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
    Commented Nov 11, 2015 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. Commented Nov 11, 2015 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. Commented Nov 12, 2015 at 3:21

1 Answer 1


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. Commented Nov 12, 2015 at 8:27
  • @NeilSmithline Rephrased the answer in order with some more explanation, see if this holds good. Commented Nov 12, 2015 at 13:46
  • Looks great. If I like the initial response of immediate takedown/prevention of further exploit. Commented Nov 12, 2015 at 21:13

You must log in to answer this question.

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