Jump to content

SQL injection attempts... should I be worried


Recommended Posts

(I'm putting this in PHP since it's not a question specific to MySQL or other DB stuff.)


I have a page that uses the GET id to find a product. GET variables are sanitized, and the SQL string is escaped even though it's expecting a number only. So the code seems safe to me. I'm getting some error_log results that appear to be hack attempts: 


p.*, t.id as blah
FROM some_table p
left outer join some_other_table t
on p.id = t.product_id
WHERE p.id = 139\' and benchmark(20000000,sha1(1))-- 
Should I be worried about something like this? Anything more (or less) that I should be doing?
Link to comment
Share on other sites

if that's the query statement that was formed, then you are not handling the $_GET variable correct, since it shows injected sql along with the numerical value.


that particular sql injection attempt may have failed, but you can inject sql that doesn't contain any characters that are affected by an escape function, that isn't failing, isn't producing any errors, and does allow the hacker to dump the contents of your database tables.


short-answer - that the sql statement you posted doesn't have any ' before the number, means that no amount of using an escape function will protect it, and that it shows injected sql with the id number, says you are not handling the value correctly.


if you post your code showing how you are handling the $_GET variable before putting it into the sql statement, someone can help with it.


an alternative would be to use prepared queries, where values are bound to place holders in the sql query statement, supplied when the query is executed, and cannot be used for sql injection.

  • Like 1
Link to comment
Share on other sites

This is an SQL injection, and you can be pretty sure that the next attempt did in fact succeed and gave the attacker direct access to your data.


So you must shut down your site immediately and handle this problem in a professional way:

  • If there's any user data in your database (password hashes, addresses, payment information etc.), consider it leaked. You must tell you users about that, because they may have a big problem now. For example, they might have used the same password for other websites.
  • All password hashes must be deleted. I really hope you've used a proper hash algorithm.
  • Check for injected data (new admin accounts, manipulated templates etc.).
  • SQL injections can in fact compromise the entire server (via SELECT ... INTO OUTFILE, for example). Was the MySQL user account of your application able to write external files? If you've used the root account, then the answer is “yes”.
  • Check your entire application as well as the system. Any strange files? Manipulations? Backdoors?

This is only the recovery procedure. After this, you need to make sure that the problem doesn't happen again:

  • Learn the basics of security. Seriously. You shouldn't even run a public website without a solid understanding of how to protect it.
  • Since you didn't know how to escape data up until now, you probably have SQL injection vulnerabilities everywhere in your code. The safest solution is to rewrite everything and use prepared statements instead (as already mentioned). Make sure you understand how they work. If in doubt, ask.
  • Secure the MySQL database itself. Keep permissions to the absolute minimum, check the connection settings etc.
Link to comment
Share on other sites

  • 2 weeks later...
Jacques and mac_gyver, as I stated that's the query that WOULD run but the code checks that the $_GET is an int. If it's not, the query doesn't run.


I guess I just don't know what is trying to be accomplished by this, had it executed...

WHERE p.id = 139\' and benchmark(20000000,sha1(1))-- 


... just an attempt to slowdown the server?


Jacques, since you didn't read the post that said the query didn't execute, your "I'm smarter than thou" remarks are really, really unwarranted. My gosh, this isn't the first time you've liked to show your arrogance on here. Calm down.


This application has been PCI-compliant and is tested monthly. It always passes compliance for injection and other hacks. I should have worded the topic better but the question was really... what does someone gain with this type of hack?

Edited by timneu22
Link to comment
Share on other sites

Gotta love those people who don't manage to write down a simple question and then blame us for not giving them the answers they wanted to hear.


Let's summarize: In your first post, you told us that you're seeing failed queries in your error log and that you're scared about “getting hacked”. We gave you the answer to this problem. Now you tell us that you actually generated the errors yourself, that your super-professional application is perfectly secure and that you're just curious how this particular injection technique works. Those are two entirely different stories, and they can't both be true.


So what is it? Is the second story now the official version, or will you come up with another one if you don't like what you hear?




what does someone gain with this type of hack?


Time-based Blind SQL injections.


It's a standard method of tools like sqlmap to test whether an application is vulnerable to SQL injections. If there's a delay, then obviously the BENCHMARK() call was executed, and that means the code is vulnerable.




This application has been PCI-compliant and is tested monthly. It always passes compliance for injection and other hacks.



Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.