ASP.NET Pages and Controls | Improving Web Application Security: Threats and Countermeasures

Use the review questions in this section to review your ASP.NET pages and controls. For more information about the issues raised in this section, see Chapter 10, "Building Secure ASP.NET Pages and Controls."

Do you disable detailed error messages?
Do you disable tracing?
Do you validate form field input?
Are you vulnerable to XSS attacks?
Do you validate query string and cookie input?
Do you rely on HTTP headers for security?
Do you secure view state?
Do you prevent XSS?
Are your global.asax event handlers secure?
Do you provide adequate authorization?

Do You Disable Detailed Error Messages?

If you let an exception propagate beyond the application boundary, ASP.NET can return detailed information to the caller. This includes full stack traces and other information that is useful to an attacker. Check the <customErrors> element and ensure that the mode attribute is set to " On " or " RemoteOnly ".

 <customErrors mode="On" defaultRedirect="YourErrorPage.htm" />

Do You Disable Tracing?

Trace information is also extremely useful to attackers . Check the <trace> element to ensure that tracing is disabled.

 <trace enabled="false" localOnly="true" pageOutput="false"        requestLimit="10" traceMode="SortByTime"/>

Do You Validate Form Field Input?

Attackers can pass malicious input to your Web pages and controls through posted form fields. Check that you validate all form field input including hidden form fields. Validate them for type, range, format, and length. Use the following questions to review your ASP.NET input processing:

Does your input include a file name or file path ?

You should generally avoid this because it is a high risk operation. Why do you need the user to specify a file name or path, rather than the application choosing the location based on the user identity?

If you accept file names and paths as input, your code is vulnerable to canonicalization bugs . If you must accept path input from the user, then check that it is validated as a safe path and canonicalized. Check that the code uses System.IO.Path.GetFullPath .
Do you call MapPath?

If you call MapPath with a user supplied file name, check that your code uses the override of HttpRequest.MapPath that accepts a bool parameter, which prevents cross-application mapping.
```
 try {   string mappedPath = Request.MapPath( inputPath.Text,                                        Request.ApplicationPath, false); } catch (HttpException) {   // Cross application mapping attempted. } 
```
For more information see, section "Using MapPath" in Chapter 10, "Building Secure ASP.NET Pages and Controls."
How do you validate data types?

Check that your code validates the data type of the data received from posted form fields and other forms of Web input such as query strings. For non-string data, check that your code uses the .NET Framework type system to perform the type checks. You can convert the string input to a strongly typed object, and capture any type conversion exceptions. For example, if a field contains a date, use it to construct a System.DateTime object. If it contains an age in years , convert it to a System.Int32 object by using Int32.Parse and capture format exceptions.
How do you validate string types?

Check that input strings are validated for length and an acceptable set of characters and patterns by using regular expressions. You can use a RegularExpressionValidator validation control or use the RegEx class directly. Do not search for invalid data; only search for the information format you know is correct.
Do you use validation controls?

If you use a validation control such as RegularExpressionValidator, RequiredFieldValidator , CompareValidator , RangeValidator , or CustomValidator, check that you have not disabled the server side validation and are not relying purely on client-side validation.
Do you rely on client side validation?

Do not do this. Use client-side validation only to improve the user experience. Check that all input is validated at the server.

Are You Vulnerable to XSS Attacks?

Be sure to review your Web pages for XSS vulnerabilities. For more information, see "Cross-Site Scripting (XSS)" earlier in this chapter.

Do You Validate Query String and Cookie Input?

Check that your code validates input fields passed by URL query strings and input fields extracted from cookies. To locate vulnerable code search for the following text strings:

"Request.QueryString"
"Request.Cookies"

Check that input is validated for type, range, format, and length using typed objects, and regular expressions as you would for form fields (see the previous section, "Do You Validate Form Field Input?"). Also consider HTML or URL encoding any output derived from user input, as this will negate any invalid constructs that could lead to XSS bugs.

Do You Secure View State?

If your application uses view state, is it tamperproof? Review the following questions:

Is view state protection enabled at the application level?

Check the enableViewState attribute of the <pages> element in the application Machine.config or Web.config file to see if view state is enabled at the application level. Then check that enableViewStateMac is set to "true" to ensure it is tamperproof.
```
 <pages enableViewState="true" enableViewStateMac="true" /> 
```
Do you override view state protection on a per page basis?

Check the page-level directive at the top of your Web pages to verify that view state is enabled for the page. Look for the enableViewStateMac setting and if present check that it is set to " true" . If enableViewStateMac is not present and set to true , the page assumes the application-level default setting specified in the Web.config file. If you have disabled view state for the page by setting enableViewState to " false " the protection setting is irrelevant.
Do you override view state protection in code?

Check that your code does not disable view state protection by setting Page.EnableViewStateMac property to false . This is a safe setting only if the page does not use view state.

Are Your Global.asax Event Handlers Secure?

The global.asax file contains event handling code for application-level events generated by ASP.NET and by HTTP modules. Review the following event handlers to ensure that the code does not contain vulnerabilities:

Application_Start . Code placed here runs under the security context of the ASP.NET process account, not the impersonated user.
Application_BeginRequest . Code placed here runs under the security context of the ASP.NET process account, or the impersonated user.
Application_EndRequest . If you need to modify the properties of outgoing cookies, for example to set the "Secure" bit or the domain, Application_EndRequest is the right place to do it.
Application_AuthenticateRequest . This performs user authentication.
Application_Error . The security context when this event handler is called can have an impact on writing the Windows event log. The security context might be the process account or the impersonated account.
protected void Session_End . This event is fired non-deterministically and only for in-process session state modes.

Do You Provide Adequate Authorization?

Review the following questions to verify your authorization approach:

Do you partition your Web site between restricted and public access areas?

If your Web application requires users to complete authentication before they can access specific pages, check that the restricted pages are placed in a separate directory from publicly accessible pages. This allows you to configure the restricted directory to require SSL. It also helps you to ensure that authentication cookies are not passed over unencrypted sessions using HTTP.
How do you protect access to restricted pages?

If you use Windows authentication, have you configured NTFS permissions on the page (or the folder that contains the restricted pages) to allow access only to authorized users?

Have you configured the <authorization> element to specify which users and groups of users can access specific pages?
How do you protect access to page classes?

Have you use added principal permission demands to your classes to determine which users and groups of users can access the classes?
Do you use Server.Transfer?

If you use Server.Transfer to transfer a user to another page, ensure that the currently authenticated user is authorized to access the target page. If you use Server.Transfer to a page that the user is not authorized to view, the page is still processed .

Server.Transfer uses a different module to process the page rather than making another request from the server, which would force authorization. Do not use Server.Transfer if security is a concern on the target Web page. Use HttpResponse.Redirect instead.