Cross Site Attacks (XSS) what is that all about?

 

“Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications. XSS enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007. Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site’s owner.”

 

All user’s inputs can be a back door for attacker to attack your site. User’s inputs that we will categorize as un-trusted inputs are :

If an attacker can get our site to return some javascript to our visitors, then the attacker’s script can take control of our visitors’ browsing session and by this the attackers can collect the personal information (passwords, credit card details) of our visitors. There are two main ways an attacker follow to get this:

1. Persistently:  by entering formed malicious input into some feature and hoping we will store it into our database and then issue it back to other visitors.
2. Non-persistently or Passively : by finding a way of sending malicious data in a request to our application and having our application echo that data back in it is response. The attacker then finds a way to trick a victim into making such a request.

The Razor view engine helps protect us against XSS attacks by encoding any data that we refer to using the @ tag to make it safe to display as HTML. This means when we request an URL with a javascript code as a query string, Razor processes the query string value and replaces the special characters and rendering javascript code as a simple text.

Razor view engine treats the contents of MvcHtmlString objects as if they were encoded, even when that is not the case. We can use Html.Raw helper method to include our HTML into the web page without it being encoded.

The goal of request validation is to stop potentially dangerous data ever reaching the application. If the user tries to submit data that looks like it might be HTML, Then ASP.Net throws an exception. This happens before the request is passed to the MVC Framework, so our application never receives the data the user has sent. But the problem with Request Validation is that it rejects any data even slightly resembling an HTML tag, and this can include valid data.

In ASP.Net MVC Framework, request validation is enabled by default. You can disable it by decorate your controller/action method by ValidateInput attribute and passing false to it. If you decorate the controller with it, that means you enabled/disabled request validation for all action methods within this controller (of course not recommended). If you decorate the action method by that attribute, that means you enabled/disabled request validation for all posted data/model properties. Also you can disable request validation for a specific property by decorate it with AllowHtml attribute.

So what if we want to accept javascript code from the user, i.e post a question on stackoverflow. of course we don’t want to refuse it or disable request validation totally. Fortunately, the Ajax helper class has method called JavaScriptStringEncode, which encodes a string so that it safe to display and escapes characters so that JavaScript will understand it. In such case we have to use Html.Raw method around the result generated by the Ajax helper method. If we don’t do this, then Razor HTML encodes the result, and we are back where we started. Session Hijacking:
ASP.Net identifies users by session ID cookie which called ASP.Net_SessionId by default, and if we use Forms Authentication, then a second cookie is used called /AUTH. If an attacker can obtain these cookies, then they can include them in a request to our server and impersonate one of our users. The browser by default preventing the javascript from a site to access cookies of another site. But if the attacker has been able to inject a script into one of our pages, then the browser believes that the script is part of our application and grands access to the session cookies.

We can protect our site by keeping a record of each client IP address when a session starts, we can deny any requests that originate from a different IP. But you should avoid this technique when you deal with the public internet.

We can mark a cookie with the HttpOnly flag, and the browser will hide its existence from javascript but will continue to send it via all HTTP requests. By default ASP.Net marks ASP.Net_SessionId and /AUTH as HttpOnly. Of course you can apply HttpOnly to your session cookies when you create them.

To save me repeating myself talk a look at this post Preventing Cross Site Request Forgery