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

 

Price manipulation OR Web parameter tampering

Price manipulation OR Web parameter tempering:

Mostly ecommerce web application has risk of price manipulation or web parameter tempering attack.

Defination:

The Web Parameter Tampering attack is based on the editing or modification of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, orders, etc. Usually, this information is stored in cookies, hidden form fields, or URL Query Strings, and is used to increase application functionality and control.

Example with URL tempering:

 Hackers in week day or on offer day edit price information products and orders bulk products using eCommerce application. Shopping carts will often pass on price data in HTTP headers or through cookies. For example, the header might say something like “www.mayecomapp.com\orders.aspx?price=200.50&orderid=nk138530&custname=nagnathkendre.” The first variable being passed along is the price.
With above URL attacker can easily change price value, lowering price value and pass order for payments, such kind of attacks is called as price manipulation or web parameter tempering.

Example with Hidden fields:

With following example in coding programmer used hidden field to store order total item cost data.
Now hacker can easily tamper with the value stored on his browser and change the total cost price and proceed to submit order for payment.
<input type="hidden" id="TotalitesmCost" name="TotalCost" value="5000.25">

Example with Form fields:

Asp.net or other web programming languages also support Form and form fields like combo, checkbox, listbox.When user selects these form fields data submit form, for hacker manipulating or editing these form fields value is easy task.

Example with cookies:

An attacker or hacker can steal the cookies and gain access to restricted area, and manipulate financial data.

Prevention:

1.  Always use SSL certificates (https) for all pages on finance based web application, use
HTTS to enforce all pages from http to https. More info..http://codechef4u.com/post/2015/06/10/HSTS
2.  Don’t trust user data, validate user input data.
3.   Use proper encryption for URL or Encode URL.
4.   Set ValidateRequest=true in asp.net web config.
5.     Don’t use persistent cookies for storing authentication tokens (session ids) and don’t select “Remember password” option in Logon screen in a public computer. 
6. We recommend to avoid using HiddenField,  if you are using ViewState or HiddenField Data encrypt it or encode it with best industry standards.
 

 

Anti-Cross Site Scripting Library(Antixss library)

Writing weak code means blindly providing security holes to attacker, most security problems come from trusting user input data too much. Such one common attack from trusting user input is Cross Site Scripting (often abbreviated as XSS). Microsoft created powerful tool that mitigates XSS risks called Anti-Cross Site Scripting Library.

Cross Site Scripting:

Cross Site Scripting (often abbreviated as XSS) when attacker uses web application send or injects malicious code like browser script, to different user. This malicious script executes and access user resources, trusted website data, website critical information.

Anti-Cross Site Scripting Library:

Anti-XSS helps you to protect your current applications from cross-site scripting attacks, at the same time helping you to protect your legacy application with its Security run time engine. 

Points to remember with Anti-XSS:

      1.  Secure Globalization: Anti-XSS protects against XSS attacks coded in dozens of languages or multiple languages called Secure Globalization. If your application is available in multiple languages this is very important protection.
2.  Performance: Anti-XSS code is written with performance in mind, code provides real time protection data protection with improved performance.
3.  Standards Compliance: Anti-XSS is written to comply with modern web standards. You can protect your web application without adversely affecting its UI.

Code Example using Anti-XSS:

    /// <summary>
    /// Returns safe input text and html fragment.
    /// added this considering prevention from xss attcks.
    /// </summary>
    public class SafeInputDataForApp
    {
        /// <summary>
        /// to prevent XSS, used Anti-XSS, returns safe data
        /// </summary>
        public void CheckValidInputs(string url,string htmlInput,string XmlInput,string item)
        {
 
          AntiXss.UrlEncode(url)
 
          AntiXss.HtmlAttributeEncode(htmlInput)
 
          AntiXss.XmlEncode(XmlInput)
 
           AntiXss.JavaScriptEncode(item)
        }
 
        /// <summary>
        /// Returns a sanitized html string
        /// </summary>
        public static string GetSafeHtml(string InputText)
        {
             return AntiXss.GetSafeHtmlFragment(InputText);
 
              //I recommends using below code, reson more safe
             //return Sanitizer.GetSafeHtmlFragment(InputText);
           }
    
    }