Turn off GZIP

Chrome was trying to decompress .NET issued JS valdiation files, which were already cached causing issues, when refreshing the browser.

This was causing the Page_Validators ( .NET JS Validators ) being unset and all client side javascript validation was not running.

You can prevent chrome/firefox dev tools from caching content but I got IIS to stop compressing the content within th web.config. Obviously don’t leave this on in production and only add this into the web.config.debug.


 <urlCompression doStaticCompression="false" doDynamicCompression="false"/>


OWASP Top 10 #6 – Security Misconfiguration

What Is It?

Security misconfiguration is anything which is considered insecure due to the settings or configuration upon a server.

This can be anything from debug settings being turned on or even out of date third party frameworks being used.

Custom Errors

Leaking of information about the implemented technology stack could be an invitation for hackers to probe a system further. With regards to an SQL injection attack, error messages can be used to view details about the database schema such as table names and then further be used to display the contents of a database table.

Error messages displayed to a user should contain information useful to the user only and nothing else. They should report to the user the minimal amount information for them to react to the error.

Any information such as details of the error or the trace stack should be hidden from the user.

We can disable the standard .NET ‘yellow’ error message which contains the trace stack and the details of the error on a site basis. This is done within the customErrors node of the web.config

&lt;customErrors mode=&quot;On&quot; defaultRedirect=&quot;Error.aspx&quot; /&gt;

The mode attribute can contain the following values:

  • On
    • Errors are reported in full. This is the default value.
  • Off
    • Errors are not reported. The user is redirected to the page defined within the defaultRedirect attribute
  • RemoteOnly
    • Users viewing the site on their local host are reported the errors in full
    • Users not viewing the site on their local host are redirected to the page defined within the defaultRedirect attribute.

If no defaultRedirect is provided the user is presented with a http response code of 500. This in itself is bad as it highlights our site as a potential site worthy of more probing by a hacker. The status code is easily read by batch scripts probing sites.

Providing a defaultRedirect presents the user with the page defined by the attribute along with a http status code of 302 (temporary redirect). This unfortunately creates a query string parameter of aspxerrorpath set to the relative URL of the page which caused the error. This can also be easily used by batch scripts to determine if a page is an error page.

We can redirect to the error page without the indicating that there was an error by changing the RedirectMode from ResponseRedirect (default) to ResponseRewrite.

&lt;customErrors mode=&quot;On&quot; defaultRedirect=&quot;Error.aspx&quot; RedirectMode=&quot;ResponseRewrite&quot; /&gt;

With this set, the contents of the error page is simply set to the response of the request without a redirect. The http status code is set to 200 which is the OK code. The hacker would need to read the contents of the page to try and determine if the page is an error page. This in itself is harder and slower. Anything we can do to slow down the hacker reduces the amount of hacking they can do on our site.

Disabling Trace

Trace information allows collecting, viewing and analysis of debug information that is collected and cached by ASP.NET. The information can be viewed at the bottom of individual pages or within the trace viewer which is accessed by calling the Trace.axd page from the route directory of the web site.

Like any debug information it contains details of implemented technology and potentially sensitive information that might be logged by accident. There are many instances of security issues where personal information such as credit card details or user accounts used in database connection strings which are logged as part of the debugging.

Tracing should be disabled within the web.config for all production environments.

&lt;trace enabled=&quot;false&quot; /&gt;

Keep Frameworks/Third Party Code Up To Date

All third party frameworks should be kept up to date to ensure that you are protected from any security issues which have been fixed within them.

With the use of NuGet this can be achieved very easily.

Encrypting Sensitive Parts Of The Web.Config

Sensitive data such as user accounts, passwords and private keys that are contained within the web.config should be encrypted.

If they are accidentally exposed to the user during an error while accessing a page or logged into an audit table and viewed by someone who should not see them, their details will not be readable.

It is also a good idea to reduce the amount of people who have access to sensitive information.

You can encrypt a node of a web.config at the visual studio command prompt by the following:

aspnet_regiis -site &quot;Site Name In IIS&quot; -app &quot;/&quot; -pe &quot;connectionStrings&quot;

This will update the web.config replacing the sensitive information with an encrypted version.

The file can be decrypted with the following command:

aspnet_regiis -site &quot;Site Name In IIS&quot; -app &quot;/&quot; -pd &quot;connectionStrings&quot;

This process uses a key which is created based upon the servers MAC address and as such is unique to the server and therefore can only be decrypted upon the web server.

Using Config Transforms To Ensure Secure Configurations

It can be very easy to leave debug settings such as non custom errors and tracing within a web.config.

Transforms for debug and release can be used to ensure that only settings for the required release are used when that release target is used.

Use Web.Release.Config to transform the Web.Config for release:

  • Remove debug attributes
  • Add custom errors
  • Remove trace

These transforms are only run during a site publish.

Retail Mode

Retail mode can be used as a back stop to ensure that no web.config setting which is considered unsafe in a production environment is actually enabled. For example in retail mode, turning off custom errors or turning on tracing will have no effect.

This setting can be set in the web.config though it is recommended to set it within the machine.config of the web server.

&lt;deployment retail=&quot;true&quot; /&gt;

OWASP Top 10 #5 – Cross Site Request Forgery (CSRF)

What Is It?

Before we talk about CSRF it is important to understand that all cookies created by a domain are sent back to that domain during page requests regardless which domain the page originated from. This includes cookies which contain authentication session cookies.

Hackers can simply change the action attribute of a form to be that of the domain/URL they are trying to breach. An unsuspecting site would only ensure that the authentication session token is valid. It would therefore be possible to use the users open session to perform malicious actions such as saving or reading data from a database.

How Can I Protect My Self From It?

Protection from CSRF attacks has a simple solution. Send another cryptically secure token to the user along with the authentication session token. This token is sent both on the page being generated as well as a cookie.

Upon receiving a post back from a page, the server simply reads the CSRF token from the page and the cookie and ensures that they are identical.

As only a page generated from the site would contain the token, any fake page posting back to the server will be missing the correct CSRF token.


The MVC helper method AntiForgeyToken generates a CSRF token and persists it in a cookie and a hidden input element on the page.

using (Html.BeginForm())

Validation against a CSRF attack is made by decorating the controller’s action method with the ValidateAntiForgeryToken attribute.

public ActionResult Index(McModel bigMac)

If a CSRF attack is caught a System.Mvc.HttpAntiForgeryException is thrown and the user is presented with a 500 status code.

ASP.NET Web Forms

A page written in ASP.NET web forms would traditionally need to manually perform the CSRF token, its persistence and checks to ensure they are identical when the page is posted back.

However we can now make use of the AntiForgery class.


Within the aspx page a call to the GrtHtml method would generate the CSRF token which is then persisted within a cookie and an input element upon the page.

&lt;%= System.Web.Helpers.AntiForgery.GetHtml() %&gt;

Validation against a CSRF attack would then be performed during a page post back with the Validation method.

protected void Page_Load(object sender, EventArgs e)
    if (IsPostBack) {

Securing Cookies

Http Only Cookies

Using AntiForgery.GetHtml or @Html.AntiForgeyToken should create cookies which are secured for access by the server only and not via a client side script.

However where a more manual approach has been made to CSRF protection it is important to ensure that the CSRF token cannot be read from by a client side script. If this is not the case then a malicious page could read the token and simply add it to its form data before posting back to the server; circumventing our protection.

Cookies can be set as HttpOnly via a property during their creation:

var cookie = new HttpCookie(&quot;MyCookies&quot;, DateTime.Now.ToString());
cookie.HttpOnly = true;

Cookies can be set as HttpOnly globally for a website via the web.config:

&lt;httpCookies domain=&quot;String&quot; httpOnlyCookies=&quot;true&quot; /&gt;

Note is it probably wise to set httpOnlyCookies to true regardless of your CSRF approach. Any information stored within a cookie which could be readable on the client side is probably a bad idea.

SSL Only Cookies

Where cookies contain sensitive information such as CSRF or authentication session token, it would be wise to enforce their transportation via SSL or HTTPS, as such preventing people from spying on the network traffic and therefore stealing them.

This can be done globally for a site within the web.config:

&lt;httpCookies domain=&quot;String&quot; httpOnlyCookies=&quot;true&quot; requireSSL=&quot;true&quot; /&gt;

However this approach might not always be possible. We can conditionally determine when to enforce SSL communication for cookies by checking the forms authentication settings and the connection for their status of secure connections. The individual cookie can then then be secured for SSL communication only via the Secure property.

var cookie = new HttpCookie(&quot;MyCookies&quot;, DateTime.Now.ToString());
cookie.HttpOnly = true;

if( FormsAuthentication.RequireSSL &amp;&amp; Request.IsSecureConnection) {
    cookies.Secure = true;