Security - input filtering and escaping

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I've recently begun using the following PHP classes to increase security.

There are two main methods to this class: the "process" method which does
the actual filtering and the "safeSQL" method which does typical escaping
stuff for avoiding SQL injection.

When using the class in processing forms, I'm a bit conflicted in deciding
whether to use the safeSQL method before finishing validating the form's

For example, I could filter and escape as soon as it is submitted:
$foo = $iFilter->safeSQL($iFilter->process($_REQUEST['foo']));

Or, I could filter it:
$foo = $iFilter->process($_REQUEST['foo']);

then do some validation and if validation is passed, then escape it:
$foo = $iFilter->process($foo);

The reason I'm concerned about which is best is this concept I've seen
mentioned elsewhere that discusses doing a lot of this stuff "silently",
which I guess could also apply to both methods.

What does everyone else think?

Karl Groves

Re: Security - input filtering and escaping

Karl Groves wrote:

Quoted text here. Click to load it

I'm going to get involved in this because I think you are referring to
an earlier thread I participated in.

First, I'm a perl guy and not PHP, and I'm not familiar with all the PHP
security issues. But, you may wish to read some of the docs:

<URL: />

You have two different issues.

  One is filtering out extraneous PHP tags and HTML and javascript. That
appears to be particulary usefull for times when the submitted data
appears back on the web and could cause trouble for your readers. In
other words, isn't simply stored in the table.

   The second is the sql injection problem.

   So, I would do the first if needed, then I would definately do the
second. I would always do it in that order.

   I hope this is of some help. Others with more PHP experience will no
doubt clarify.


Quoted text here. Click to load it

Re: Security - input filtering and escaping

Quoted text here. Click to load it

As I said, I'm using a new class and attempting to decide where/ when to
apply the method for avoiding SQL Injection.

Quoted text here. Click to load it

I did.
It didn't really discuss this concept of "filtering silently".
Others (I believe Chris Shifflet) have expressed the notion that such
filtering should occur silently without giving the (potentially abusive)
user the clue that their crap has been done away with. That way they cannot
be clued into the fact that you've caught them attempting to abuse the
system. By providing them with that information they may be inclined to
keep trying, whereas if they think they've gotten away with it, they'll
just go on their way.

On the other hand, there are those who would say that such silent filtering
is bad for usability. Those users who are NOT purposely abusing the system
but who may nevertheless enter bad stuff into web forms. By silently
filtering the input, the user is missing out on valuable feedback with
which to recover from error. In this case, it is argued, the vast majority
of users are "harmed" by the desire to thwart a minority of abusers.

Quoted text here. Click to load it

Right. The idea would be to eliminate the bad junk before it ever makes it
into the database

Quoted text here. Click to load it

So, instead of doing the filtering & injection stuff at the same time, your
proposal would be to:
1. Filter
2. Validate
3. If validation passed, do the SQL injection stuff.

Karl Groves

Site Timeline