Are there any tools for scanning for SQL injection vulnerabilities while logged in?

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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).

Answer 4

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.

Answer 5

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.

Answer 6

I am not aware of any tools that can do post-authentication SQL injection discovery via sqlmap, but I can describe the manual process here.

First, you login to a website, while capturing all the HTTP requests and response via setting up the browser using proxy, and Burpsuite as the proxy. Now we will focus only on the post-HTTP authenticated requests.

https://portswigger.net/support/configuring-firefox-to-work-with-burp#:~:text=Select%20the%20%22Manual%20proxy%20configuration,(by%20default%2C%208080).

Next use the Burpsuite to extract out the "curl" command to replay the URL against the webserver. Select those URL (usually POST request) that you actually have to provide input to the webserver. If you replay the entire URL against the webserver, most likely it will be successful. The POST URL should contain the cookie plus other parameters in the HTTP requests. Try experimenting with removing some of the HTTP headers, and you will realize that just the cookie alone sometimes DOES NOT work. (eg, the Asus router webserver, it does not just depends just on the cookie but other elements in the HTTP headers are involved as well). This is why sqlmap's "--cookie" may not work because authentication may be spread over multiple HTTP parameters in the headers. So "--headers" may be needed to successfully replay the URL requests. If you can replay successfully the URL (meaning the HTTP response does not contain "you have been logout" signature) then the entire curl command should work when modified to use "sqlmap" as the command instead.

The sqlmap parameter "--auth-type" and "--auth-cred" is only for preauthentication requests. For many authentication which I am aware of (eg, Asus router) it does not correspond to any of these types, and so there is no way to use this method. The reasons I suspect is because basic authentication is not secure - it is just "username:password" base64 encoded data passed directly over the web.

Answer 7

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.