Question

My knowledge is shallow since I’ve only studied PHP/HTML/MySQL as a hobby, so please be gentle.

ESCAPE is intended to help programmers prevent SQL injections. Yes, programmers should be smarter and just addslashes(), but in light of the recent LulzSec stupidity, I think it would be a good move by W3C to implement a new form input method that makes it easier for programmers to implement security.

I only know PHP, so I’ll speak to that. Basically, while before we had

$safeTagSearch = addslashes($_GET["tagSearchRaw"]);

we will now have

$safeTagSearch = $_ESCAPE["tagSearchRaw"]);

If tagSearchRaw = "cats in hats", it will be slashed as ☃"cats in hats☃". (The unicode snowman is to illustrate how this will work for different languages with different escape sequences.)

The $_ESCAPE code will recognize the ☃ as the form escape character and do a tiny bit of processing before passing \"cats in hats\" to $safeTagSearch.

Is this at all feasible?

Answer 1

I don’t think it’s feasible at all because it is requiring the web programming language to be aware of the specific SQL syntax you’re using. That functionality is the domain of the database provider (such as ODBC, OLEDB, SQL Server Native, Jet, whatever) to be able to convert all inputs into the SQL-specific-variant syntax necessary to get the job done in the database with no errors and no SQL injection.

The cure isn’t to give web developers a crutch for their misuse of concatenated SQL statements, but instead for web developers to use formal parameters on commands (or at least to use parameter placeholders such as ? on ad-hoc queries) instead of just squishing SQL fragments and parameter strings together and hoping it works right.

If you offer $_ESCAPE to supposedly cure people who brainlessly use $_GET, then you’ll introduce other problems through the brainless use of that, such as storing in the database strings that have been escaped twice (oops). That is just going to confuse the issue.

An additional issue this brings up is the problem of not knowing whether the string you’re using is safe or unsafe. A resolution I would support is the construction of strongly-typed String objects that indicate what kind of string it is (HTMLString, UnsafeString, SQLString, etc.).

Then if you try to do something like <SQLStringFragment> + <UnescapedString> you will get a compile-time or run-time error for trying to concatenate two different kinds of strings without first converting them to the same type.

The DB Library could be extended to offer conversion utilities like SQLStringFromParameterValue that would accept an unescaped string and return an escaped one based on the properties of the current connection.