Web application attack: XSS

1.     Introduction:

The web has grown exponentially in last few years catering as the foremost platform for e-commerce, Social networking, Banking, Online shopping, Entertainment and much more. Web servers and web applications are being deployed to provide services and carry out operations where the medium World Wide Web is involved. Naturally web application security issues have surfaced, which have become a major cause of concern for organizations which depend on www for their functioning. The field of web application security has increased at great pace with new vulnerabilities and security flaws coming into picture. There will be hardly anyone reading this article, who has not heard of news related to website compromise, user account hacking or ethical hacking. The OWASP lists top 10 web application security risks. OWASP stands for open web application security project. It is a worldwide charitable organization focused on improving security of application software. XSS is a common vulnerability found in web applications which ranks 2^nd out of OWASP’s top 10. Nearly 39% of web application security flaws are related to XSS. In this article, I will try to explain how XSS works, its dangers and how these attacks can be prevented.

2.     What is XSS:

XSS stands for Cross site scripting. (Do not confuse XSS with CSS which stand for ‘Cascading Style Sheets’ and are nowhere related). XSS is basically, injecting malicious scripts into webpages or webapplications through an HTTP request which tampers with the expected output from web application. In this, the malicious scripts (precisely, Javascript) exploits the interpretation of scripts in web browser. The browser is fooled into executing scripts that appear to come from trusted website. These XSS attacks occur when web applications send user-supplied input to the browser without proper sanitization. The idea of XSS will get clearer when we discuss the first example in section ‘Finding XSS vulnerabilities’.

3.     Risks of XSS flaws:

Okay, so, what’s the deal when my web browser executes some strange scripts? What all damage it can possibly have? Well, if the website you’re accessing has XSS vulnerability, an attacker with good knowledge can hijack your session with server, steal cookies from your PC, deface webpages, redirect you to unintended webpages and introduce malware scripts into your browser. XSS also aids phishing-a common way of hacking social networking and bank accounts. XSS vulnerabilities are classified as very widespread and most prevalent web application security vulnerability by OWASP. Impacts of XSS are classified as ‘moderate’. Risks arising from XSS range from constantly popping annoying pop-ups to total user account compromise, installing malware, virus on victim’s PC.

4.     Types of XSS:

Reading theory about security stuff like this is always boring. I promise I’ll quickly introduce you to the 3 types of XSS and then we’ll move on to next topics which I hope, you’ll find interesting. Anyways, the 3 types of XSS attacks are called - stored, reflected and DOM based.

1)     Stored:

Stored XSS attacks are those when the malicious script permanently gets stored on the webpages, databases of victim website. Think of it like this- there is this news website which allows you to enter comments on their news articles. The comments stay on the page forever. Now instead of putting comment, you entered a javascript and sent it. Now this javascript will stay there forever and execute every time page is accessed. Here you just performed stored XSS attack. It is found in chatrooms, shoutboxes, bulletin boards, blogs etc.

2)     Reflected:

According to me, reflected XSS vulnerabilities are the most common of all vulnerabilities. For example, consider a situation where a website asks you to enter your name and then greets you by name. Like, “Good Morning !”. Now instead of putting your name, if you put a javascript, it will be echoed back from server and your browser will execute the script. Here we performed reflected XSS attack. It is called ‘reflected’ because the name entered by you doesn’t get stored on website. Error messages, search results, or any other response from server that includes atleast some of the user-supplied data maybe vulnerable to reflected XSS.

3)     DOM based:

Very rare. DOM based XSS are quite similar to the reflected XSS except that script doesn’t need to be echoed from server. Script is injected into the browser’s own DOM environment. The malicious code is passed as a parameter to the script residing on a webpage which unknowingly executes it.

5.     Finding XSS vulnerabilities:

In this section, we’re actually going to find a XSS vulnerability. XSS is basically injection of scripts into webpages. Consider the following simple PHP code which is vulnerable to XSS.

$query = $_POST['query'];

if (isset($_POST['query']))

{

echo "You searched for " . $query . "!";

}

echo "
Please type your search query below:

";

?>

If you have a web server installed, try running this PHP file. It asks you to enter a search query and simply prints “You searched for ”. Suppose if you type ‘PICT’, it will print, “You searched for PICT!”. The URL in this case will be:

http://www.example.com/search.php?query=PICT

Now, what if we replace “PICT” with following snippet of code?

URL will become:

http://www.example.com/search.php?query=

Here, the page will print upto “You searched for “ and then it will actually parse as any other HTML tag and execute the javascript code in between. The alert function is just used for demonstration and it can be replaced with any other javascript code-as we explore in next section. This is a reflected type of XSS attack.  Detection of XSS vulnerability is very easy by testing the input fields or manual analysis of web application code. If a webpage stores user supplied input as an attribute of an HTML tag, putting “> before the script tag will terminate the previous tag and hence browser will interpret script smoothly. Not only javascript, it is even possible to inject HTML code into XSS vulnerable webpage as follows:

http://www.example.com/search.php?query=

Great website!

As you can guess, this will print “You searched for “ and then ‘Great website’ in bigger font size. Similarly, all other HTML tags can be used here. Some mechanisms to thwart XSS attempts like magic quotes can be bypassed with String.fromCharCode() javascript function,  URL obfuscation, hex encoding etc but that is out of scope of this article.

6.     Exploiting XSS flaws:

1)     Injecting phishing page:

Phishing is basically, making the victim log in to a fake login page where the credentials entered by him are recorded by attacker. Their username and password is recorded in some database and they’re redirected back to original website. This is very very common hack these days and lots of people are attempting to ‘phish’ each other’s facebook accounts! If a webpage has XSS vulnerability, the contents of entire webpage can be modified to make it look like a login page where user can enter his credentials. The following example URL will demonstrate this:

http://www.example.com/search.php?query=

Username:
Password:

The above code is self-explanatory where write.php is a PHP file which records username and password sent to it through HTTP GET request.

2)     Iframe phishing:

This is similar to previous one. Instead of putting long html tags like

, etc, the attacker injects iframe in the target webpage as follows:

http://www.example.com/search.php?query=

notice that the 100% height and 100% width occupies the whole size of window and the victim won’t notice the difference if they’re foolish enough!

3)     Redirect phishing:

The injected javascript could be coded to redirect the user to another webpage where the attacker’s phishing page is hosted.

http://www.example.com/search.php?query=

where fakepage.htm is the page attacker wants victim to visit.

4)     Cookie stealing:

A user’s session with server can be hijacked once the attacker gets his cookie. The website should have XSS vulnerability for successful execution of this attack. The attacker can craft his link as follows:

http://www.example.com/search.php?query=

When the user opens such kind of link, the cookie stored by current session (i.e. by example.com) is passed as ‘cookie’ parameter to ‘write.php’ which is a PHP file hosted by attacker on his own domain. This php file records the cookie into database.

5)     Website defacement:

A website is prone to defacement if it has stored XSS vulnerability on it. The attacker can inject a script which can entirely modify the way a webpage looks. The injected script can make any changes to the page relying upon the power of Javascript. I’m sure you must have seen websites which say that they’re ‘hacked’ alongwith some message from hackers!

6)     Javascript events:

Javascript event triggers can be wisely used to perform XSS on websites which allow HTML tags but ban the usage of

When the error page is loaded, browser will parse