3

I'm working in a web site that doesn't use parameters on SQL queries. All the queries are adhoc and the way they are doing the input validation seems good to me, I'm not able to break it to do SQL Injection.

They are validating the numeric input and if it's string they are doing this (e.g):

sanitizedInput = "'" & Replace(input, "'", "''") & "'"

In others SGBD it's easy to break, but in MSSQL I'm not finding a way to do it. How can I break this? I just want to show them that this isn't enough.

Improve this question
8
  • 1
    Duplicate of stackoverflow.com/questions/139199/….
    – Nam Nguyen
    Sep 28, 2011 at 10:56
  • Hi Nam, stackoverflow is more for programming related questions, I through I would find a more technical answer here, since this is specialize in IT Security. So, can we all assume that answer is fine and there is no way to break it? Or should this be consider as a different question in a more technical environment and hope to find more better answer?
    – Bruno Costa
    Sep 28, 2011 at 11:01
  • The devil is in the details. Please do look at AviD's paper in that duplicate question. There IS way to break this sanitization.
    – Nam Nguyen
    Sep 28, 2011 at 11:03
  • Can you show me how? :P There all I'm asking :)
    – Bruno Costa
    Sep 28, 2011 at 11:22
  • 1
    AviD's paper already did. You just did not bother to read.
    – Nam Nguyen
    Sep 28, 2011 at 11:28

4 Answers 4

Reset to default
6

No. This will certainly not handle string concatenation that is not delimited by quotes. e.g. a numeric field.

Consider

sql= "select username from users where id=" + id

if id is provided as 1 or 1=1 then all rows from the database can be returned. Obviously this can example could be extended to union select attacks or even entire nested queries.

Just use bound parameters and avoid the entire problem of SQLi.

Improve this answer
2
  • Cheekysoft, as I said in my question, they're validating the numeric fields. I just need a demo to show them "why they should change this".
    – Bruno Costa
    Sep 28, 2011 at 15:34
  • 2
    Might be tough to put together a simple example for the T-SQL dialect (it is v.easy for MySQL's dialect). I suspect your best bet may to be find a unicode homoglyph, such as U+02BC that gets auto-translated to a U+0027 quote character by your server. Check that the filter can't be defeated by different whitespace characters, carriage returns or lower ansi chars, such as the null char.
    – Cheekysoft
    Sep 28, 2011 at 16:15
4

I'm not able to break it

Just because you are not able to break it, does not guarantee that no one else cannot break it. I've seen SQL injection attacks reported in the SANS diary that I can't even begin to understand (mostly because I don't have the time to figure out what they are doing).

http://isc.sans.edu/diary.html?storyid=9397
http://isc.sans.edu/diary.html?storyid=11011
http://www.sans.org/reading_room/whitepapers/securecode/sql-injection-modes-attack-defence-matters_23

Improve this answer
1
  • I know that Tangurena, I know how to prevent SQL Injection and what should I do. I just need a justification to tell my client that he should change all the code to be secured.
    – Bruno Costa
    Sep 29, 2011 at 13:27
4

If you want a guaranteed safety from injection attacks, use bound parameters.

Your method may in practice actually be safe for a particular RDBMS, but you have no guarantee of this -- all you can do is check against the types of code-injection attacks that you can think to check against (while bound parameters simply do not allow code to be injected).

Are you sure, MSSQL does not map any characters from alternate character sets (e.g., unicode) to internally to a single quote (or an escape character like \ ), that would make an injection attack against your defense possible? Are you sure later processing of your sanitized input does not inadvertently (or purposely by a malicious co-admin) break your sanitation procedure? Are you sure an update to MSSQL will not later include new language/character-set support that would allow someone to do this unicode style attack to secretly inject a quote or escape character? Are you sure, your application will never be moved to another RDBMS that is vulnerable to these sorts of attacks (say years from now if MSSQL is abandoned or clearly inferior to another product)?

Improve this answer
-1

No.

If you must interpolate, you should always use code of the form:

sql = "select * from table where param = " + quote_sql_value(value)

Where quote_sql_value replaces ' with '' and surrounds the result with ' on either side.

Note that MySQL and other databases have escape sequences that may be difficult to detect and encode properly. So far as I can tell, it appears MSSQL does not have such, so the encoding of a value should be fairly simple. However, you should do further research on MSSQL encoding; don't take my word on it.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .