Comment se protéger efficacement des attaques par injections de script ?

Ici, le serveur exécute lui-même une commande propre au langage qu’il utilise.
Un attaquant doit alors utiliser des fonctions spécifiques à un langage.
Cependant la plupart des langages utilisés sur un serveur peuvent interagir avec le système d’exploitation, les risques sont alors similaires à l’OS command injection
Cependant, là où l’injection de commande est située uniquement du coté serveur, une injection de script peut aussi être effectuée du coté client si le javascript utilisé le permet.

Impact

Les injections de script possèdent les impacts de 3 failles:

OS Command Injection

Les injections de script permettent d’effectuer des injections de commandes avec des fonctions comme system() qui exécute une commande sur l’OS (Voir l’article sur les injections de commandes). Injection SQL Si le serveur victime utilise une base de données, il est alors possible d’effectuer des injections SQL et d’avoir les mêmes risques que pour ces dernières. (Voir l’article sur les injections SQL). Cross Site Scripting (XSS) Lorsqu’une vulnérabilité d’injection de script est située du côté client, l’application devient alors vulnérable au XSS réfléchies {reflected XSS}, les conséquences peuvent être multiples. (Voir l’article sur les injections de script).

Comment un hacker peut-il injecter du code ?

1. Un coté client et un coté serveur vulnérable

Pour illustrer une attaque par injection de script, je vais utiliser l’exemple d’une application web contenant 2 failles: une située côté client et une située coté serveur. Il est conseillé d’avoir suivi les articles sur les injections de commandes et le Cross Site Scripting afin de bien comprendre ce qu’est une commande injection et le fonctionnement d’une XSS réfléchie. Le site vulnérable permet de s’entraîner aux équations, un bouton « generate » permet d’afficher une équation aléatoire ainsi qu’un formulaire permettant de la compléter.

2. Exploitation de l’injection de script du coté serveur

Sur le formulaire, Loris va tenter de rentrer une commande Shell.

Il se retrouve avec un message d’erreur PHP.
Il comprend alors que son entrée est traitée par la fonction eval, une fonction permettant d’exécuter du code PHP dans un programme PHP.
Afin de pouvoir exécuter des commandes Shell, il va alors transformer son entrée en :

La fonction système va permettre d’exécuter n’importe quelle commande Shell, le code malicieux {malicious code} exécuté par le serveur ressemblera alors à ceci :

En faisant un ls, Loris voit un fichier nommé « routes.txt »,

En utilisant cat dessus, Loris se retrouve avec tous les chemins disponibles sur le site web, notamment « /{nom_endpoint} » qui n’est pas visible sur la page web.

3. Exploitation de l’injection de script du coté client

En se rendant dessus, Loris retrouve alors une page classique :

En regardant dans le code HTML, il remarque une section <script> faisant appel à la fonction eval, fonctionnant de manière similaire à la fonction eval en PHP mais avec de code Javascript. Cette fonction semble utiliser un paramètre de l’url.

Il est donc possible de faire exécuter du code javascript à un navigateur grâce à un paramètre dans l’url
En utilisant un code malicieux permettant de rediriger les cookies d’un administrateur vers son serveur avec ‘document.cookie’, Loris aurait alors accès à un compte avec des privilèges élevés.
Il lui suffit donc de construire son code pour une XSS réfléchie :
Puis de le placer dans le paramètre « value » de l’url.
Pour finir, en utilisant un peu d’ingénierie sociale, il n’a plus qu’à envoyer un mail à un administrateur du site afin de le faire cliquer sur le lien contenant l’attaque pour exécuter le javascript.

Quelles sont les protections contre les attaques par injection de script ?

Pour se protéger des attaques par injection de script les recommandations des autres injections s’appliquent :

• Filtrer toutes les entrées utilisateurs
• N’autoriser que certaines valeurs afin de restreindre le champ d’action d’un utilisateur au maximum

Cependant les attaques par injections de script sont très dangereuses et impliquent d’énormes conséquences.
De plus, de telles fonctions sont généralement facilement remplaçables.
Il est donc obligatoire de ne jamais utiliser de fonction permettant d’exécuter un code entré pour l’utilisateur.

Comment se protéger des attaques par injections de script avec UBIKA Cloud protector

UBIKA Cloud Protector permet de protéger les applications web grâce à son moteur syntaxique qui lui permet de détecter la grammaire des différents langages utilisés du côté serveur : PHP, Java etc.

Dans cet exemple, UBIKA Cloud Protector va détecter 2 patterns malicieux : , et leur attribuer un score.
Le score total étant supérieur à la limite autorisée, la requête va être interceptée et l’utilisateur redirigé vers une page de blocage.