Re: another Quickform security question

On 10/3/05, l Burnerheimerton <lburnerheimerton@yahoo.com> wrote: > --- Justin Patrin <papercrane@gmail.com> wrote: > > > On 10/3/05, l Burnerheimerton > > <lburnerheimerton@yahoo.com> wrote: > > > So I am ABSOLUTELY clear on this, in order to > > sumbit a > > > form in the most secure way using Quickform, I > > should > > > create a rule for *ALL* submitted fields. > > Correct? > > > > > > > I don't know what you're asking. If you want to > > verify something about > > a field you always have to set up a rule. Otherwise, > > how do you know > > that it is what you want? > > > > For hiddens, use setConstants to make sure they stay > > the value you wanted. > > > > For elements which have to be in a certain format > > verify them. > > > > Also, make sure to think about XSS and SQL > > injection. For some more on this: > > > http://pear.reversefold.com/dokuwiki/doku.php?id=phpfaqs > > > > -- > > Justin Patrin > > > > -- > > PEAR General Mailing List (http://pear.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > Justin - what I meant was, everywhere I read, it says > to trust NO user input. I wanted to know what I > needed to do with Quickform to verify nothing was > trusted. Never trust user (non-server) input. You don't have to do anything special with QF that you wouldn't do anyway with other solutions. > > So, what I understand you saying is that for Quickform > specifically, I need to calidate EVERY field I use in > the form using a validation rule. Several days ago I > wrote in this forum asking if a malicious user could > get around the validation forms using telnet. I never > got a definitive answer but I think the answer is no - > *IF* validation rules are used. Could you verify > that, oh writer of quickforms? "Using telnet" or JS or FireFox extensions or writing their own HTML form which submits to your URL or using HTTP_Request/Client is all the same. Anyone can spoof the client-side form and send you anything they want. They can add and remove fields and put whatever they want in the form. So, basically what I'm saying is that client-side validation is nice (max lengths, max file size, JS code) but it can't be trusted. Client-side code is a convenience for the user, not a replacement for server-side validation. This of course doesn't mean that you need to validate every single field in a specific way. As long as you quote your queries and output properly you'll just get "bad" data in your DB as a result of attcks (instead of losing data or opening security holes). If you also want to have no bad data then you're going to have to validate every single field in some way, but this is a losing battle. Unless you're really really worried about your data (i.e. not having "garbage" in your text fields or 0000-00-00 00:00:00 or some-such in date fields) there's no need to "validate" absolutely everything. Just validate enough to make sure that your DB's integrity isn't compromised (link values are real records, in other words) and you'll be fine. > > I use DB with placeholders or autoprepare/execute, > which I understand escapes the data appropriately > before using it. Yes, this should effectively stop SQL Injection attacks. > > On the dsiplay side, I use htmlentities() before > displaying the data which should solve the XSS issue. > Yes, using htmlentities() should solve XSS issues. -- Justin Patrin