Comments on: Mass SQL Injection attack http://rc3.org/2008/04/27/mass-sql-injection-attack/ Strong opinions weakly held Fri, 10 Feb 2012 14:59:55 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: http://wasabi.homelinux.com/ http://rc3.org/2008/04/27/mass-sql-injection-attack/comment-page-1/#comment-2684 http://wasabi.homelinux.com/ Sun, 25 May 2008 20:19:24 +0000 http://rc3.org/?p=8211#comment-2684 <p>Php all together needs to be avoided</p> Php all together needs to be avoided

]]> By: Sencer http://rc3.org/2008/04/27/mass-sql-injection-attack/comment-page-1/#comment-2618 Sencer Sat, 03 May 2008 10:47:41 +0000 http://rc3.org/?p=8211#comment-2618 <blockquote> <p>should sanitize all input by default and force programmers to go out of their way to access the original input</p> </blockquote> <p>sanitize it for what? For output to the web? for usage in sql queries? If the latter, for which databases, and which charactersets should be assumed? My point is there is too many variables to make it automatic.</p> <p>@Simon:</p> <blockquote> <p>(some environments call these prepared statements, but you can simulate them with anything just by writing a simple function).</p> </blockquote> <p>and please, please, people who do that make sure that the function does more than simply glue string togethers without any further checks or escaping, otherwise you've only obfuscated the problem in the code, but exploiting is as easy as it was before. (Yes, I've seen it often enough...)</p>

should sanitize all input by default and force programmers to go out of their way to access the original input

sanitize it for what? For output to the web? for usage in sql queries? If the latter, for which databases, and which charactersets should be assumed? My point is there is too many variables to make it automatic.

@Simon:

(some environments call these prepared statements, but you can simulate them with anything just by writing a simple function).

and please, please, people who do that make sure that the function does more than simply glue string togethers without any further checks or escaping, otherwise you’ve only obfuscated the problem in the code, but exploiting is as easy as it was before. (Yes, I’ve seen it often enough…)

]]> By: Chris Adams http://rc3.org/2008/04/27/mass-sql-injection-attack/comment-page-1/#comment-2611 Chris Adams Sun, 27 Apr 2008 20:29:08 +0000 http://rc3.org/?p=8211#comment-2611 <p>Simon: I agree completely about using placeholders but I think the problem with PHP was that it wasn't consistent and a lot of code was written which made dangerous assumptions about the magic quotes behavior. It wouldn't have been perfect but the web would be safer if PHP had default escaping for input and output.</p> <p>If I could wave a magic wand for PHP6 I'd make a few backwards-incompatible changes:</p> <ul> <li>Input data would be tainted and functions which aren't marked as taint-safe would throw exceptions.</li> <li>Output data would be HTML-escaped by default and the raw-output function would be have a discomforting name like <code>insecure_output</code>. </li> <li>PDO and all other database classes would have their syntax improved to make parameters available without prepared statement overhead: it's <a href="http://svn.improbable.org/ImpUtils/trunk/ImpPDO.php" rel="nofollow">pretty easy to subclass PDO for this</a> but it should be standard.</li> </ul> Simon: I agree completely about using placeholders but I think the problem with PHP was that it wasn’t consistent and a lot of code was written which made dangerous assumptions about the magic quotes behavior. It wouldn’t have been perfect but the web would be safer if PHP had default escaping for input and output.

If I could wave a magic wand for PHP6 I’d make a few backwards-incompatible changes:

  • Input data would be tainted and functions which aren’t marked as taint-safe would throw exceptions.
  • Output data would be HTML-escaped by default and the raw-output function would be have a discomforting name like insecure_output.
  • PDO and all other database classes would have their syntax improved to make parameters available without prepared statement overhead: it’s pretty easy to subclass PDO for this but it should be standard.
]]> By: Simon Willison http://rc3.org/2008/04/27/mass-sql-injection-attack/comment-page-1/#comment-2610 Simon Willison Sun, 27 Apr 2008 19:05:09 +0000 http://rc3.org/?p=8211#comment-2610 <p>Sanitizing user input, while essential, is the incorrect way to avoid SQL injection in my opinion. SQL injection is caused by gluing strings together to create SQL queries. In this day and age there is absolutely no excuse for doing this - you should be using a database library that takes a SQL statement with placeholders and the values for those placeholders separately (some environments call these prepared statements, but you can simulate them with anything just by writing a simple function).</p> <p>PHP originally escaped input by default, and it took YEARS for the community to recover from the mess that it caused!</p> Sanitizing user input, while essential, is the incorrect way to avoid SQL injection in my opinion. SQL injection is caused by gluing strings together to create SQL queries. In this day and age there is absolutely no excuse for doing this – you should be using a database library that takes a SQL statement with placeholders and the values for those placeholders separately (some environments call these prepared statements, but you can simulate them with anything just by writing a simple function).

PHP originally escaped input by default, and it took YEARS for the community to recover from the mess that it caused!

]]>