35

I just saw this come up in our request logs. What were they trying to achieve?

The full request string is:

properties?page=2side1111111111111 UNION SELECT CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45),CHAR(45,120,51,45,81,45),CHAR(45,120,52,45,81,45),CHAR(45,120,53,45,81,45),CHAR(45,120,54,45,81,45),CHAR(45,120,55,45,81,45),CHAR(45,120,56,45,81,45),CHAR(45,120,57,45,81,45),CHAR(45,120,49,48,45,81,45),CHAR(45,120,49,49,45,81,45),CHAR(45,120,49,50,45,81,45),CHAR(45,120,49,51,45,81,45),CHAR(45,120,49,52,45,81,45),CHAR(45,120,49,53,45,81,45),CHAR(45,120,49,54,45,81,45) -- /*

Edit: As a google search didn't return anything useful I wanted to ask the question for people who encounter the same thing.

roo
  • 7,106
  • 8
  • 39
  • 45

2 Answers2

22

This is just a test for injection. If an attacker can see xQs in the output then they'll know injection is possible.

There is no "risk" from this particular query.

A developer should pay no attention to whatever injection mechanisms, formats or meanings - these are none of his business.

There is only one cause for for all the infinite number of injections - an improperly formatted query. As long as your queries are properly formatted then SQL injections are not possible. Focus on your queries rather than methods of SQL injection.

roo
  • 7,106
  • 8
  • 39
  • 45
Your Common Sense
  • 156,878
  • 40
  • 214
  • 345
  • 5
    "A developer should pay no attention to whatever injection mechanisms, formats or meanings - these are none of his business." - Can you elaborate? To me that sounds like I shouldn't care about SQL injection at all. Or place all my trust into whatever framework I use. – roo Jul 03 '13 at 04:46
  • Yes, yes. That's it - you shouldn't. – Your Common Sense Jul 03 '13 at 04:48
  • 1
    Thats madness! If advise people to think like that then why did you write https://github.com/colshrapnel/safemysql ? – roo Jul 03 '13 at 04:57
  • 1
    The very purpose of this library is indeed a proper formatting. While "Safety" mentioned there has a wider meaning - the query is safe from whatever errors caused by improperly formatted literals (including injections but not aimed to). – Your Common Sense Jul 03 '13 at 05:05
  • Ah okay - so you mean check that your queries are correct and dont care about mechanisms that exploit them. That makes sense. – roo Jul 03 '13 at 05:11
  • Yes. By the way, using a placeholder to represent *every* dynamically added query part is the only way. – Your Common Sense Jul 03 '13 at 05:18
  • You shouldn't have to worry about SQL injection because your user facing code should not allow it. It should be executing stored procedures and passing in parameters. Stored procedures do not care what the user sends in. It's interpreted as data, not code, regardless of quotes or strings or special characters or any other tricks. – Terry Carmen Jul 13 '18 at 12:33
  • FWIW, this does identity the server type as MySQL, since MySQL char() accepts a variable number of parameters, while SQL Server only accepts one. – Terry Carmen Jul 13 '18 at 12:41
  • What is the meaning of `xQs` in this answer? – Avatar Oct 17 '18 at 12:58
7

The Char() function interprets each value as an integer and returns a string based on given the characters by the code values of those integers. With Char(), NULL values are skipped. The function is used within Microsoft SQL Server, Sybase, and MySQL, while CHR() is used by RDBMSs.

SQL's Char() function comes in handy when (for example) addslashes() for PHP is used as a precautionary measure within the SQL query. Using Char() removes the need of quotation marks within the injected query.

An example of some PHP code vulnerable to an SQL injection using Char() would look similar to the following:

$uname = addslashes( $_GET['id'] );
$query = 'SELECT username FROM users WHERE id = ' . $id;

While addslashes() has been used, the script fails properly sanitize the input as there is no trailing quotation mark. This could be exploited using the following SQL injection string to load the /etc/passwd file:

Source: http://hakipedia.com/index.php/SQL_Injection#Char.28.29

icedwater
  • 4,701
  • 3
  • 35
  • 50
Ganesh S
  • 371
  • 6
  • 26
  • 1
    Nice intro to injection but doesn't really answer the question, which is "what was that _specific_ SQL trying to acheive?" – paxdiablo Jul 03 '13 at 03:30
  • I am interested in both the specific SQL they were trying to execute, but also how this could work. As a google search didn't return anything useful I wanted to start a discussion for people who could be at risk. – roo Jul 03 '13 at 04:27
  • @roo, discussions are not really what SO is for. If you're stating you want to know how the current attack would work (and it appears that is the case here), that's another matter. But the desire to start a discussion is likely to get questions closed and deleted. – paxdiablo Jul 03 '13 at 05:34
  • 2
    @paxdiablo - Fair point, discussion was the wrong word. I raised the question because I didn't know what this query was trying to do and google didn't have the answer. I knew that SO was the best place to get an answer and have the largest reach if it was something important. – roo Jul 03 '13 at 05:53