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
Difference between revisions of "SCG WF ASPNET"
(Created page with "{{Template:OWASP Secure Configuration Guide}}") |
m |
||
| Line 1: | Line 1: | ||
{{Template:OWASP Secure Configuration Guide}} | {{Template: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; | ||
Revision as of 18:20, 9 March 2015
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;
