Stop Chatty HTTP Headers

You don’t have to be a security expert to know that the first pieces of information a hacker needs in order to perform a successful attack on any application is the technology used and the operating system. Yet we still find most web applications plagued with chattiness. They voluntarily broadcast information about the technology used and identify their server. Don’t believe me? Take a look at what Microsoft.com includes in it's request headers:

Luckily, this risk can be easily mitigated with only a couple of lines in any .Net application's global.ascx file and web.config file.

First, we will need to identify the headers we need removed, then we'll remove them in the Application_PreSendRequestHeaders event.

Here is the my global.ascx.cs:

public class WebApiApplication : System.Web.HttpApplication
{ 
    private static readonly List<string> unwantedHeaders = new List<string>
        {
            "Server",
            "X-AspNet-Version",
            "X-AspNetMvc-Version" 
        };
    protected void Application_Start()
    {
        GlobalConfiguration.Configure(WebApiConfig.Register); 
    }
    void Application_PreSendRequestHeaders(object sender, EventArgs e)
    {
      unwantedHeaders.ForEach(Request.RequestContext.HttpContext.Response.Headers.Remove);
    }   
}

The only remaining part is to tell our web.config to remove the X-Powered-By header by placing the following snippet inside the <system.webServer> node:

    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>

In addition to removing the chatty headers, you should change asp.net Cookie name to something unique to your application or business.

This can be done by setting up the session state Cookie name in your web.config:

  <system.web>
      <sessionState cookieName="THE_NAME_OF_YOUR_CHOICE" />
  </system.web>

The last thing to do is to avoid using the aspx file extension, the framework gives you plenty of options to drop the file extension all together or use your own extension.

Always treat your application's security and quality as part of your design process and not as add-ons to consider implementing halfway through the application development.

Update:

I have received a couple of emails asking for additional measures to secure a .Net web application. While I would love to keep blogging about application security, I do have a day job that I like to keep :-) and a team that needs me (Sometimes). But if you are really (and you should be) interested in security, you can look into the following:

  • SQL Injection (How to perform and prevent)
  • Parameter Tampering (hint, NEVER trust a user input. ALWAYS validate)
  • Cross Site Scripting (XSS)
  • Cross-Site Request Forgery (CSRF)
  • Session Hijacking 
  • Encryption 

For all those and more Security related topics, visit OWASP (Search the items mentioned above)

Comments (3) -

Mike Stansen 2/26/2014 5:28:10 PM

Sammy,

Do you have any plans for writing about SQL Injection,  Parameter Tampering, Cross Site Scripting , Cross-Site Request Forgery, Session Hijacking and Encryption

TY

Mike,

I'm Sorry, I don't have any plans to blog about the rest of security measures you mentioned.

You will need to look each and every one up and study them. However, I can answer questions if you come up with anything specific.

Good luck

Sammy

Thanks for your imput, hope to read more from you good job.

Add comment