How strict should I be in rejecting unexpected HTTP request parameters redux?



  • I read this: How strict should I be in rejecting unexpected query parameters?

    Answer: No, do not error out on unexpected query string parameters.

    But I just got a requirement from our security guy that I must do so. Not only for unexpected query string, but also unexpected cookies, headers, and unexpected everything. Reasoning:

    It is possible that some component in the tech stack has a vulnerability like buffer overflow, sql injection, or other vulnerabilities of this sort. Unexpected data in requests may be a malicious attempt to find and exploit such a vulnerability. Therefore it is needed to return a 4xx response in such a situation. The blackbox should be configured to detect a spike of 4xx responses and react appropriately: ban the ip that produces such responses, notify the admin that the server is under attack, and the likes. The 4xx response is not meant for the attacker but for our security systems.

    I don't know... it seems to make sense, but it contradicts advice found in stack exchange sites.

    Where is the error of such reasoning?



  • ... but it contradicts advice found in stack exchange sites.

    First, the question you refer to has actually two answers. One which advises against returning an error and the other finding it a reasonable approach. And the votes for both answers are similar, so I would not treat any of these as a clear recommendation. What is the accepted answer is only the personal choice of the OP. So no actual contradiction here.

    Apart from that the situation you describe is different. There is a clear purpose given why the application should return an error - because an upstream security device will use these responses to detect anomal behavior and block the specific clients. It is even clearly stated that "The 4xx response is not meant for the attacker but for our security systems."

    In summary: the requirement you phase does not contradict previous recommendations at all. And it looks like a useful requirement for me for this specific use case.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2