This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

SCG WF ASPNET

From OWASP
Revision as of 18:28, 9 March 2015 by Dvvord (talk | contribs)

Jump to: navigation, search
This article is part of the OWASP Secure Configuration Guide.
Back to the OWASP Secure Configuration Guide ToC: https://www.owasp.org/index.php/Secure_Configuration_Guide Back to the OWASP Secure Configuration Guide Project: https://www.owasp.org/index.php/OWASP_Secure_Configuration_Guide


Summary

ASP.NET server-side Web application framework designed for Web development to produce dynamic Web pages. It was developed by Microsoft to allow programmers to build dynamic web sites, web applications and web services. It was first released in January 2002 with version 1.0 of the .NET Framework, and is the successor to Microsoft's Active Server Pages (ASP) technology. ASP.NET is built on the Common Language Runtime (CLR), allowing programmers to write ASP.NET code using any supported .NET language. The ASP.NET SOAP extension framework allows ASP.NET components to process SOAP messages. ASP.NET is in the process of being re-implemented as a modern and modular web framework, together with other frameworks like Entity Framework. The new framework will make use of the new open-source .NET Compiler Platform (code-name "Roslyn") and be cross platform. ASP.NET MVC, ASP.NET Web API, and ASP.NET Web Pages (a platform using only Razor pages) will merge into a unified MVC 6.[3] The project is called "ASP.NET vNext".


Common Misconfigurations

Tracing misconfiguration

Description

Trace.axd is an Http Handler for .NET  that can be used to view the trace details for an application. ASP.NET tracing enables you to view diagnostic information about a single request for an ASP.NET page. ASP.NET tracing enables you to follow a page's execution path, display diagnostic information at run time, and debug your application. When it's enabled in a production environment, it poses a disclosure risk by exposing information about the internal operation of the page. A request to this file through a browser displays the trace log of the last n requests in time-order, where n is an integer determined by the value set by requestLimit="[n]" in the application’s configuration file.

How to test

Make a request http://[target]/trace.axd Tracing does not appear to be ON as the request didn't return a page with a heading called "Application Trace". File:TraceAXD.png

Remediation

Trace can be disabled inside web.config file. <configuration> <system.web> <trace enabled="false"/> </system.web> </configuration> Trace can be configured at page level with @Page directive, so when going to production remove those settings from pages or turn them off.


Custom errors misconfiguration

Description

Custom errors are used to ensure that internal error messages are not exposed to end users. Custom errors can include Framework version, Stack Trace. This information can be leveraged to exploit the application as it discloses potentially sensitive information about the internal implementation of the website. Instead, a custom error message should be returned which provides a friendlier user experience and keeps potentially sensitive internal implementation information away from public view.

How to test

Make a request http://[target]/<random_page>.aspx

Another way is if Page receive param (like ID) you can duplicate this param in request ID=1&ID=1 That will cause framework to show error page.

If custom error mode in turned off you will see detailed error description formed by asp.net framework.

Remediation

Turn ON CustomErrors mode that will prevent disclosure of technical information.

<configuration> <system.web> <customErrors mode="On"> </system.web> </configuration>


Hash DoS misconfiguration

Description

The hash table denial of service vulnerability (hash DoS) allows an attacker to make a POST request with a very large number of parameters constructed to cause hash collisions when parsed by ASP.NET. These collisions are very computationally expensive and could subsequently cause the CPU utilization to spike thus disallowing it to process legitimate requests. Microsoft patched the risk in security update MS11-100 then resolved it permanently with the release of .NET 4.5.

How to test

A POST request with 1,001 form parameters named "0" through to "1000". Check if any differences occurs when web-application process such requests. Time differences, some error responses.

Remediation

Install MS11-100 patch


ELMAH log misconfiguration

Description

ELMAH is used extensively by ASP.NET websites for error logging and handling. When improperly configured, ELMAH error logs can be easily viewed without any access controls thus exposing potentially sensitive information about the website.

How to test

Request http://[target]/elmah.axd

You must see page with "Error Log for" text

Remediation

In order to provide a customization mechanism for the features ELMAH requires the configuration file to contain specific sections declarations under the root configuration node, as shown in the following snippet. <configSections>       <sectionGroup name="elmah">         <section name="security" requirePermission="false" type="Elmah.SecuritySectionHandler, Elmah" />       </sectionGroup>     </configSections>

There's a default section group named elmah which contains custom configuration sections to tune several aspects concerning security.

Notice the presence of the requirePermission attribute declaration. Note: The requirePermission attribute is new to ASP.NET 2.0 and it's not recognized by ASP.NET 1.x, thus it must be omitted in that environment.

Configure ELMAH Log access.

<elmah>  
   <security allowRemoteAccess="0" />  

</elmah>


Excessive headers misconfiguration

Description

By default, excessive information about the server and frameworks used by an ASP.NET application are returned in the response headers. These headers can be used to help identify security flaws which may exist as a result of the choice of technology exposed in these headers.

How to test

Make a request to web-application and check HTTP response headers. You can use Fiddler, Burp, ZAP or other web-proxy. File:Headers.png

Remediation

Configuring the application to not return unnecessary headers keeps this information silent and makes it significantly more difficult to identify the underlying frameworks. <system.web>

 <httpRuntime enableVersionHeader="false" />

</system.web>

Go into the IIS configuration of the website and locate the “HTTP Response Headers”  And remove X-Power-By header.

The MVC version is also easy, although it does require us to touch code. Over in the Global.asax, we want to jump into the Application_Start event and add the following: MvcHandler.DisableMvcResponseHeader = true;