NYCPHP Meetup

[Ben Sgro (sk)]

Nice topic,

I agree with much of what has been said. I'd also like to say that most 
people using php are into writing code.
'Most people'; not just those setting up a one time phpBB or something, I 
mean software engineers.

And when I say 'writing code', I mean those that write tight procedures, 
check return values, etc...

Now, those same engineers that are into writing code, may not be into 
security with the same intensity and attention to detail that they give to 
code. I think security and programming while closely related, are two 
disciplines.

Just because your a great programmer, doesn't mean your great at tightening 
apps.

I think all developers should take some time to read a few phrack white 
papers, 2600 articles, or jon erikson books.

Even better, write some dummy programs to exploit in c (stack and heap 
stuff, plenty examples online), php for some xss and sqlinjection.

You may learn something new that you can apply to development and 
application security.

- Ben


----- Original Message ----- 
From: "Peter Sawczynec" <ps at pswebcode.com>
To: "'NYPHP Talk'" <talk at lists.nyphp.org>
Sent: Thursday, September 14, 2006 10:21 AM
Subject: Re: [nycphp-talk] "The Web is broken and it's all your fault."


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

_______________________________________________
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