NYCPHP Meetup

NYPHP.org

[nycphp-talk] "The Web is broken and it's all your fault."

Dan Cech dcech at phpwerx.net
Thu Sep 14 09:40:11 EDT 2006


michael wrote:
> http://www.internetnews.com/dev-news/article.php/3631831
> "
> 	Those are the words that Rasmus Lerdorf, the creator of PHP,
> 	said to kick off his keynote at the php|works conference under
> 	way here.
> 	...
> 	"The Web is pretty much broken, we can all go home now,"
> 	Lerdorf said somewhat sarcastically to the capacity crowd.
> 	"Luckily most people don't realize that it's broken."
> 	
> 	Part of the reason Lerdorf considers the Web "broken" is that
> 	it is inherently insecure for a variety of reasons. One of those
> 	reasons sits at the feet of developers.
> 
> 	"You don't know that you have to filter user input," Lerdorf
> 	exclaimed.
> "

Personally, I'm of the opinion that right now people tend to focus too
much on input filtering, and not enough on safe storage and display
practices.

If you are correctly handling incoming data, it makes little difference
what that data may be.  For example, if you construct a query like:

$query = "SELECT * FROM mytable WHERE myid='$someid'";

You are obviously vulnerable to assorted SQL injection attacks.

However, construct the query like:

$query = 'SELECT * FROM mytable WHERE myid='.
mysql_real_escape_string($someid);

or:

$query = 'SELECT * FROM mytable WHERE myid=?';
$args = array(
    $someid,
);

And you have prevented the attack, regardless of the contents of
$someid.  This is because you are correctly formatting the data in
context, in this case as an SQL string.

The same goes for displaying data on a webpage, pass it through
htmlspecialchars and you'll be guaranteed that it is correctly formatted
as a block of HTML CDATA.

The security breach comes from treating the data incorrectly, not from
its contents.

That said, if you need to display html received from the client as html,
you need input filtering to separate the bad from the good.  However,
these cases are not the norm, and in many situations input filtering is
merely restricting the data you're allowing clients to input, without
any real security gains.

If you need to enforce certain restrictions on user input, according to
the 'rules' of the system then input filtering is a great idea, but
don't get caught up in thinking that filtering input is the answer to
all security problems.

Dan



More information about the talk mailing list