What should (or) how an Incident Handler do (or) follow when an SQL injection attack is reported?

  1. Initial Response
  2. Analysis
  3. Action

Aiming to make a procedure guide to follow for myself and my team. Brief or detail, anything would help.

  • This is heavily dependent on your industry (and applicable rules/regulations) as well as any requirements specific to your application/database. You might not care (for example, if you're hosting publicly available data that you regularly update) or security might be critical to this DB (and you immediately shut down the DB). – Jesse K Nov 11 '15 at 18:56
  • 1
    @JesseKeilson SQL injection is almost never something you shouldn't care about. Sending arbitrary SQL commands to your database is almost always very bad, even if it's public data. The most obvious vulnerability is a DOS attack by sending many many costly requests to the DB. If the DB user allows write access, you could drop tables and destroy the application. – Steve Sether Nov 11 '15 at 20:47
  • @suspect01, is this for a product development team or on a production system? The difference is vital for handling the attack vector. – Andrew Philips Nov 12 '15 at 3:21

1) Initial Response can be taking the particular module/section of page offline or patch it on IPS or WAF. After that you should check the same yourself first with any web-proxy like Burpsuite or ZAP, if the reported vulnerability is false-positive or a real threat. You can also use a tool called SQLMAP to reduce the effort in verification.

2) For analysis part you can see, what sort of data you are able to get using that attack vector. Also you can see what roles are assigned to the web user and what privileges are granted. Depending upon the exposure and impact of vulnerability, you can decide the action.

3) For resolution, You can put server-side validation on the input vector. Also you can change the SQL statement in actual code to Parameterized SQL Query. A detailed procedure for mitigation can be found here. https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

PS: To prevent this from happening you should consider source code analysis at the time of development and after build is complete a dynamic application testing or Penetration Test. This will reduce the surprises in real-time.

  • While not incorrect, I'm not sure this really answers the question. – Neil Smithline Nov 12 '15 at 8:27
  • @NeilSmithline Rephrased the answer in order with some more explanation, see if this holds good. – Krishna Pandey Nov 12 '15 at 13:46
  • Looks great. If I like the initial response of immediate takedown/prevention of further exploit. – Neil Smithline Nov 12 '15 at 21:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.