Thursday, March 19, 2015

Cross Site Scripting attack in MVC

As everyone liked the last week's blog post on Cross Site Request Forgery attack, I decided to post about another well-known security vulnerability in MVC applications. It's called Cross Site Scripting (aka XSS) attack. Its the most common security vulnerability across the web and can be the most nasty one.

Cross Site Scripting

In simple words, it's an attack whereby attacker injects some scripts into a web page which then affects the victim. These attacks are divided into 2 categories viz Active and Passive. Let's take a look at each of these one by one.

Passive Injection

This type of attack occurs when the website accepts unsanitized input by the attacker and later displays it to the victim. Suppose we have an online messaging board or blog that allows users to post comments. If the input is accepted as is, the attacker can inject a script tag in the comment which might be something like this:

Nice Post</div><script>src=</script>

The closing tag can close the previously open div and then a script tag mentions the javascript file to be executed. To find out the type of tag to close and how to structure the malicious comment might require some inspection of the web page and some hit and trials. This comment then gets saved on the server and gets displayed to others who access the webpage. The script tag posted by attacker won't be displayed when the page is rendered but the javascript will be executed on the client side. So the attacker can execute a malicious script on the victim's machine which can tamper the webpage or steal victim's personal information and send it to the attacker.

Using the script tag, attacker can point to an external javascript file or use embedded javascript. Here are some ways other than the script tag to execute javascript:

<img src="javascript:alert('Hacked');">

<body onload=alert("Hacked")>

<div style="background-image: url(javascript:alert('Hacked'))">

I can not cover all the ways by which the script can be inserted but the point is that attacker is able to execute some malicious javascript code on anyone's machine who accesses the website.

Active Injection

For active injection, the user input is directly used on the webpage and is not saved on the server. Suppose we have a website that takes user's name as input and shows a welcome message like this. Note that the name is coming from the query string parameter.

Active Injection

As an attacker, I can pass this as the query string parameter: Abhi\x3cscript\x3e%20alert(\x27EVIL\x27)%20\x3c/script\x3e. And this is what it does:

Active injection Attack
I was able to execute javascript code by manipulating the query string parameter displayed. Now everyone must be thinking that this is the script that the attacker executed on his own machine. How does it affect the victim? Well, the attacker might be able to make the victim click on such a malformed link which will then execute the malicious javascript on the client machine. To make the victim click on the link might require some social engineering or some other devious techniques. But again, some malicious code can be run on victim's machine without the victim's knowledge.


In this blog post, we saw what cross site scripting attack is and it's 2 different categories. In the next week's post, I am going to cover how to prevent the cross site scripting attacks.
For future updates to my weekly blog, please subscribe to the blog and follow me on Twitter. Until then Happy Coding :)

"Professional ASP.NET MVC 5"


  1. A brief informative article. Thanks Abhi.

  2. A while back I was working on a Splunk setup and needed to automate the backup and restore process. Since Splunk does not do this natively I thought I should whip-up something quickly. Serious Security CCTV