3

We have built a web application using ASP.Net MVC3 and SQL Server 2008 which has features like credit card payment, etc. We engaged a 3rd party to perform vulnerability assessment and penetration testing.

We got a good report with few security issues. We have fixed all the issues except one.

In that report it says that our application reveals web directories such as 'Admin/Contact/Details' '/Areas/Admin/Styles/'. It is not major issue. But our management want to fix that too ...

Any ideas to solve it correctly and quickly. Appreciate if someone can shed some light on this.

Rory Alsop
  • 61,507
  • 12
  • 118
  • 322
Gayan Perera
  • 31
  • 1
  • 2
  • Not without knowing what your app does with these revealed directories. If they only have to be available to admins, and you already have a windows authentication in place, you could very easily hide them behind a login check. – Alexander Dec 01 '14 at 11:18
  • 1
    It sounds to me like those are standard ASP.NET MVC routes, and have nothing to do with actual directories.... which leads me to question the quality (and cluefullness) of the pentesters... – AviD Dec 01 '14 at 11:38
  • It didn't say anything about revealing paths, did it? If an error gave a local path in a response, this would make sense. – tuson Dec 01 '14 at 11:52

2 Answers2

4

It's a typical scenario with .NET MVC - search-engine friendly URLs are a direct result of proper implementation. But let's have something clear - these are not web directories, but MVC routes, right?

Paranoid pen-testers are often uncomfortable when the admin interface is somehow exposed in the URL, since it can attract unwanted attention, or be harvested and used for fuzzing.

If you want to improve on this, you may need to abuse the ASP.NET routing engine to obfuscate the path, if their concern is that the admin interface is "exposed" - that would be a quick fix, but obfuscation is never the correct way of fixing things.

An alternative is to use a resource manager and routing is based on resource tokens, but that would involve heavy modifications to the application. Each resource has its own resource token ID, and can be dynamically generated when a user logs in. Then every resource (page, style, image) is a link to the resource manager. Then getting a stylesheet will look like:

<link rel="stylesheet" type="text/css" href="/Resource/80af9420ab0401-00291844a/91009abff01">

The same applies to the URLs. This may result in a lot of overhead and poor performance, poor scalability, etc. I do not recommend it, but these days management just listens to whatever external "consultants" they're paying to, and refuses to acknowledge internal talent.

Unfortunately, sometimes it's a question of compromise - security should not be a result of poor scalability or performance...

Milen
  • 1,233
  • 8
  • 12
1

If these are directories then you can hide these. A good article is here: Solving the tyranny of HTTP 403 responses to directory browsing in ASP.NET:

You may not know this, but an HTTP 403 response when browsing to an empty directory is a serious security risk.

What the?! You mean if I go to my website which has a “scripts” folder where I put all my JavaScript and I have directory browsing disabled (as I rightly should) and the server returns a 403 “Forbidden” (which it rightly should), I’m putting my internet things at risks of being pwned?!

The summary of how to do this was to add this to the web.config:

<system.web>
  <customErrors>
    <error statusCode="404" redirect="/Error/PageNotFound?foo=bar" />
  </customErrors>
</system.web>
<system.webServer>
  <rewrite>
    <outboundRules>
      <rule name="Change location header" patternSyntax="ExactMatch">
        <match serverVariable="RESPONSE_location" pattern="/Error/PageNotFound?foo=bar" />
        <action type="Rewrite" value="/Error/PageNotFound" />
      </rule>
    </outboundRules>
  </rewrite>
  <httpErrors errorMode="Custom">
    <error statusCode="403" subStatusCode="14" path="/Error/PageNotFound" responseMode="Redirect" />
  </httpErrors>
  <defaultDocument enabled="false" />
</system.webServer>

If the report refers to MVC routes instead of directories, then you could still respond with a standard Page Not Found message so that the user is not informed of the presence of the admin page. Please note that this is not real security and should not be used in lieu of properly securing the admin pages (I realise you seem to be aware, but if anyone else finds your question I thought I'd make this clear). Admin users would then have to login using the login page and would not be able to go to the admin pages directly and be prompted for their credentials.

Community
  • 1
SilverlightFox
  • 34,178
  • 6
  • 73
  • 190