Hacker News Reader

Comment by kolektiv | Hacker News Reader

Well, yes .NET (IIS, specifically) does have a poor default (or rather, the default *.config files created by things like VS have poor defaults). However, hiding the error isn't really enough. Yes, it doesn't expose very many things. But it has exposed, of course, that you're running IIS. And the site is .NET in some form.

Those might not seem a big deal, but you've just provided quite a lot of hints about what the attack surface looks like. Most vulnerability scans will flag up "leakage" of data. IIS also does annoying things by default like "powered by IIS" type HTTP headers (it's not alone in that of course). You'll usually be warned to switch that off because you don't want to make attacks easier than they otherwise would be. Internal error form leakage is just another example.

View on HN

It's harder than that to hide what server you're using. And keeping such a secret is barely worth it. You can test for characteristics or exploits of all the common servers easily. And it's pretty hard to hide all implementation details. At a glance through the source I can see it's using .axd files and microsoft webforms ajax with a specific version.

Most (all?) web servers stick their names in a header. I've never heard that that is controversial from a security POV. Also, .NET apps are incredibly recognisable from a quick glance of the source code (__doPostBack and VIEWSTATE are two easy tells). Again, most popular web app frameworks leave some hints in the source that makes it fairly easy to figure out what they are (utf8=✓ in rails).

It's harder to detect the framework when ASP.NET MVC is used. No view state in the source code, no .aspx extensions and the server response headers identifying IIS and ASP.NET can be removed. There's always HTTP server fingerprinting but you're moving on past the low-hanging fruit now.

Well, after removing all the default headers, there's the CSRF token, certain paths that will bypass a regular 404 detection, and so on... There are ways.

Most vulnerability scans inflate their findings with non-security stuff because it brings more business and false positives are always well received by management (less by those who actually has to evaluate the results technically). Better safe than sorry, they say. However, I have hard time seeing how it is a security vulnerability. Discovering IIS server is easy anyway, unless you take very special precautions which 99.999% of people never do, and any automated exploit tool that wanders on the site would do that discovery anyway, so would any focused attacker. So this specific thing is not nice, it looks unprofessional, it may annoy or scare the users that accidentally type a wrong thing, but I do not see how it's security related.

IIS still defaults to adding 'served by ASP.Net' as a 'x-powered-by'. Something I again often forget to remove. And certain versions of MVC you have to jump through hoops to remove their x-aspnetmvc-version. And on top of that you can often tell by just looking at which js files have been included. Is it using MS js files? Yes, then it's 99% IIS with ASP.Net.

So that's not what I, or I would think any reasonable developer, would considered even a vague security concern as an experienced developer with exposure to a few different frameworks can often tell the platform, and thus the probable server, by just looking at the HTML.

If it were a serious security concern MS would have patched the header by now! Instead they've added even more with MVC.

So are there any other reasons? Or is Troy just wrong in this instance?

There's a good NuGet package for dealing with this now: http://brendanforster.com/blog/custom-server-headers-bad-for...

Reply on news.ycombinator.com