Stack traces
The information disclosure we see most often while working are stack traces that are providing information in error messages about the underlying frameworks in use. You can also find other information in stack traces such as what parameters are expected by an endpoint which is undocumented. This is a great place to not return those stack traces since by not documenting something it is probably not intended for public use as an example. Stack traces are great for debugging, but best left disabled in production.
Server banners or headers
The second most common, and a lower severity, information disclosure we come across involves the default behavior of many technology stacks to return their version numbers in headers or banners. This is hard to say “turn this off” because it is not really an issue unless there is a known exploit against your version. Additionally, unless your environment requires the utmost obfuscation for additional security, yes security through obscurity is beneficial within reason, it is just not much of a gain. Still if it isn’t necessary to have on and you want one extra small layer of defense go ahead and disable these version numbers. That will at a minimum help when bots come crawling looking for un-patched servers to attack.
Other errors and response differences
Lastly we will touch on one of the actually interesting information disclosure. This is commonly found in conjunction with an IDOR. Let’s think of an API endpoint such as: www.mydomain.com/api/users/profile/123/edit in this simple example we are using the ‘123’ URL parameter to tell our server which user profile to edit. Now, even if we have proper authorization controls in place and we cannot simply say let me edit 122 we may be able to determine whether that user ID is live in the application.
This happens when we can retrieve varied responses for real and non-existent parameters. In this example maybe 122 returns a 401 unauthorized, but 124 returns a 404. This is a simplified example, and even in this specific case we have outlined the disclosure is not very useful. Where this can cause trouble is when one endpoint allows enumerations and another lacks authorization controls. In this case the information disclosure is a low severity, but could lead to more easily exploiting another issue if it were discovered. And for this reason it should be fixed even though it is a low severity because it is a simple fix to handle all failed requests with the same generic response.
Conclusion
So in summary these issues we feel are much more flexible with regard to “Fix those lows!”. With that said, always evaluate each situation for its merit as you would with any other vulnerability, and just bear in mind that many information disclosures are used to further other attacks. Even if you do not have another vulnerable area at the moment you may later. Sometimes we must consider that a stitch in time saves nine.
Are you looking for a security assessment for your network or applications? Send us an email at info@mccormackcyber.com
