Some pages of my website were vulnerable to SQL injection. The injection worked only when the user was logged in. I have now fixed this problem, and now I want to make sure that no similar problems remain. I have tried scanning with sqlninja and sqlmap but neither program has a provision to give website login details. Are there any tools that can scan for injection vulnerabilities with a logged in session?

  • The best tools proved for claim is a Havij Advanced SQL Injection tools by ITsec team. – user45570 Apr 28 '14 at 6:24

There is a cookie option in sqlmap :

--cookie=COOKIE HTTP Cookie header

So you just need to paste your cookie and you will be able to use sqlmap as if you were logged.

If you need the list of all the options : https://github.com/sqlmapproject/sqlmap/wiki/Usage


Let me offer you an easier alternative.

It is your website. You have access to the source code. Look through it and verify that all your database queries are parameterized. This is much much more efficient than scanning your website in the hopes that the tool you use tries the right injection at the right place.

  • ^ This is the best advice you can get, if there are parameters your tool does not test for, you are screwed. – Lucas Kauffman Jul 31 '13 at 9:45
  • 3
    The code is too big.Also If I get some scan report, I can submit it to my clients as proof. – Harikrishnan Jul 31 '13 at 9:53
  • 2
    You can't prove that code is secure - OTOH relying exclusivley on security by design (code review) without testing it is downright silly. SQLMap does support cookies - just login using a browser and copy the cookie into your test script. – symcbean Jul 31 '13 at 12:48
  • 3
    @symcbean I respectfully disagree. Some attacks are pretty difficult to secure against just through code reviews but SQL injection isn't one of them. Just ensure that every single database call is parameterized and you will be fine. – Ayrx Jul 31 '13 at 12:55
  • 1
    @symcbean and Terry, I don't think there's any disagreement here. Both of you are saying the right thing. Both of you have good suggestions, now we just have to combine both of them. Review the code + test with tools = Good stuff. – Adi Jul 31 '13 at 13:03

You don't "fix" SQL injection problems. Well, people do, but that's wrong. What you must do is not to allow them to happen in the first place. The main tool for that is, as @TerryChia points out, parameterized SQL statements. Parameterized SQL statements are very effective at preventing SQL injection attacks, by being a generic and thorough solution; this is much better, incomparably better, than any kind of "input data sanitation".

SQL injection attacks occur because the Web site is trying to interpret user-provided data (field contents) as code (SQL is a programming language, after all). This implementation strategy is doomed. It cannot be really "fixed"; see this answer for some conceptual discussion on this subject.

"When the only tool you have is a hammer, then all problems have better be nails, because you're gonna hit them repeatedly on the head." Be aware that parameterized SQL statements, though widely applicable and efficient (more than traditional "dynamic" SQL statements), cannot do everything; there are very rare and specific contexts where dynamically building up SQL statements is the only solution. But this is not your situation -- you would already know it, and also all that I write in this answer.

SQL injection "testing tools" are not satisfactory in any way: they are not meant for ensuring security, but for attacking the "low-hanging fruit". They will miss the overwhelming majority of possible SQL injections. Their purpose is to allow a non-technical attacker to nevertheless believe he is some kind of elite-level hacker; or to automate attack attempts on thousands of distinct sites. What these tools will tell you is one-way: if they succeed in breaking into your site, then you know that the site is extremely vulnerable; however, if they fail, then you know nothing.

Nevertheless, if you want to get a tool past a "login session" system (despite all that I have explained above), then it depends on how the login is managed. Most Web sites will use a "login page" which results in setting a cookie value in the client; that cookie represents the "logged in" state and it suffices to send it back to the server to be considered as part of the "session". SQL injection test tools allow you to include arbitrary cookie values in the request, which is what you are asking for. See, for instance, the sqlninja documentation (search for the second occurrence of the "cookie" word in that page).


You can use webslayer. https://www.owasp.org/index.php/Category:OWASP_Webslayer_Project.

Webslayer is an application brute force/Fuzz application. To check the injection after login, follow these steps.

You will need the following, A browser and an intercepting proxy like webscarab (or tamper data addon of firefox will do.).

  1. Login into the application using the browser.
  2. Using the intercepting method, get the cookies of the logged in session. (If you are using webscarab or an intercepting proxy, you can copy all the request headers.)
  3. Start webslayer and paste the details into the headers coloumn in webslayer.
  4. Input the URL/Request you want to test SQL injection against.
  5. Add "FUZZ" as the keyword where you want to test for injection
  6. Select your payload
  7. Hit start

Steps 3 - 7 is the standard working of webslayer, which you can get a tutorial on. There are lot of videos for that in Youtube like (http://www.youtube.com/watch?v=QGNyvXIcky4)

This will help test any injection vulnerabilities in a logged in session.


Most well-written web applications have a central login or session validation logic. What I do in these cases is simply comment out that part of the code in the development server. Now all my tools have access to all of the functionalities.


Parameterized SQL statements is the only reliable answer to your probem. Maybe sqlmap or havij fail to identify the vulnerable parameter but a determined and skilful hacker might. So, to be on the safe side secure sanitize all your database queries.

protected by Community Apr 28 '14 at 6:55

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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