Discovering Security Vulnerabilities And Leaks In ASP.NET Websites

Huyam AL-Amro and Eyas El-Qawasmeh

Information Systems Department King Saud University, KSU

Riyadh, Saudi Arabia huyamalamro@yahoo.com, eyasa@usa.net

ABSTRACT—Websites written in ASP.NET might contain security vulnerabilities that are not seen to the owner of the website. This paper describes an algorithm that aims in the detection of security vulnerabilities. The suggested algorithm performs a scanning process for all website/ application files. Our scanner tool relies on studying the source code of the application depending on ASP.NET files and the code behind files (Visual Basic VB and C sharp C#). A program written for this purpose is to generate a report that describes most leaks and vulnerabilities types (by mentioning the file name, leak description and its location). The suggested algorithm will help organization to fix the vulnerabilities and improve the overall security.

Keywords-components; ASP; ASP.NET; Websites; Vulnerability; Leak; Denial-of-Service DoS; Threats; Security; Script; JavaScript; HTML; Algorithm; SQL Injection; Cross Site Scripting XSS; Hijack Session; Cookie Poisoning; IFrame

I. INTRODUCTION

Currently many organizations and individuals depending on the websites for many real life applications such as paying bills, booking hotels, tickets and many others. The dynamic web application that accept input from the user and respond based on the input like many web applications that are developed by ASP.NET framework, allows the user to exploit the weaknesses in the web site by looking for security vulnerability to inject his malicious code or script. Most programmers use ASP.NET web application framework to build their dynamic websites, web applications and web services [1], this is due to its better language support and its distinctive features like: Event driven programming, rich with server controls, easy and quickly in using its development environment (Visual Studio.NET or Visual Web Developer). For example, one common use of ASP programming is to gather data from the user (as user name) and display this data on subsequent pages during user's visit [2]. If this input control does not validated against malicious input, the hacker can inject his malicious input or script that can destroy the database or steal website files. From this point, came the importance of having a tool to test websites/ applications written using the ASP.NET language, especially the lack of the existence of specialized programs to check the ASP.NET sites and the discovery of security vulnerabilities. The paper suggests an algorithm for the purpose of improving the security of

websites. The suggested algorithm consists of many steps. We are able to implement the basic steps in this algorithm and we still working to finish the rest.

II. VULNERABILITY TYPES

Currently, there are many types of vulnerabilities that vary in terms of complexity, detection, and recover. Following are the main types that this paper will tackle.

A. SQL Injection

SQL Injection is a form of attack that can occur when an application uses user input that has not been checked to see that it is valid and the hacker uses this malicious input to exploit sensitive information from the database [3]. For example, if we have an application that requires an input string for (SSN) text box, which is expecting a social security number of the form nnn-nn-nnnn. After that, the application will execute a similar SQL statement:

// Use dynamic SQL

SqlDataAdapter myCommand = new SqlDataAdapter ("SELECT au_lname, au_fname FROM authors WHERE au_id = '" + SSN.Text + "'", myConnection);

// Use stored procedures

SqlDataAdapter myCommand = new SqlDataAdapter ("LoginStoredProcedure '" + SSN.Text + "'", myConnection);

The developer expects the user's input like '172-32-9999' and generates the following SQL statement:

SELECT au_lname, au_fname FROM authors WHERE au_id = '172-32-9999'

But the user's malicious input was:

'; DROP DATABASE pubs --'

This would turn the database query into:

SELECT au_lname, au_fname FROM authors WHERE au_id = ''; DROP DATABASE pubs --'

In this case, the ' (single quotation mark) character that starts the malicious input terminates the current string literal as in the following statement:

SELECT au_lname, au_fname FROM authors WHERE au_id=''

The ; (semicolon) character tells SQL that this is the end of the current statement and the start of another:

; DROP DATABASE pubs

The result of this code is delete "pubs" database.

Finally, the – (double dash) sequence of characters is a SQL comment that tells to ignore the rest of the text [4].

This example does not represent the only case to create the SQL Injection; there are many forms of malicious input to create this type of vulnerability. For example, the user can enter the following malicious input:

' OR 1=1 --

This would turn the database query into:

SELECT au_lname, au_fname FROM authors WHERE au_id = '' OR 1=1 --

Since 1=1 always evaluates to true, this query will always return more than 0 rows [5].

B. Cross Site Scripting

Cross Site Scripting ('XSS') is one of the most common application layer web attacks that take advantage of a web site vulnerability in which the site displays content that includes un-sanitized user provided data [6][7]. Cross Site Scripting occurs mainly in dynamic web pages that are mixing of browser data (HTML) with the code (<script> tag) which is embedded in the data. The script can be (JavaScript, VBScript, ActiveX, HTML, or Flash) [8][9]. The main objective of 'XSS' is to manipulate client-side scripts of a web application to execute in the manner desired by the malicious user. This is generally applicable where an application takes input from the end-user and displays the same input back to the user usually as a response to the same page request, such as search engines which display the search term in the title ("Search Results for: search_term") [6][7][8]. Exploited 'XSS' is commonly used to achieve the following malicious results [6]:

Identify theft

Accessing sensitive information

Spying on user's web browsing habits

Altering browser functionality

Web application defacement

Denial of Service

There are two main types of Cross Site Scripting:

1) Stored Cross Site Scripting

2) Reflected Cross Site Scripting

1) Stored Cross Site Scripting

The stored (or persistent) Cross Site Scripting occurs when the data provided by the attacker is saved by the server, and then displayed permanently on "normal" pages returned to other users [15]. Stored XSS requires particular kind of vulnerability in the application where the data is placed in somewhere (ex. Data base) and later feedback is send to the user, this can be through Forum, Blog, etc. The attacker can send <HTML> or <JavaScript> to the application instead of the normal input to be stored in the data base, later when the victim comes to the application web site he/she will download the <HTML> or <JavaScript> located there. The application here acts as an attack site but works for the hacker [10]. For example, when the user comes to the shopping site and he wants to send a message to the site administrator, he should Log-In to the web site first and then looking for a link (like Post Message link which usually consists of subject name and an area for writing a message). The attacker can exploit this facility to inject his malicious input 'XSS'. He will tries simple scripting code to examine site vulnerability, then he could inject script like:

<script> alert (document.cookie); </script>

When the site administrator downloads this message, he will receive a small window contains cookie information. The hacker could craft script to steal this cookie information to his site.

2) Reflected Cross Site Scripting

Reflected (or non-persistent) Cross Site Scripting can occur when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results and reflected back for the user, without sanitizing the request [15][11]. For example, if we have a user Log-In prompt (User-Id, Password) and the user has supplied his Log-In information:

User-Id: Ahmed

Password: ********

Suppose the user typed his Password incorrectly, he may have a message like ("Sorry, Invalid Log-In"), but sometimes we have a message like ("Sorry Ahmed, Invalid Log-In") and here's the problem, where the (user name) sends and reflected back to the output. If there is no input validation for Log-In text boxes, the attacker can exploit this vulnerability to inject his malicious input 'XSS' instead of User-Id. The attacker can craft an email contains a link request from the user to click on the link to update personal data. This part of comment is called "Phishing" in which attacker sends several emails in the hope of someone clicks on the link. When the victim clicks on the link he will send <JavaScript> to an application which will reflected back down to the victim. The attacker could erase the original Log-In page and place exactly the same original one, when

the victim clicks on "Submit" button it will sends cookie information to the attacker.

Examples on XSS

Suppose we have the following code snippet of ASP application which is vulnerable to the XSS attack:

<% Response.Write (“Your search on’” + Request.Querystring(“SearchString”) + “returned following results:” ) %>

We will consider this code as the base code for the following examples and we just need to pass the <JavaScript> code as the value for the "SearchString" parameter [8].

• Hijack Session

The attacker needs the cookie form the victim to hijack the session. This is can be implemented by creating one form and make it submit to the attacker site.

</form><form name = 'a' action = 'attackersiteaddress' method = 'post'>

<input type = hidden value = '<script> + document.cookie + </script>'>

</form>

<script> a.submit() </script>

• Cookie Poisoning

The attacker can corrupt the value of the cookie if he detect that an application is relying on the cookie value to display specific action done by the user with "response.write". Assume the application store the value of the last search done by the user along with the date-time in cookies. The attacker here can update the value of the last search with a herf pointing to his site as following:

<script> document.cookie.userlastsearch = '<A herf = "attackersiteAddress"> You have won a random prize please click here to continue </A>'

</script>

There he may ask the user to Log-In again to fool him with a prize. The attacker may bait him with 5$ and latter ask him to pay 50$ for some wonderful product. The amount may not the main target but the credit card number.

• IFrame

"The <iframe> tag specifies an inline frame. An inline frame is used to embed another document within the current HTML document" [12].

The attacker can simply fool the user by showing the UI that has size 100% in height and width to look the same as an application site through writing the following malicious code:

<iframe SRC="attacker site" height = “100%” width =”100%”>

From the previous examples, we reach to the main reasons that make an application susceptible to Cross Site Scripting attacks:

1. There is no input validation control for the inputs coming to an application.

2. There is no sanitization control for the output coming from the application [10].

III. SUGGESTED APPROACH TO UN-COVER LEAKS

Following is the algorithm that describes the leaks. We developed this algorithm and we implemented it in Java. The algorithm consists of around 12 step where each step handle a specific kind of leaks. However, due to the space limitation, we will list only two types of vulnerabilities and discuss them. They are: SQL Injection and Cross Site Scripting.

Check_For_SQL_Injection(allowFiles[])

// The allowFiles[] is an array contains all necessary files which extracted from the input directory path name and its subdirectories and needed to the inspect. These files are of type: "aspx", "aspx.vb", "aspx.cs" and "config".

// we should confirm that Request Validation is enabled and has value (true).

Step 0: Check if "validateRequest" attribute in web.config file exists and has value (false) then report there is leak.

// we should prevent displaying of the detailed errors information to users which may serve hackers.

Step 1: Check if "Debug" attribute in web.config file exists and has value (true) then report there is leak.

// if "Debug" attribute is not exist, this means its value is (true) by default.

Step 2: Check if "Debug" attribute is not exist in web.config file then report there is leak.

// we should provide minimum information that could help hackers by setting "customErrors" attribute to "On" or "RemoteOnly".

Step 3: Check if "customErrors" attribute in web.config file exists and has value (off) then report there is leak.

Step 4: Check if "customErrors" attribute is not exist in web.config file then report there is leak.

Step 5: Check if "validateRequest" attribute in (.aspx) file exists and has value (false) then report there is leak.

// validate all inputs to ASP.NET application by using validator controls.

Step 6: Check if any TextBox ID name in (.aspx) file is not validated using RegularExpressionValidator or RangeValidator then report there is leak.

// concatenation select query means there is no parameters collection used in building SQL statement.

Step 7: Check if there is concatenation select query in (.aspx.vb or .aspx.cs) file then report there is leak.

Check_For_XSS(allowFiles[]);

Step 8: Define AntiXss methods that encode HTML tags when output is rendered back to the browser.

AnitXssMethods_Array =

[AntiXss.HtmlAttributeEncode, AntiXss.HtmlEncode, AntiXss.JavaScriptEncode, AntiXss.UrlEncode, AntiXss.VisualBasicScriptEncode, AntiXss.XmlAttributeEncode, AntiXss.XmlEncode]

// "Response.Write" command is used to write output to browser.

Step 9: Check if "Response.Write" command in (.aspx, .aspx.vb and .aspx.cs) file does not have any of AntiXss methods then report there is leak.

// determine whether the output includes input parameters that may come from a variety of sources.

Step 10: Check if " Request.Params, Request.Form, Request.QueryString, Request.Cookies, Request " command in (.aspx, .aspx.vb and .aspx.cs) file does not have any of AntiXss methods then report there is leak.

// "<%= %>" command is a shorthand method for the Respose.Write command.

Step 11: Check if "<%= %>" command in (.aspx) file does not have any of AntiXss methods then report there is leak.

// "<%# %>" command is data binding expression and use the Eval and Bind functions. The Bind function is the only case where we will not be able to protect from XSS using encoding, but we can with Eval function.

Step 12: Check if "<%# %>" command in (.aspx) file contains (Eval) function and does not have any of AntiXss methods then report there is leak.

IV. PERFORMANCE RESULTS

We tried to test our algorithm on some online websites. However, we are not able to get any website. Therefore, we are forced to check it offline. For this purpose, we have downloaded some code from the following websites. They are: http://www.axezz.com/AxpDatagrid/AxpQuery.zip http://www.sourcecodester.com/aspnet/3866/online-library-management-system-olms.html http://www.aspnetsource.com/products/TihBlogCompact.html

Sample of AxpQuery directory scanning shown in the following snap shot:

Figure 1. Snap shot of AxpQuery directory scanning.

V. DISUCSSISION

The detection process for security vulnerabilities in

ASP.NET websites/ applications is a complex process, where most of the code is written by somebody else and there is no documentation to determine the purpose of some code. Other factors due to the fact that ASP.NET which is part of .NET framework that separate the HTML code from the programming code in two files, one for (aspx) file and another for the programming code depending on the compiled language (Visual Basic VB, C sharp C#, Java Script). Since the VB and C# are the most common languages in use around the world with ASP.NET files, we have adopted these two compiled languages in the construction of our proposed algorithm in addition to aspx files. Therefore, the scanning process inspects at least those three types of files (aspx, VB and C#). The developed program tried to inspect different forms of writing in code, where there are no standard form followed in writing some code, and the presence of some alternatives to some of the commands.

VI. CONCLUDING REMARKS

Reducing security vulnerabilities in any website/ application requires two things. The first thing is, a conscious developer who is aware to the responsibility which should be accompanied by instilling security into the application from the beginning of programming [13], and the website/ application owner role in inspecting his site/ application for vulnerabilities before making the website public. This paper describes our development tool that is designed to discover vulnerabilities in the source code of websites. The developed tool relies on the fact that the web application is three-tiered: Presentation, application, and storage. The web browser is the presentation, ASP.NET is the application and the database is the storage [14]. Therefore, the scanner tool tries to detect the vulnerabilities that can help hackers from the reflected output or messages, check most of the ASP.NET server controls and the commands in the code behind that interact with the database. After scanning process, it will generate a report list all the discovered leaks and vulnerabilities by displaying the name of the infected file, the description and its location.

This report requires a reaction from the organization to take the necessary corrections steps.

REFRENCES [1] wikipedia.org,

"ASP.NET"[Online]http://en.wikipedia.org/wiki/ASP.NET. May 2 , 2012.

[2] D. White, N. Foster, "What is ASP programming?" [Online] http://www.wisegeek.com/what-is-asp-programming.htm. June 2012.

[3] C. Mackay, "SQL Injection attacks and some tips on how to prevent them" [Online] http://www.codeproject.com/Articles/9378/SQL-Injection-Attacks-and-Some-Tips-on-How-to-Prev. Jan 2005.

[4] J.D. Meier, A. Mackman, B. Wastell, P. Bansod, and A. Wigley "How to: Protect from SQL Injection in ASP.NET." [Online] http://msdn.microsoft.com/en-us/library/ms998271.aspx. May 2005.

[5] B. Jovicic, and D. Simic, "Common web application attack types and security using ASP.NET". Belgrade, Serbia and Montenegro : ComSIS, Vol. 3, No. 2. December 2006.

[6] J. Guillaumier, "Cross Site Scripting - XSS - The underestimated exploit" [Online] http://www.acunetix.com/websitesecurity/xss.htm.

[7] IMPREVA Protecting the Data That Drives Business, "Cross-Site Scripting" [Online] http://www.imperva.com/resources/glossary/cross_site_scripting.html.

[8] I. Poison, "Cross site scripting: Common threats in web applications" [Online] http://www.codeproject.com/Articles/10732/Cross-site-scripting-Common-threats-in-web-applica. June 2005.

[9] J. Shanmugam1, Dr. M. Ponnavaikko2, " Cross Site Scripting-Latest developments and solutions: A survey". Pilani, India : s.n., Vol. 1, No. 2. September 2008.

[10] Safelight of securityadvisors, " Cross Site Scripting (Stored XSS) demo." [Online] http://www.youtube.com/watch?v=7M-R6U2i5iI. Jan 2009.

[11] Safelight of securityadvisors, " Cross Site Scripting (Reflected XSS) demo." [Online] http://www.youtube.com/watch?v=V79Dp7i4LRM. Jan 2009.

[12] w3schools.com, "HTML <iframe> Tag" [Online] http://www.w3schools.com/tags/tag_iframe.asp.

[13] B. Sullivan, "Top 10 security vulnerabilities in .NET configuration files" [Online] http://www.devx.com/dotnet/Article/32493/1954.

[14] Ms. R. Royal, Dr. P. Singh Walia, "Detecting and previnting web attacks by filters", .s.l : International Journal of Enterprise Computing and Business, Vol. 2. 2230-8849. 1 January 2012.

[15] G. Singh, H. Singh and N. Kaur, "Web application vulnerability assessment and preventing techniques", International Journal of Enterprise Computing and Business. India, Vol. 2. 2230-8849 1 January 2012.