4

I found a simple breakout in a where clause in one of our projects where the code is so old that they claim they can't use parameters to communicate with ms SQL server. It's written in C++, I can't read this language and I'm not able to access the code in any way.

To illustrate the issue I added an example of a non harmful statement, the bold part is what the user can directly input

SELECT '1 ' SELECT 2--';

The single quote after 1 is causing the breakout in this scenario. This is what I've shown to the team.

They then did a detection in code that searches for single quotes and add three other single quotes after each single quote they find. Thus the example would become this

SELECT '1'''' SELECT 2--';

I don't like this solution at all, but I can't find a way to breakout any more. The fields inside the database are stored treated as nvarchar characters. Is there still a possibility to bypass this practice in any kind?

Improve this question
4
  • Use a double quote. This is a shitty fix.
    – thel3l
    Commented Feb 7, 2018 at 11:51
  • I know that's why I'm wondering if it couldn't be bypassed someway.
    – Samyne
    Commented Feb 7, 2018 at 12:18
  • Just to clarify... The part you are injecting here is 1' SELECT 2--? Your SQL queries doesn't look like real SQL to me. Are you injecting in the column list? Coul you perhaps produce a more realistic example? Like SELECT foo FROM bar WHERE bar = ... or something.
    – Anders
    Commented Feb 7, 2018 at 12:45
  • The original issue was inside a where clause where a text value was not being parsed until now. Then they added ''' to each ' they could find in the users input. I updated the example with user input in bold what should represent the user input data. No need to make the sql statement more complex than it needs. I just need to know if it still could be escaped in a way I don't know.
    – Samyne
    Commented Feb 7, 2018 at 16:09

2 Answers 2

Reset to default
1

the code is so old that they claim they can't use parameters to communicate with ms SQL server

That's a lousy excuse. It's like saying "your car is so old, we can't build in seatbelts". They might have to redo a lot of work with more modern techniques, but it can be done.

The fix they applied is escaping, which is a correct solution (second best to parameterised queries). To escape an apostrophe (or 'single quote') in MSSQL, you can prefix it with another apostrophe. Why did the developers add two more? The only explanation I can think of, is that the output is interpreted as SQL again, but honestly I don't know and it should create bugs if nothing else.

As for how to break out of it, that part of your question seems to be a duplicate of this one (though yours is specific for MSSQL):

How to defeat doubling up apostrophes to create SQLi attack?

The answer is basically:

[...] you may be able to force various SQL databases to translate unicode to the local charset. For example, Ā could be converted to A. Even worse: U+02BC, or ʼ would be translated as ', which is U+0027. This is called Unicode-based Smuggling.

Improve this answer
0

They are encoding the dangerous characters - this is not a bad approach, but can create other issues . They are changing the length of the string - if they're not being careful about checking the length after the encoding, they could be opening themselves up to a buffer overflow, or (in some cases) truncating the encoding in the middle to create an unexpected quote.

Try an input of all single quotes and see what happens.

Better to reject single quotes, assuming this is a column name and you can be sure there are no columns with single quotes.

Improve this answer

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