RE: PHP filter function against SQL injections

["Dan Anderson" <dan-anderson () cox net>]

I'll add another "me too".

In my experience, extensive use of client-side security is a terrific
indicator that the server is probably vulnerable.

I'd actually recommend not having the client check anything.

The problem with any security checking at the client is that it provides
absolutely no security and still manages to instill a false feeling that you
are secure.

Dan

> -----Original Message-----
> From: listbounce () securityfocus com [mailto:listbounce () securityfocus com]
> On Behalf Of jeffrey rivero
> Sent: Tuesday, February 13, 2007 8:59 AM
> Cc: security-basics () securityfocus com
> Subject: Re: PHP filter function against SQL injections
>
> I second that its all to often i see this as an major problem
> jeff
>
> Henry Troup wrote:
> > It's a serious mistake to assume that the php page will only ever see
> input from its own page.  An attacker will not use the form on the page,
> but drive attacks directly into the submit URL.  Client-side javascript
> can be a user convenience; but it can never be part of your security
> strategy.
> > Filtering input for security must be done on the server.  On the server
> you must treat all input as "evil" until it is proven innocent (passes the
> filter).
> > --
> > Henry Troup
> > htroup () acm org
> >
> >  On Sat Feb 10 10:35 , Nic Stevens  sent:
> >
> > > I would suggest, though, using data filtering on the form using
> > > javascript as your first line of defense. If you're accepting a string,
> > > for example, only allow valid characters to be placed in the form
> field.
> > > (I don't know the event handler syntax off hand but I know it can be
> done)
> >