Codechef4u is a community for computer professionals,by computer professionals,just like you; who loves sharing and helping each others,Join them
Share your post

Security Vulnerabilities in Web.config or Security misconfigurations

Security misconfigurations OR Security Vulnerabilities in Web.config

Single change in machine.config file could affect every website on network or single change in web.config create security risk for asp.net web application.

Note :This article is written considering all asp.net environments(Asp.net 1+), may be some new security features added in current asp.net version to avoid this security mistake and those are missing in this article. we will update those if found any ,we suggest users please add new configuration measures in your comment. 
This article lists possible mistakes programmer could avoid while creating web application.

1.  Missing Custom Error Handling:

As programmer always remember to enable custom error pages in order to prevent attackers from mining information from the framework's built-in error responses.

Typical misconfigurations:

<customErrors mode="Off" />
This is improper error handling; system exception could provide useful information like database information, file information. Error messages provide quite useful information to the attacker that can be used to launch further attacks such as code Injection,SQL Injection,XSS attacks.
<customErrors mode="RemoteOnly" />
Custom error message mode for remote user only. No defaultRedirect error page specified. The local user on the web server will see a detailed stack trace. For remote users, an ASP.NET error message with the server customError configuration setting and the platform version will be returned.

Secure error handling:

 
<customErrors mode="RemoteOnly" />
  <customErrors mode="On" defaultRedirect="YourErrorPage.htm" />
Or such as
    <customErrors mode="RemoteOnly" defaultRedirect="~/error.aspx" redirectMode="ResponseRewrite">
      <error statusCode="404" redirect="~/error404.aspx" />
    </customErrors>

This will display only generic message on specific custom error page.

2.  Password in configuration file:

Using hardcoded user credentials in configuration file is dangerous and bad practice, with such practice you are providing blindly hacker security hole in your application.

Clear-text passwords in the configuration files are subject to exposure in a variety of ways, including people getting access to the file, the file being served directly to a user due to a server error, a file download flaw, access to a backup copy, or some other exposure.

Typical misconfiguration:

    <authentication mode="Forms">
      <forms>
        <credentials>
          <user name="nagnath" password="test@1224"/>
          <user name="shourya" password="fgdf25"/>
        </credentials>
      </forms>
    </authentication>


Secure use:

<authentication mode="Forms">
      <forms timeout="129600" name="myWebApp" protection="All" slidingExpiration="false" loginUrl="~/Account/login.aspx" cookieless="UseCookies" />
    </authentication>


3.  Sliding Expiration:

The slidingExpiration setting is a security measure used to reduce risk in case the authentication token is stolen.Hacker or attacker use stolen authentication ,but he don’t know user credentials.

Typical misconfiguration:

<authentication mode="Forms">
 <forms name="myWebApp" protection="All" slidingExpiration="true" loginUrl="~/Account/login.aspx" cookieless="UseCookies" />
 </authentication>


When sliding expiration is enabled, as long as an attacker makes at least one request to the system every 15 minutes (or half of the timeout interval), the session will remain open indefinitely. This gives attackers more opportunities to steal information and cause other mischief.

Secure use:

<authentication mode="Forms">
      <forms name="myWebApp" protection="All" slidingExpiration="false" loginUrl="~/Account/login.aspx" cookieless="UseCookies"/>
    </authentication>
when slidingExpiration setting is disabled, they can't log back in as the legitimate user, so the stolen authentication token is now useless and the threat is mitigated. When set to false, the specified timeout interval becomes a fixed period of time from the initial login, rather than a period of inactivity

4.  Debugging Enabled/ Disabled:

Leaving debugging enabled is not good practice, debugging messages help attackers learn about the system and plan a form of attack.

The debug attribute of the <compilation> tag defines whether compiled binaries should include debugging information. Symbols (.pdb files) tell the debugger how to find the original source files for a binary, and how to map breakpoints in code to lines in those source files.

 Leaving debugging enabled is dangerous because you are providing inside information to end users who shouldn't have access to it, and who may use it to attack your applications

Typical misconfiguration:

<configuration> 
<system.web>
<compilation debug="true" targetFramework="4.5">
….
</compilation>
</system.web>
</configuration>

Secure use:

<configuration> 
<system.web>
<compilation debug="false " targetFramework="4.5">
….
</compilation>
</system.web>
</configuration>

5.  Cookieless Session State Enabled:

Asp.net web application allows storing the session token in the page URLs rather than a cookie.

Example: 

http://mySecuritrytestApp.com /default.aspx  to
http://mySecuritrytestApp.com /(912345678ABCDEFG)/default.aspx. In this case, 912345678ABCDEFG represents the current user's session token.
Multiple users browsing site sate time would receive completely different session resulting deferent URL.

Typical misconfiguration:

<configuration>
        <system.Web>
          <sessionState cookieless="UseUri"/>
   </system.Web>
</configuration>


Allowing session storing in the page URLs is dangerous because side effect of making those applications much more vulnerable to session hijacking attacks.

Secure use:

<configuration>
        <system.Web>
          <sessionState cookieless="UseCookies"/>
  </system.Web>
</configuration>
Best prevention from these session hijacking attacks is to force your Web application to use cookies to store the session token. This is accomplished by setting the cookieless attribute of the <sessionState> element to UseCookies or false.

 

6. Tracing Enabled:

 The tracing feature of ASP.NET is useful tool for developers and programmers to debug and profile your applications.

Unfortunately tracing enabled in production environment is dangerous because it is also one of the most useful tools that a hacker can use to attack your applications.

Typical misconfiguration:

<configuration>
        <system.Web>
          <trace enabled="true" localOnly="false"/>
  </system.Web>
</configuration>
When tracing is enabled simply browsing trace.axd hacker can view an incredibly detailed list of recent requests to the application

Secure use:

<configuration>
        <system.Web>
          <trace enabled="false" localOnly="true"/>
  </system.Web>
</configuration>
Best prevention from obtaining trace data is to disable the trace viewer completely by setting the enabled attribute of the <trace> element to false.

7.  Cookies Accessible Through Client-Side Script

When httpOnlyCookies disabled in that case cookies are accessible in client side script like JavaScript, VbScript. Hacker initiates a cross-site scripting (XSS) attack by attempting to insert his script code into the Web page.

Typical hacker example:

on blogging site users provide feedback, comments, but an attacker, rather than posting about the current topic, will instead post a message such as <script>alert(document.cookie);</script>.

The comments now include the attacker's script code in its page code—and the browser then interprets and executes it for future site visitors. Usually attackers use such script code to try to obtain the user's authentication token (usually stored in a cookie), which they could then use to impersonate the user. When cookies are marked with the HttpOnly property, their values are hidden from the client, so this attack will fail.

Typical misconfiguration:

 <configuration>
   <system.Web>
      <httpCookies httpOnlyCookies="false">
</system.Web>
</configuration>


Secure Use:

<configuration>
   <system.Web>
      <httpCookies httpOnlyCookies="true">
</system.Web>
</configuration>

 

8.  Cookieless Authentication Enabled

Like cookieless sessionstate  allowing Cookieless Authentication is dangerous because it leads to session hijacking. When a session or authentication token appears in the request URL rather than in a secure cookie, hacker can easily identify user.

Typical misconfiguration:

<configuration>
    <system.Web>
      <authentication mode="Forms">
        <forms cookieless="UseUri"/>
      </authentication>
    </system.Web>
    </configuration>


Secure Use:

<configuration>
    <system.Web>
      <authentication mode="Forms">
        <forms cookieless="UseCookies"/>
      </authentication>
    </system.Web>
    </configuration>


9.  SSL For authentication:

Web application uses the Secure Sockets Layer (SSL) protocol to encrypt data passed between the Web server and the client. If you are using SSL hacker not able to attack your data passed between from server and the client.

Typical misconfiguration:

  <configuration>
    <system.Web>
      <authentication mode="Forms">
        <forms requireSSL="false"/>
      </authentication>
    </system.Web>
    </configuration>


Secure use:

  <configuration>
    <system.Web>
      <authentication mode="Forms">
        <forms requireSSL="true "/>
      </authentication>
    </system.Web>
    </configuration>


Using SSL means that attackers using network sniffers will not be able to interpret the exchanged data. Rather than seeing plaintext requests and responses.
We recommend using HTTP Strict Transport Security(HSTS) for enforcing all pages with HTTPS protocol that uses Secure Sockets Layer (SSL). For more …http://codechef4u.com/post/2015/06/10/HSTS