MVC Application Security Issues: Software Information & Header Sensitive Data - Part Two

Background

In my previous article, I’ve explained what are the different types of third party attacks possible during client-server request/response exchanges. We also concluded why we need our website to run on “HTTPS” instead of “HTTP”, also we’ve seen the need of SSL enabled environment.

In this article, we will go one step up and will cover scenarios which are related to software information (could be version or framework or language information). If a third party person senses this information, he will manipulate user’s sensitive data with the help of protocols/syntax used in that particular technology or used in that particular software version.



Problem (Software Specific Information visible to end user)

Developer can use any technology to develop a website, could be JSP, Servlets, ASP.Net MVC etc., if I give an example say X developer is using ASP.Net MVC to build a website. Now, when we deploy a website into production, the assemblies (assembly information & other attributes) which have been deployed with “Debug” mode would be different from those deployed with “Release” mode. But, if you observe the headers during the process of request – response, you will find the sensitive information in the request/response header.

When client requests the data from server, server returns response header which contains ASP.Net MVC version, IIS/server version along with several other fields. So, third party attacker senses the information & that information can be used to search the pattern or syntax, specific to that version/framework. This increases the chances of an attack & also an attacker can plan a more focused attack on the application.

If you use Google Chrome, debug the browser pressing F12 which opens “Inspect Element” window. Refresh the page, you will observe the following in Network tab –

Headers

• Server: Microsoft-IIS/7.5
• X-AspNetMvc-Version: 4.0
• X-AspNet-Version: 4.0.30319

Solution



If the response header returns information about MVC version number say, MVC 4, attacker would know the MVC protocols to call controller and invoke Action corresponding to that controller, and he will plan accordingly. To avoid this situation, we need to remove the unwanted HTTP header field values from the response. Following are the three response header values which we may want to remove for security reasons –

1. Server – Indicates which web server version is used.
2. X-Powered-By – Indicates the website is powered by which? Like, “powered by ASP.Net.”
3. X-aspnet-Version – Indicates the version of ASP.Net is Used.

URL Rewrite

Developer can use the URL Rewrite module to remove the unnecessary values from server header. Please make a note – This tool won’t remove the actual header field, it will only remove the values contain by the header.

How to do

Step 1: Install URL Rewrite. You can use this URL to download & install into IIS.

Step 2: In IIS, in the left panel, click on the website you want to remove the server headers from, after click on that, at the right side, you will see the “URL Rewrite” option, click on that option.



Step 3: Inside that option, click on “View Server Variables” in the Actions pane at the right hand side.



Step 4: Click on the Add button at the right hand side, and then enter “RESPONSE_SERVER” in the given textbox.



Step 5: After this configuration, an “outbound rule” needs to be created.

In Web.config file, we need to include following section under configuration->system.webServer element:

<rewrite>
    <outboundRules>
        <rule name="Remove RESPONSE_SERVER">
            <match serverVariable="RESPONSE_SERVER" pattern=".+" />
            <action type="Rewrite" value="" /> </rule>
    </outboundRules>
</rewrite>

If you follow the above steps, you will observer that the server/version specific values will be blank in the response header.

Another Problem

Using the above solution, the problem of exposing version & server information with response header will be resolved. Next problem is, if any uncaught error occurs during execution of an application. In such case, if any uncaught error encounters, the application will respond with an exception stack trace.

For example,

HttpException

at System.Web.CachedPathData.GetPhysicalPath(VirtualPath Path)
at System.Web.HttpContext.GetFilePathData()
at System.Web.Configuration.CustomErrorsSection.GetSettings(HttpContext context, Boolean canThrow)
at System.Web.HttpResponse.ReportRuntimeError(Exception e, Boolean canThrow, Boolean localExecute)

This potentially reveals the details of internal technologies to third party attackers.



Solution

Web.config has an element <httpErrors>, with the help of this element developer can be able to handle internal errors & send custom error messages as a response to user’s browser. Using this, the detailed error message (i.e. exception stack trace) won’t be exposed to end user. The response will be more user friendly. It will also help when particular user’s request fails & developer doesn’t want to let user know about internal error, then web page which encounters an error can be redirected to some other URL to re-perform the operation.

<HttpErrors> Attributes

This element has “errorMode” attribute which performs at the IIS level. It decides how the response should return to the user’s browser.

3 type of values you can set for “errorMode” attribute –

 

1. DetailedLocalOnly – This is the default value if you don’t define “errorMode” attribute. Using this value, IIS returned an error at server level. That means, it will log a detailed error to server’s browser, but for an end user, custom error response will be sent. The exception or detailed error won’t be shown on end user’s browser. In that case, the developer will also get to know about internal error as well as the detailed error would not be exposed outside the server so attacker won’t figure out the internal technologies.
   
   
2. Custom – Using this value, IIS will return custom message to all browsers including the server browser. In this case, developer won’t find what the exact detailed error is.
   
   
3. Detailed – Using this value, IIS will return detailed error information to all browsers including the server browser. This value should not be used to resist technical information to be exposed.

Another attribute is “existingResponse” which is optional, defines the IIS behaviour for existing response when server returns HTTP status error code.

3 type of values you can set for “existingResponse” attribute –

1. Auto – It will leave the existing response untouched. For that, you need to set “SetStatus” flag.
   
   
2. Replace – It will replace the existing response with new one.
   
   
3. PassThrough – If existing response is present, it will leave that response untouched.

Example to show how to set values –

<httpErrors errorMode="DetailedLocalOnly" existingResponse="Replace" />

In Web.config file.

Conclusion

With previous ones and this article, I’ve covered all possible scenarios, all possible situations where a website attack would be possible. With ASP.net MVC, all these configs, methods, elements which I’ve explained in this two-part series, a developer has to implement these techniques to make the website/application secure from third party attackers. I hope, like my previous article on security issues, this article would also be helpful for all MVC developers.