liamb.com | IEnumerable(Thoughts)

We have been focusing on security lately and especially how to secure ASP.Net web applications that are hosted on the internet and available to anyone that comes across your web site.

I will be creating a number of posts with regards to web site security but I thought I would start with ASP.Net and how to configure settings in your web.config file to assist with securing your web site / web application.

1. Custom Errors Node

   Malicious users will start to interrogate your web site by attempting to see what sort of errors they can produce by exploiting your web site’s input such as the url, form fields and cookies.

   Based on the type of errors that are produced, they will be able to determine the type of technologies you are using, the web site’s structure or even database table names from the un-handled exceptions that are produced.

   By adding a custom errors node under the system.web section of your web.config file, you will prevent malicious users from gaining access to sensitive web site information when an un-handled exception occurs. The default redirect property of this node will redirect a user to your custom support page that displays a friendly message informing the user that an exception occurred and that they were redirected to the support page.
   
   <customErrors mode=“On” defaultRedirect=“support.aspx” />

2. HttpCookie Node

   One of the more common security problems plaguing web servers is cross-site scripting. Cross-site scripting is a server-side vulnerability that is often created when rendering user input as html. Cross-site scripting attacks can expose sensitive information about the users of a web site.

   Internet Explorer 6 SP1 introduced a new attribute for cookies that prevented them from being accessed through client side script. A cookie with this attribute is called an http only cookie and any information contained in these types of cookies is less likely to be disclosed to a malicious user or web site.

   To enable http only cookies via your web.config file use the http cookie node under the system.web section of your web.config file to implement the http only cookies feature. The require ssl property of this node should be set if your web site uses a secure connection.

   <httpCookies httpOnlyCookies=“true” requireSSL=“false” />

3. Session State Node

   Session hijacking is a form of identity theft where a malicious user impersonates a legitimate user by stealing his session token and gaining access to a web site.

   ASP.Net supports cookie free session state which instead of creating cookies for the session on the client, will add the session state information to the url of the web page. This will allow a malicious user a much easier way of obtaining identity and hidden information when added to the session and is not secure if left unencrypted.

   Ensure that you specify the cookieless attribute of the session state node to use coookies under the system.web section of your web.config file.

   <sessionState cookieless=“UseCookies” />

4. Trace Node

   The trace feature of ASP.Net is one of the most useful tools that you can use to ensure web application security by debugging and profiling your web applications.

   Unfortunately, it is also one of the most useful tools that a malicious user can use to attack your web applications if it is left enabled in a production environment. A malicious user can view an incredibly detailed list of recent requests to the web application by simply browsing to the page’s trace.axd file.

   The best way to prevent a malicious user from obtaining trace data from your web application is to disable the trace viewer completely by setting the enabled attribute of the trace node to false. If you have to have the trace viewer enabled, either to debug or to profile your web application, then be sure to set the local only attribute of the trace node to true under the system.web section of your web.config file. That allows users to access the trace viewer only from the web server and disables viewing it from any remote machine, increasing your web application security.

   <trace enabled=“false” localOnly=“true” pageOutput=“false“/>

5. Debugging Node

   A common mistake for ASP.Net developers to make is releasing web applications into a production environment with the debug attribute of the compilation section in the web.config file set to true.

   This common mistake is well known for causing performance degradation in web applications because of the debug symbols that are created when a web page is requested, can cause overhead.

   It is not so well known that if you have enabled debugging and disabled custom errors in your web application, then any error message displayed to an end user of your web application will include not only the server information, a detailed exception message, and a stack trace, but also the actual source code of the page where the error occurred.

   <compilation debug=“false“></compilation>

The above mentioned information and settings is just a start to securing your web application and ensuring that malicious users are going to have a hard time when attempting to attack, break or gain access to your web application. Security is an ongoing process and needs to be constantly reviewed, discussed, tested and improved when developing web applications. Even more so when the information you are collecting, storing and displaying on your web site is sensitive and or confidential.