Web Security Measures in ASP.NET Applications

Sachin Sunkle
Page content

At my current workplace, All Applications are expected to adhere to PCI DSS standards meant for Data protection, Access Regulation and so on. Dedicated SOC Team,consisting of Security analyst who are continously on the prawl to identify breach, conduct periodic auditing of Applications, hardening of Servers.

While all our .NET applications adhere to below guidelines,

We also use tools like Snyk to perform code vulnerability analysis as part of Jenkins driven CI/CD pipeline. In spite of above, we do come across vulnerabilities identified by SOC Team which we needs to be addressed quickly. SOC team uses tools such as Burp Suite.

This post is going to summarize such incidents reported so far (and will keep updating it). In most of these cases, These issues required additional efforts over and above those provided by library or framework. Hopefully, it will be helpful to anyone trying address such vulnerabilities.

Every cookie being sent by the Web application has attributes like,

  • HTTPOnly - Indicates whether a cookie is accessible by client-side script
  • Domain - Indicates the domain to associate the cookie with
  • Path - the virtual path to transmit with the current cookie
  • Secure - Indicates whether cookie is sent only on Secure (HTTPS) Connections.

OWASP has nice primer on Cookie Security.

Of the above, Path attribute limits the scope of a cookie to a specific path on the server and can therefore be used to prevent unauthorized access to it from other applications on the same host. Accordingly, SOC Team had recommended that all cookies issued by application must have path attribute set.

In case of typical ASP.NET Application, there are cookies generated by .NET framework (like for Session, Anti XSRF Token and son on) and custom ones which are issued and used by Application itself.

While it is fairly easy to set path for custom ones, we had to make code changes for cookies issued by .NET framework libraries. Lets take case of Session ID cookie, by default, this cookie always has root / as path. So how can this be changed as per the application’s deployment settings (i.e. specific virtual directory in IIS)?

We tried below,

  • Step 1, try using httpcookies section in web.config like,
    <httpCookies requireSSL="false" httpOnlyCookies="true"  domain="site.com/myapp"/>

First of all, this configuration element does not allow setting Path property and even during runtime, only the Domain property is populated while issuing the cookie. So this definitely does not help address the issue.

So other way is to programmatically set the path for Session Cookie. This can be done by providing custom implementation of SessionIDManager class like below,

  public class MySessionIDManager : SessionIDManager, ISessionIDManager
    {
        void ISessionIDManager.SaveSessionID(HttpContext context, string id, out bool redirected, out bool cookieAdded)
        {
            base.SaveSessionID(context, id, out redirected, out cookieAdded);

            if (cookieAdded)
            {
                var name = "ASP.NET_SessionId";
                var cookie = context.Response.Cookies[name];
                // this will be possibly read from configuration
                cookie.Path = "/myapp"; 
           }
        }
    }

Thanks to this Stackoverflow thread for listing this approach. Application under consideration only had this particular cookie however, for all other .NET framework issued cookies, similar technique will have to be used.

This is already detailed here

Masking of Sensitive Data

This typically involves masking the sensitive data like

  • E-mail id
  • Phone Number
  • Credit/Debit Card Number

It could well be used in Web Application or be received or sent as part of HTTP API.

The best bet in this case is to mask it on the server side itself before sending/rendering the data in browser. Note that, in some cases, above fields are used for data binding purposes. The approach we followed in such scenario was to use Hash value of it instead of merely masking the data. We have always used SHA256 or above for hashing.

Summary

Addressing security vulnerabilities is continuous process as hackers keep on inventing new ways for breaching and exploiting weak spots. As Application Architect/Developers, we need to brace ourselves for the same.

Happy Coding !!