Protect yourself from the XSS (Cross-site scripting) vulnerability

Introduction: What is the XSS Fault

Article for web developers and site administrators.

XSS comes from Cross-Site Scripting and as the CSS acronym was already taken for Cascading Style Sheets , we used an X for "cross".

The flaw is to inject an arbitrary script into a page to cause a well-defined action . Other users run the script without realizing it as soon as the page is opened.

Cross also means crossing, because one of the goals of the flaw is to run a script to transmit data from one site to another.

This problem is mainly at the level of cookies, because one can for example recover the cookies of a site A from a site B. One can thus recover the cookies of anyone, even the administrator of a site .

Note also that we can exploit the XSS fault in JavaScript but also with other languages.

What can be done with an XSS Fault?

There are two types of XSS faults:

1) Permanent XSS

This is when the script is stored on the external server (database). It is therefore retrieved and executed at any time on the site by any user.

2) Non permanent XSS

The script is often embedded in a URL and is executed without being stored on a server.

We can distinguish several non-exhaustive possibilities of exploiting this fault:

• A redirection of the page to harm the users or to attempt a phishing attack.
• Stealing sessions or cookies. (So ​​pretending to be another user to perform actions)
• Make the site inaccessible by using loop alerts or any other harmful means.

How do I know if my site is fallible?

When you pass data (comments, article posts, search for a term, etc.) via your site, if a script passed as:

<script type = "text / javascript"> alert ('test'); </ script>

runs, that is, if the "test" dialog box appears, your site is fallible .

Example of exploiting XSS flaw

The first XSS worm named Samy spread on myspace in 2005. All users who visited a specific page re-propagated the worm in turn.

I can not name all the possibilities, but know that it happened to me to see flaws XSS in the nicks of the members. The administrator relied only on JavaScript that checked if the nick contained only letters and numbers, but did not check on the server side.

How to protect yourself

It is absolutely necessary to use the php functions htmlspecialchars()which filters the '<' and '>' or htmlentities()which filters all the entities html.

These functions should be used on user entries that will appear later on your site. If they are not filtered, scripts like the ones we saw above will run with all the trouble that ensues.

Here is an example of using this function:

<?php echo htmlspecialchars($_POST['nom']); // echo affiche les données sur un page, du coup on protège l'affichage avec la fonction htmlspecialchars?>

As possible, we must place cookies with the HttpOnly parameter , preventing their recovery with JavaScript (Attention it is not necessarily supported by all browsers).