Can I protect against SQL injection by escaping single-quote and surrounding user input with single-quotes?

Question

I realize that parameterized SQL queries is the optimal way to sanitize user input when building queries that contain user input, but I\'m wondering what is wrong with takin

Answer 1

While you might find a solution that works for strings, for numerical predicates you need to also make sure they're only passing in numbers (simple check is can it be parsed as int/double/decimal?).

It's a lot of extra work.

Answer 2

It's a bad idea anyway as you seem to know.

What about something like escaping the quote in string like this: \'

Your replace would result in: \''

If the backslash escapes the first quote, then the second quote has ended the string.

Answer 3

Yeah, that should work right up until someone runs SET QUOTED_IDENTIFIER OFF and uses a double quote on you.

Edit: It isn't as simple as not allowing the malicious user to turn off quoted identifiers:

The SQL Server Native Client ODBC driver and SQL Server Native Client OLE DB Provider for SQL Server automatically set QUOTED_IDENTIFIER to ON when connecting. This can be configured in ODBC data sources, in ODBC connection attributes, or OLE DB connection properties. The default for SET QUOTED_IDENTIFIER is OFF for connections from DB-Library applications.

When a stored procedure is created, the SET QUOTED_IDENTIFIER and SET ANSI_NULLS settings are captured and used for subsequent invocations of that stored procedure.

SET QUOTED_IDENTIFIER also corresponds to the QUOTED_IDENTIFER setting of ALTER DATABASE.

SET QUOTED_IDENTIFIER is set at parse time. Setting at parse time means that if the SET statement is present in the batch or stored procedure, it takes effect, regardless of whether code execution actually reaches that point; and the SET statement takes effect before any statements are executed.

There's a lot of ways QUOTED_IDENTIFIER could be off without you necessarily knowing it. Admittedly - this isn't the smoking gun exploit you're looking for, but it's a pretty big attack surface. Of course, if you also escaped double quotes - then we're back where we started. ;)

Answer 4

I realize this is a long time after the question was asked, but ..

One way to launch an attack on the 'quote the argument' procedure is with string truncation. According to MSDN, in SQL Server 2000 SP4 (and SQL Server 2005 SP1), a too long string will be quietly truncated.

When you quote a string, the string increases in size. Every apostrophe is repeated. This can then be used to push parts of the SQL outside the buffer. So you could effectively trim away parts of a where clause.

This would probably be mostly useful in a 'user admin' page scenario where you could abuse the 'update' statement to not do all the checks it was supposed to do.

So if you decide to quote all the arguments, make sure you know what goes on with the string sizes and see to it that you don't run into truncation.

I would recommend going with parameters. Always. Just wish I could enforce that in the database. And as a side effect, you are more likely to get better cache hits because more of the statements look the same. (This was certainly true on Oracle 8)

Answer 5

Yes, you can, if...

After studying the topic, I think input sanitized as you suggested is safe, but only under these rules:

1. you never allow string values coming from users to become anything else than string literals (i.e. avoid giving configuration option: "Enter additional SQL column names/expressions here:"). Value types other than strings (numbers, dates, ...): convert them to their native data types and provide a routine for SQL literal from each data type.

   • SQL statements are problematic to validate

2. you either use nvarchar/nchar columns (and prefix string literals with N) OR limit values going into varchar/char columns to ASCII characters only (e.g. throw exception when creating SQL statement)

   • this way you will be avoiding automatic apostrophe conversion from CHAR(700) to CHAR(39) (and maybe other similar Unicode hacks)

3. you always validate value length to fit actual column length (throw exception if longer)

   • there was a known defect in SQL Server allowing to bypass SQL error thrown on truncation (leading to silent truncation)

4. you ensure that SET QUOTED_IDENTIFIER is always ON

   • beware, it is taken into effect in parse-time, i.e. even in inaccessible sections of code

Complying with these 4 points, you should be safe. If you violate any of them, a way for SQL injection opens.

Answer 6

There are two ways to do it, no exceptions, to be safe from SQL-injections; prepared statements or prameterized stored procedures.