Hmm, I guess I knew where the author was going and got the answer right, but I disagree with the premise of the question.

The asssumption that you can prevent SQL injection by combining "quote doubling" with "keyword detection" is simply silly. Quote doubling is only ever of any use in striong values (values that you encapsulated in quotes in your SQL string)

There are, however, very simple ways that you CAN safely prevent injection with a very similar method:

1) Always know the "type" of the data that the user is submitting in a given variable/field.

2) Whenever inserting a user-provided character string (text/nvarchar/etc), replace (double up) single quotes

3) Whenever providing any other sort of value, validate it as really being of that type BEFORE trying to use it in any dynamic SQL. If it is supposed to be a number, check it is numeric; if it is supposed to be a date, check it really is. And of course, if it is not of the type it is supposed to be, never ever allow it to be used in dynamic SQL.

When these simple, easy-to-implement rules are consistently followed there is no way to perform an injection attack (as far as I know).

PLEASE NOTE: The problem with this method is that there is no reliable way to establish, over any significant amount of code, that the above rules really were followed consistently - so it is much safer to just stick to ADO Parameters and pre-defined SQL statements, or Stored Procedures with Parameters. (and the following does not count: "EXEC MyProc @SomeVar = " & SomeUserProvidedVariable & "; " - this is exactly the same as regular dynamic SQL)

Does anyone know of any way that a SQL injection could actually be performed, if the 3 rules above were consistently followed?