Dealing with Information Leakage in HttpResponse Headers on Server Error
In the past, I have dealt with security issues related to Default Service Banners, Verbose Headers, and Information Leakage via HttpResponse Headers. These issues are common and can be easily resolved with a web.config update or an URLRewrite rule. However, I recently stumbled upon a new issue where these headers are not removed when the server encounters an error.
When the response code is an error, such as a 404 (not found) error, the information leakage headers are still present. Surprisingly, this issue is not well-documented and has never come up in our Pen-Tests. I am curious to know if other developers have faced this issue and how they have resolved it.
Thanks to my co-worker, Cody, we have found a solution to mitigate this problem at the load balancer level. By using an iRule for F5, we can remove the blacklisted header names from every response, regardless of whether it is an error or not. You can learn more about iRules here.
If you are using AWS or another managed load balancing mechanism, I’m afraid I am not familiar with the specific steps to accomplish this. However, I recommend exploring the documentation or seeking assistance from the support team of your chosen platform.