6 ms·

Oh man - failure to use a framework or they worked around it - either way this was a big programming no no - direct use of SQL with NO sanitizing. Very bad. I

Oh man - failure to use a framework or they worked around it - either way this was a big programming no no - direct use of SQL with NO sanitizing. Very bad. I can't even call this a vulnerability - it's an open door.

noir_lord 13y ago
The horrible reality is that much (possibly most, I have no figures so this is ancedotal) of the PHP code in production was written using a) no framework b) some in-house framework that was never audited. It is only in the last couple of years that the PHP community has begun properly getting it's shit together (composer, PSR, unit testing (not a universal panacea but a useful tool)). The problem is as always the good programmers will continually seek out better ways to do things (or at least explore the available options) while the "bad" programmers will continue to program like it's 2001 and PHP4 is the new kid on the block. This is mostly the result of PHP's origins and is unlikely to improve in the short term. If you follow best-practices, use modern tools (as mention composer, psr autoloading) and a decent framework (Symfony 2, Zend or my favourite Laravel) then you can turn out a good, secure and well engineered product.
- kijin 13y ago
  This is bad programming, period. It has very little to do with frameworks. If somebody is inclined to stick raw POST data into an SQL query, a framework isn't going to save him. Maybe an ORM will, but ORMs are only a small part of what we call frameworks nowadays, and any ORM that allows custom SQL still leaves plenty of room for a lazy developer to shoot himself in the foot. Similarly, a framework won't prevent you from sticking raw POST data into an exec() call. Most frameworks don't even care about those shell functions, they're so heavily focused on providing a smooth CRUD experience. On the other hand, if the argument is that someone who knows how to use a proper framework is likely to be a better programmer than someone who doesn't, I agree and I'm sure that such a correlation can be easily proven.

noir_lord 13y ago

The horrible reality is that much (possibly most, I have no figures so this is ancedotal) of the PHP code in production was written using a) no framework b) some in-house framework that was never audited. It is only in the last couple of years that the PHP community has begun properly getting it's shit together (composer, PSR, unit testing (not a universal panacea but a useful tool)). The problem is as always the good programmers will continually seek out better ways to do things (or at least explore the available options) while the "bad" programmers will continue to program like it's 2001 and PHP4 is the new kid on the block. This is mostly the result of PHP's origins and is unlikely to improve in the short term. If you follow best-practices, use modern tools (as mention composer, psr autoloading) and a decent framework (Symfony 2, Zend or my favourite Laravel) then you can turn out a good, secure and well engineered product.

kijin 13y ago
This is bad programming, period. It has very little to do with frameworks. If somebody is inclined to stick raw POST data into an SQL query, a framework isn't going to save him. Maybe an ORM will, but ORMs are only a small part of what we call frameworks nowadays, and any ORM that allows custom SQL still leaves plenty of room for a lazy developer to shoot himself in the foot. Similarly, a framework won't prevent you from sticking raw POST data into an exec() call. Most frameworks don't even care about those shell functions, they're so heavily focused on providing a smooth CRUD experience. On the other hand, if the argument is that someone who knows how to use a proper framework is likely to be a better programmer than someone who doesn't, I agree and I'm sure that such a correlation can be easily proven.