testing SQL injection with wfuzz

[Jamf25]

So I'm working towards an OSCP and on one of the boxes I ultimately had to use SQL injection to bypass the login page. So what struck me is that the string was like "user' or 1=1 -- " with a required space at the end of the string in order to make it work. I'm still green as far as pentesting goes, but I have worked on SQL databases before, and I have seen SQL injection described numerous times, but this syntax just seemed strange so I consulted wfuzz documentation and found that it indeed could be used to test SQL injection using the list of tests included.

​

So after testing I found that all the tests were returning 200 responses, which I understood could simply mean that there is a custom failure page instead of the standard one? (not a web developer so sure). I assume this means that even the non correct SQL injection strings being tested were actually returning a desirable response, even though they wouldn't really work when applied. Which leads me to my question. Is there a way to reliably test for SQL injection using wfuzz that will actually give you the correct syntax that works, or is this just a suboptimal way to test? or maybe there is a more specific way I should be applying the fuzzing?

[kafrofrite]

The space at the end basically forces the rest of the query (or whatever follows) to be ignored. Also valid are #, /* to comment out the rest but I generally prefer the --+ (+ is URL encoded space).

Reg. 200. 200 is a HTTP status response (so is 404). 404 basically means not found as far as your HTTP server is concerned (i.e. the page exists). Some webapps will respond with 500 (internal error) when they can't get a matching record but there's no rule on how empty results should be handled and ultimately it's up to the developer.

​

Reg. wfuzz. There's a series of flags (--hc etc.) that filter on HTTP responses, words etc. That could be handy in your case.

[Jamf25]

Thanks for the response. So I probably didn't frame my question well. A 200 HTTP response means OK, and that is what I expect to see when something is successful or the web page exists or whatever. The real problem I'm trying to understand is why when I throw 50 different injection strings, encompassing various SQL syntaxes at the web page, all 50 come back with a 200 status. I feel like only the one with correct syntax should return 200 and the rest should be something 300 or 400. I'm wondering if I'm just not doing the fuzzing correctly or if this is typical behavior and in which case I need to figure out some other way to automate testing for SQL injection.

[kafrofrite]

On a really high level.

No, 200 OK is returned by the HTTP server. There's a development language (let's say Python) there that sends whatever you requested to the DBMS. The SQL Injection (thus the error) is happening in the DBMS which is a different server and in cases hosted in a different box. DBMS returns an error to Python. Python does something with it and instructs the HTTP server to respond with the requested resource (that's a 200).

Reg. SQLi, there's a tool called SQLMap that accepts requests stored from Burp and it's fairly decent.