Hacker News Reader

Comment by mattmanser | Hacker News Reader

Re: telegraphcottages.co.uk

How is that a security hole? It's actually .Net having a bad default configuration for ASP.Net MVC, a lot of us made this same mistake when doing our first MVC projects. It's not actually exposing anything dangerous (in fact it's hiding the actual error like it should do).

The actual error will be something like this:

http://stackoverflow.com/questions/5967103/a-potentially-dan...

It's .Net disallowing at the root level and if you don't know about it, you can't code for it.

Or am I missing something? Given it's Troy Hunt who's usually quite knowledgeable about this stuff, I'm confused?

View on HN

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.

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...

What it shows is that the server is not configured to return a custom error page when an exception occurs. Beyond the obvious usability issue, this may be used by an attacker to identify sites that leak internal information. It's not a vulnerability per se, but it's a gateway to helping find them.

More info: https://asafaweb.com/Scan?Url=telegraphcottages.co.uk#Custom...

this may be used by an attacker to identify sites that leak internal information

But what does that even mean? We've already discussed below that thinking you can hide an ASP.Net MVC site is wishful thinking unless you totally strip out every identifying part of the framework client-side, there are so many ways I can think of, including the ones below, like the js libraries, the CSRF style, the CSS style the validation uses, the wrapping of JSON responses in a object named d, etc. etc.

I even have vague recollections of coming across odd behaviours in IIS when it sends the allow-continue header in certain scenarios that no other webserver does. Though I can't remember the details now so might be wrong there.

I think you should stop classifying this as a vulnerability and just call it what it actually is, a misconfiguration.

I do like asafaweb, nice tool.

Reply on news.ycombinator.com