The state of PHP security [LWN.net]

The state of PHP security

Posted Dec 26, 2006 12:49 UTC (Tue) by IkeTo (subscriber, #2122)
In reply to: The state of PHP security by iabervon
Parent article: The state of PHP security

> I still think the solution to SQL access is to remove support for using
> strings as SQL statements, and instead have a "SQL statement" type, with
> functions to append statement text (with it being an error to include any
> single quotes in this) and to append constants.

I don't think so. There is no intrinsic problem of using strings as SQL statements. It is the same whether you write

handle.do_select("SELECT id, name FROM customers WHERE country='" + country + "'")

handle.do_select(new SQLStatement("SELECT id, name FROM customers WHERE country='" + country + "'")).

If your user don't know what's wrong with it, you can't expect them to do the right thing for it. If the syntax for doing things the secure way is harder than the syntax for doing things the insecure way, you will see lazy people doing the wrong things saying that they are only for the prototype and never correct it when the software is released.

The only answer is a combination of education and making correct things easier. Make the first example in the official database tutorial that needs a user-provided input to read handle.do_select("SELECT id, name FROM customers WHERE country=?", country), and tell learners that this is safe because even if country contains a single quote or semicolon it does the right thing to get them escaped. Build the library so that a single placeholder syntax is used for all different SQL implementations. As a bonus, teach them how to subvert programs that simply appends the user input to the SQL. Then doing it the secure way is easier than doing it the insecure way, and people actually feel insecure when they write insecurely. Then there will be no more problem of SQL injection.

(Log in to post comments)

The state of PHP security

Posted Dec 26, 2006 18:57 UTC (Tue) by iabervon (subscriber, #722) [Link]

My point is that doing

handle.do_select(new SQLStatement("SELECT id, name FROM customers WHERE country='" + country + "'"))

should always give a runtime error "Single quote in SQL statement". The only way to do this query should be something like

handle.do_select(new SQLStatement("SELECT id, name FROM customers WHERE country=") + country).

You'll note that this is easier than the insecure way (you don't have to know how to put a string in a SQL statement, or remember to close your single quotes or anything like that, and it's shorter anyway, unless your language happens to have operator overloading for strings and nothing else), and, additionally, the system prevents the insecure way from ever being executed, regardless of whether its input is malicious in a particular case or not. The slightly inconvenient case is where you'd be able to use a hard-coded constant embedded in your SQL if that were permitted; but hard-coded constants are a pain for further development anyway; some day your DBA will make you change them, and you'll be sad if they aren't split out into a single location with a logical name. (The only exception being patterns for LIKE, where you have to suffer through making your pattern a string constant instead of having it embedded in the SQL.)

The only sure way to educate people not to write insecure code is to make insecure code not work at all. The lazy people who do things the insecure way for the prototype will find that the prototype doesn't even run, so they'll go back and do it the secure way.