NYCPHP Meetup

[Peter Sawczynec]

It would seem that it would be more optimally secure to both:
i) correctly handle the data, but also to
ii) check for what the data is. 

That would include checking length and data type. Wrong data types 
and too long strings can break SQL queries. 

But, hypothetically, if one is stuffing all their data into type VARCHAR
fields 
all kinds of things will get handled. But, later data summary reports from 
the database can produce inaccurate results. 

I was just reviewing Adobe best practices on Flash ActionScript 2.0 
and they suggested that all variables be declared and be 
strongly typed to force your application to throw errors immediately 
when wrong data types get sent to a function.

The ActionScript strong data typing is of the form:
var cust_first_name : string
var this_date : Date

It appears that almost every other language competitively positioned to PHP 
forces discipline a bit more, starting with making one know the expected 
data type(s) at all junctures.

Warmest regards,
 
Peter Sawczynec,
Technology Director
PSWebcode
_Design & Interface
_Ecommerce
_Database Management
ps at pswebcode.com
646.316.3678
www.pswebcode.com








-----Original Message-----
From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On
Behalf Of Dan Cech
Sent: Thursday, September 14, 2006 9:40 AM
To: NYPHP Talk
Subject: Re: [nycphp-talk] "The Web is broken and it's all your fault."


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
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com

Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php