2

In the past I have dealt with security issues related to Default Service Banners/Verbose Headers/Information Leakage via HttpResponse Headers. These issues are quite common, and usually look something like this for an Asp.Net - IIS Server.

Server: Microsoft-IIS/10.0

X-AspNet-Version: 4.0.30319

X-Powered-By: ASP.NET

These types of issues are very common, and usually quite trivial to deal with, typically a web.config update or an URLRewrite rule to remove the verbose headers.

However, one issue I stumbled upon lately, is when the Server encounters an error, these headers are not removed. For example a 404 (not found) error will still have these headers appended on. In fact most error responses are not able to properly remove the information leakage headers. I did some searching and found out this issue is not very well documented, in fact it has never come up in one of our Pen-Tests specifically.

I am curious if any other developers have dealt with this issue, specifically information leakage in HttpResponse Headers when the response code is an Error. If so, how did you fix it. I am using Microsoft, Asp.Net, IIS technologies, but still curious if other technologies/servers have this issue.

MattyMerrix
  • 151
  • 6

3 Answers3

1

Thanks to Cody (my co-worker) for his response.

We have had many applications to mitigate this problem for. We've actually done it at the load balancer level, so that all responses, error or otherwise, are treated the same.

We're doing that with an iRule for F5 - iRules Home

https://clouddocs.f5.com/api/irules/

the irule has an array of blacklisted header names, and just removes those on every response

if you're trying to accomplish the same thing within AWS or some other managed load balancing mechanism, unfortunately i'm not sure how you would go about doing that

schroeder
  • 123,438
  • 55
  • 284
  • 319
MattyMerrix
  • 151
  • 6
0

My understanding is that although it's best practice to remove these informational headers, it doesn't give much protection as there are other ways attackers can characterise a server. For example different web servers might send other headers back in a different order, or might respond differently for error cases or edge cases.

If you have anything in front of your web server, it might be able to strip headers from the response. For example if using Amazon Web Services CloudFront CDN, you could use a Lambda function on the response to always strip the headers.

Chris Denning
  • 271
  • 1
  • 3
0

What you're trying to achieve is security through obscurity... Even though you can remove the headers, you can't really patch the detection mechanisms that easily.

You see, each web server (IIS in your example) has a certain signature and fingerprint. This means the web server also has a specific logic for dealing with some strange requests, other headers, timings, timeouts, reconnection attempts, handling of some exotic data etc etc.

You can theoretically change that behaviour in open source Web Servers, but IIS is not open source as far as I know. You could in theory reverse engineer it and try to rebuild it, but that's probably more effort than you're willing to spare.

So in my humble opinion, the best defence would be to just regularly update your web server and the OS as well. You could also use a reverse proxy/CDN provider like Cloudflare as Chris Denning suggested.

A information leakage would be when the equivalent of phpinfo would get leaked with environment variables containing secret keys (which is a bad practice in the first place!).

Sir Muffington
  • 1,447
  • 2
  • 9
  • 22