Home page logo

basics logo Security Basics mailing list archives

RE: PHP filter function against SQL injections
From: "Dan Anderson" <dan-anderson () cox net>
Date: Sun, 18 Feb 2007 04:29:43 -0600

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.


-----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

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

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

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
(I don't know the event handler syntax off hand but I know it can be

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]