Continuous SQL injection testing

Question

We have a set of internal Python/Django web applications that are pretty well tested functionality-wise, but from time to time we do discover vulnerabilities and, specifically, places where SQL and other types of injections may happen. Currently, this is a very manual process requiring the knowledge of the system (white box).

But, is there a way to do an automated SQL injection test of all of our API endpoints of the applications under test?

I guess some of the things I don't understand now is: should we actually write the logic of these tests and examples for them and use, say, Python unittest framework, or is there a way to specify endpoints and possible parameters and let some security testing framework generate the malformed inputs to probe for SQL injections (sqlmap?) (the question is in a sense about whether it would be Example-based testing or Property-based testing)

Answer 1

I would like to look at this problem from a different point of view.

You've said that you found many SQLIs in different API endpoints in your application.

What exactly was the fix/mitigation for such an issue? And how is it possible that even after this fix another issues in another endpoints in the same application were found?

How exactly is the application structured?

My idea was to build like a tunnel where all the API request go through first and check the string against a whitelist of chars for ex. I believe there are libraries who could also do that pretty well.

Also most ORMs nowadays are doing this job for you.

Maybe it would also be interesting to know how exactly is the Data Access Layer in your application is built and try to refactor it and follow the OWASP cheatsheet in mitigating SQLis.

I'm not suggesting to ignore the Automating tests part. I'm more curious of why does this problem still exist after fixing it many times.

It's also impossible to say that you can totally eliminate such issues that's why even after finding a Generic solution for the whole application you may still need these automated tests.

Answer 2

You could script up example based testing pretty easily. With a sample request, sqlmap can do the rest. The only thing it doesnt do by default I believe is path paramters, but that as well could be incorporated into your script. The issue with this is that it will exponentially increase the amount of time it takes for unit tests to run and is generally not done this way because of that. Its up to you and your developers to determine if time added is acceptable. In my experience, it generally isn’t. You could also build somethig out that launches sql map in a separate thread, for example, when something is deployed to stage, and alert security if something is found. This way it wouldnt block your build. Example based testing would be the answer to your question though.

Answer 3

Interesting question!

You will need to automate multiple processes for this to work. There is no magic product (which I know of) that does this, but here is an algorithm:

1. Gather info about web servers running your SQL applications. This can be done easily via nmap -sS host-range -oX output.xml -p 80,443,8080,1080

2. Out of these found applications gather POST/GET parameters from output.xml file to put them under test. This can be done via curl and some bash scripting, or python XML parser with help of curl or wget.

3. Use the list of gathered POST/GET parameters request to feed into SQLMap to tests for SQL Injections. Something like this:

   for every POST/REQUEST in list { execute SQLMap -u link_from_list --risk 3 --level 3 if flagged as SQL Injection { report() } }

4. Investigate the report; eliminate false positives and finalize a report for the dev team to patch

5. Patch, patch, patch!

6. Start over at step [1]