NYCPHP Meetup

[David Krings]

Paul Houle wrote:
>    I think of ORM as a partial solution to the problems of building 
> database-backed web apps.  People call database applications "CRUD" 
> apps,  short for
I have no idea what ORM is, mainly because I didn't follow the past 
threads, but here is my take of the problem you describe.

  >    This would have been OK if they'd written something like
> 
> $first_name=addslashes($_POST["first_name"]);
> $last_name=addslashes($_POST["last_name"]);
> $organization=addslashes($_POST["organization"]);

Depending on the database used there are better means. In case of mysql 
using mysql_real_escape_string is the way better approach as I learned 
not too long ago. With addslashes you get the proper escaping, but upon 
retrieval you have to take the surplus slashes back out. When storing 
something that has slashes in the original information (windows file 
paths for example) how is the code supposed to know which slashes to 
take out? And all that although a slash won't break your SQL.

> 
>    But they didn't.  Neither do most developers.  Now,  there are tools 

That is because most developers are ignorant, unqualified, or arrogant 
or all three in regards to users some very basic level of quality and 
security.* I have seen apps where the developer went through the trouble 
to take out anything that might be offending to SQL or the rest of the 
code rather than to choose proper delimiters and proper escaping.
I often post opinions in a german online newspaper and they use a PHP 
script with MySQL. Of course, that script doesn't do any escaping and 
blurts out the whole SQL query upon failure. How easy will it be to drop 
some tables, add some, modify, add procedures....in short, that script 
is open to SQL injection at the first degree.

I recall that I did exactly the same when I started poking around in 
MySQL with PHP until I read about SQL injection and that addslashes is 
the way to go - until I tried to store file paths in my tables and all 
they stopped working upon retrieval. I then opted to go the ignorant and 
unqualified route by not escaping file paths and thus not needing to 
strip slashes. Until I came across a folder name with a single quote in 
it. Then I learned to do it the right way.

>    The ORM system takes care of quotes and bad data for you.

One of the lessons of professional software QA and hobbyist PHP 
development is "All input is evil!". I always distrust everything even 
when it comes from a db record that I just wrote a few seconds ago. In 
that sense I think it is a bit foolish to just forget about proper 
validation and have some system take care of it. That system is also 
just a bunch of lines of code. While I do see the benefits of 
simplifying db access and with that abstracting the db layer I still 
think that anything that comes in and goes out has to be fully verified 
to be good data. Don't expect that you get good data and don't expect 
that the other system will take care of bad data (from you or someone else).

This concludes today's lesson. Thank you students.

David

*Note: There are very many honorable exceptions and I know of several 
who take things like security, quality, and usability into consideration 
- after the lack of doing so bit them hard into their behinds.