Secure ASP.NET coding practice for three most critical vulnerabilities in Web Application

Secure ASP.NET coding practice for three most crit= ical vulnerabilities in Web Application

Secure ASP.NET coding practice for 3 most critical vulnerabi= lities in Web Application

Introduction:

ASP.NET provides several exciting security controls, but the= se need to be understood properly and used wisely. Failing to use the ASP.NET functions properly results in an insecure web application. We see therefore that ASP.NET does not exempt the programmer from following coding standards= and procedures in order to write safe and = secure application co= de.

In this paper we will discuss about the code level mitigation for three most frequently found vulnerabilities:

Cro= ss Site Scripting

SQL Injection

Inf= ormation Leakage

Cross Site Scripting:=

An application is vulnerable to Cross Site Scripting if malicious user input is embedded in the HTML response without passing throu= gh any particular validation process. Let’s take a look on a vulnerable chunk of code

<%@ Page ValidateRequest=3D"false" %><= /b>

<html>

<script runat=3D"server">

voi= d buttonsubmit_Click(Object sende= r, EventArgs e)

{

Response.Write(comment.Text);<= /span>

}

</script>

<body>

<form runat=3D"server">

<asp:TextBox runat=3D&q= uot;server" />

<asp:Button runat=3D&qu= ot;server"

Text=3D"SubmitComment" />

</form><= /i>

</body><= /i>

</html><= /i>

Now an attacker can send malicious request with embedded JavaScript through the comment textbox which will be executed at the client’s browser. To see that this is possible, the above vulnerable script can be fed with the following input:

<script>alert([removed])</script>

Now this type of script injection attack can be mitigated by adopting a two tire security approach. User input validation will form the first tire of security while HTML-encoding on outgoing user data will form a second layer of security. So we can start assuming that all user input is malicious and to safely allow restricted HTML input developers/testers shou= ld adopt three security approaches as follows:

a)      Add the ValidateRequest=3D"false" attribute to the @ Page directive to disable the ASP.NET request validation.

b)      Encode the string input wit= h HtmlEncode function.

c)       White listing approach can be adopted by using a String Builder and calling its Replace method to selectively remove the encoding on the HTML elements that you want to permi= t.

The following .aspx code depicts= this as an example.

<%@ Page ValidateRequest=3D"false"%>

<script runat=3D"server">

voi= d submitbutton_Click(object sende= r, EventArgs e)

{

Str= ingBuilder stringbuilder1 =3D new StringBuilder(

HttpUtility.HtmlEncode(Txt1.Text));

// Selectively allow <b> and <i>

str= ingbuilder1.Replace("<b>", "<b>");

str= ingbuilder1.Replace("</b>", "");

str= ingbuilder1.Replace("<i>", "<i>");

str= ingbuilder1.Replace("</i>", "");

Response.Write(str= ingbuilder1.ToString());

}

</script>

<html>

<body>

<form runat=3D"server">

<div>

<asp:TextBox Runat=3D&q= uot;server"

Tex= tMode=3D"MultiLine" Width=3D"318px"

Height=3D"168px&= quot;></asp:TextBox>=

<asp:Button Runat=3D&qu= ot;server"

Text=3D"Submit&q= uot; OnClick=3D"submitbutton_Cli= ck" />

</div>

</form><= /i>

</body><= /i>

The above .aspx page code shows = this approach. The page disables ASP.NET request validation by setting ValidateRequest=3D"false". It HTML-encodes the input and then selectively allows the <b> and <i> HTML elements to support simple text formatting.

Now the second tire of security can be brought into the fram= e by encoding the output to know that the text contains HTML special characters = or not.

Res= ponse.Write(HttpUtility.HtmlEncod= e(Request.Form["text"])= ); Or in case of URL strings that contain in= put to the client. =

Response.Write(HttpUtility.UrlEncode(urlString));

=

As a result, the HTML response stream of the malicious input= <script>alert([removed])<= ;/script> will look like this

<script>alert([removed])</script>=

This will ultimately restrict the browser to execute the Javascript code because no HTL <script> tag is present any more in the response.The greater-th= an and less-than symbols are replaced by their HTML-encoded o= utput,< and > respectively.

In addition to this two tire security approach discussed abo= ve, we can also use the following countermeasures to prevent cross site scripti= ng as further safe guards.

Setting the correct character encoding:
Character encoding can be done in page level or in configura= tion level. To set the Character encoding at the page level we can use <meta> element or the Res= ponseEncoding page-level attribute as follows:

<% @ Page ResponseEncoding=3D"iso-8859-1" %> R <meta http-equiv=3D"Content Type"       content=3D"text/html; charset=3DISO-8859-1" />

To set the Character encoding at the configuration level we = have to bring certain changes in Web.config file as follows:

<configuration>    <system.web>       <globalization          = requestEncoding=3D"iso-8859-1"          responseEncoding=3D"iso-8859-1"/>=    </system.web> </configuration>
Use white listing approach rather than black listing:

Sanitizing user input by filtering out known malicious characters is a common practice. But we should not rely on this approach because an attacker can usually find an alternative means of bypassing your validation. Instead, your code should check for known secure, safe input. T= here are other safe ways of representing these malicious characters. For example < (less than) and > (greater than) can be represented as < and > respectively.

Using the HttpOnly Cookie Option:

HttpOnly cookie attribute is supported by Internet Explorer 6 Service Pack 1 and later, which prevents client-side scripts from accessing a cookie from the [removed] property. Instead, the script returns an empty string. The cookie is still sent to the server whenever the user browses to a = Web site in= the current domain.

SQL Injection:=

Secure coding practice in ASP.NET against SQL injection vulnerability should focus on the following countermeasures:

Constrain user suppli= ed input

Before applying any countermeasure at the code level we shou= ld be concerned about the potential risk associated with denying a list of unacceptable characters (blacklisting) because it is always possible to overlook an unacceptable character when defining the list. Also this kind of validation approach can be easily bypassed by representing an unacceptable character in an alternate format.

ASP.NET server side validator controls, such as the Reg= ularExpressionValidator an= d RangeValidator= controls can be used to constrain input. Alternatively we can also the Regex cl= ass in our server-side code to constrain input.

When user input is captured by an ASP.NET TextBox control, we can constrain its input by using a = RegularExpressionValidator control as shown in the following aspx code..

<%@ %> <form runat=3D"server&qu= ot;>     <asp:TextBox runat=3D"server"/>     <asp:RegularExpre= ssionValidator runat=3D"server"   &nb= sp;                 &nb= sp;            =            ErrorMessage=3D"Incorrect data"             &nb= sp;            =            ControlToValidate=3D"text1"  &nbs= p;                  &nb= sp;            =            ValidationExpression=3D"^\d{3}-\d{2}-\d{4}$"= ; /> </form> If the user input is from another source, such as an HTML control, a query string parameter, or a cookie, you can constrain it by using the Reg= ex cl= ass from the System.Text.RegularEx= pressions namespace. The following example assumes that the input is obtained from a cookie. if<= /span> (Regex.IsMatch(Request.Cookies["SSN"], "^\d{3}-\d{2}-\d{4}$")) {     // perform the database task } else {     // handle exception } &n= bsp;

User supplied input parameters need to be validated before b= eing used in SQL statements. The following = data access routine can be taken as an example of how validate user input parameters.

= using<= /span> System; usi= ng System.Text.RegularExpressions; public void useraccount(string username, string password) {     // check username contains only lower case or upper case letters,     // the apostrophe, a dot, or white space. Also chec= k it is     // between 1 and 40 characters long     if ( !Regex.IsMatch<= /span>(userIDTxt.Text, @"^[a-zA-Z'./s]{1,40}$"))       throw new FormatException("Invalid username format"); &nb= sp;     // Check password contains at least one digit, one lower case     // letter, one uppercase lett= er, and is between 8 and 10     // characters long     if ( !Regex.IsMatch<= /span>(passwordTxt.Text,             &nb= sp;         @"^(?=3D.*\d)= (?=3D.*[a-z])(?=3D.*[A-Z]).{8,10}$" ))    &nb= sp; throw new FormatException("Invalid password format"); =     // Perform data access operation (using t= ype safe parameters)     ..= . } =

Use parameterized sto= red procedures:
The following code shows how to use parameters with <= span style=3D'color:#BDD5DA'>stored procedures.

using System.Data; using System.Data.SqlClient; usi= ng (SqlConnection connection =3D new SqlConnection(connectionString)) { DataSet userDataset =3D n= ew DataSet(); SqlDataAdapter myCommand =3D new SqlDataAdapter= (             &nb= sp;"LoginStoredProcedure", connection); myCommand.SelectCommand.CommandType =3D CommandType.StoredProcedure; myCommand.SelectCommand.Paramete= rs.Add("@au_id", SqlDbType.VarChar, 12); myCommand.SelectCommand.Parameters["@au_id"].Value =3D SSN.Text<= /span>; &nb= sp; myCommand.Fill(userDataset); } = In= the above example the @au_id parameter is treated as a literal value and not as executable code. Also, t= he parameter is checked for type and length. In the preceding code example, the input value cannot be longer than 12 characters. If the= data does not conform to the type or length defined by the parameter, the SqlParameter class throws an exception.

Note: Using stored procedure with parameters does not necessarily prevent SQL injection.Take a look a= t the following stored procedure:

= CRE= ATE PROCEDURE dbo.RunQuery @var ntext<= /span> AS    &nb= sp;    exec sp_executesql @var GO

Now despite being a parameterized stored procedure , this one executes whatever is passed to it.Co= nsider the @var variable being set to:

DROP TABLE USERS;

Use parameterized dyn= amic sql:

Now if you are not using stored procedure, you still should = use parameters when constructing dynamic SQL statements. The following code sho= ws how to use parameters with dynamic SQL statement.

using System.Data; using System.Data.SqlClient; usi= ng (SqlConnection connection =3D new SqlConnection(connectionString)) { DataSet userDataset =3D n= ew DataSet(); SqlDataAdapter myDataAdapter =3D new SqlDataAda= pter(          "SELEC= T au_lname, au_fname FROM A= uthors WHERE au_id =3D @au_id",          connection); &nb= sp;            =   myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); myCommand.SelectCommand.Parameters["@au_id"].Value =3D SSN.Text<= /span>; myDataAdapter.Fill(userDataset); } =

Using a least privile= ged database account:

Your application should connect to the database by using a least-privileged account. If you use Windows authentication to connect, the Windows account should be least-privileged from an operating system perspective and should have limited privileges and limited ability to access Windows resources. Additionally, whether or not you use Windows authenticat= ion or SQL authentication, the corresponding SQL Server login should be restric= ted by permissions in the database.

If your ASP.NET application only performs database lookups a= nd does not update any data, you only need to grant read access to the tables. This limits the damage that an attacker can cause if the attacker succeeds = in a SQL injection attack.

Avoid Disclosing Error Information

Use structured exception handling to catch errors and prevent them from propagating back to the client. Log detailed error information locally, but return limited error details to the client.<= /p>
If errors occur while the user is connecting to the database= , be sure that you provide only limited information about the nature of the erro= r to the user. If you disclose information related to data access and database errors, you could provide a malicious user with useful information that he or she can use to compromise your database security. Attackers use = the information in detailed error messages to help deconstruct a SQL query that they are trying to inject with malicious code. A detailed error message may reveal valuable information such as the connection string, SQL server name,= or table and database naming conventions.

Information leakage: Remember that __VIEWSTATE data can be viewed

The __VIEWSTATE’s Base64 encoding can be easily decode= d, and the __VIEWSTATE data can be exposed with minimal effort. Now the attack= er can see the information that may be sensitive, such as internal state data = of the application.To encrypt the __VIEWSTATE data= we have to add the machineKey attribute in web.config file as follows:

<configuration>

<system.web>

<machineKey validation=3D"3DES"/>

</system.web>

</configuration>= ;

Retrieved from "http://www.articlesbase.com/security-articles/se= cure-aspnet-coding-practice-for-three-most-critical-vulnerabilities-in-web-= application-889853.html"