How strict should I be in rejecting unexpected query parameters?

Question

TL;DR Is it a "best practice" to return an HTTP 400 Bad Request response if extra parameters are sent with a request?

I'm putting together a web app and doings some testing with OWASP ZAP. I'm pretty happy with the results - the errors I get seem to be all low confidence and when I inspect the errors in detail, I'm finding that the ZAP tool really didn't change anything with the request. But that leads me to a "higher level" question, which is best explained with an example:

OWASP ZAP allegedly found an SQL injection with the following URL:

http://example.com/api/client/1?query=%27+AND+%271%27%35%271%27+--+

in "human-readable" form, that is:

http://example.com/api/client/1?query=query' AND '1'='1' --

Looks like a pretty standard SQL injection attack. Now, this endpoint is intended to return a client object in JSON form, and that's what this request does through OWASP ZAP. The server returned exactly what was expected, the client with ID=1. I'm doing everything that the OWASP ZAP docs recommend with respect to SQL injections, so what more should I do?

It occurs to me that I just don't know what OWASP ZAP expects to receive in response to this kind of attack - an error reponse, perhaps? The docs are helpful, in a "this is how to interface with the database" kind of way, but it's not clear to me if I need to respond with an error.

Should I return a 400 Bad Request error if inappropriate query parameters are provided?

Answer 1

No, you should not be returning a 400 if there are extra query parameters you do not expect.

Reasoning: You are actually making it easier to attack the application. By notifying the attacker that a particular parameter is invalid, they can easily start guessing parameters, and when they receive a 200 instead of a 400, they know they've found a valid parameter which they can try attacking by other means. Additionally, your application is no less secure when the false positive is reported. Adding logic to return a 400 is more work without an additional pay-off

Answer 2

Should I return a 400 Bad Request error if inappropriate query parameters are provided?

That is not a bad idea and along with a whitelist approach this can be used for a variety of scenarios.

Is it a "best practice" to return an HTTP 400 Bad Request

Well that is tricky question and to answer that you will have to look at variety of web application attack's and none of them will tell you that is the solution. While a whitelist can be a good approach but "best practice" is different for many a attacks.You specifically ask about SQL injection.SQL injection best practice is to use Prepared Statements (with Parameterized Queries).Try solving sql injection using a whitelist,you simply cant.

so what more should I do?

That takes us to "how to approach web application security?"

You need to understand that any automated attacks will most likely yield easy bugs.They also wont cover any logic attacks that your application might have.Apart from that in order to write secure web application code i would suggest OWASP CHEATSHEET SERIES (https://github.com/OWASP/CheatSheetSeries/tree/master/cheatsheets). I have yet to find anything better. Happy coding!.