Comprendre les vulnérabilités web en 5 min – episode #1 : Injections!

A chaque jour ses nouvelles annonces de sites piratés, infligeant des pertes de données, mots de passe à leur propriétaires et utilisateurs.
En visitant un site web, la plupart des gens se disent “Humm, ce site est sûrement sécurisé”, ou ne pensent tout simplement pas à la sécurité qui devrait être évidente, mais la réalité est différente.
Les applications web sont sujettes aux attaques.

 

La fondation Owasp publie assez régulièrement le top 10 des vulnérabilités web, connu sous le nom de “Owasp top 10”. Au fil des prochaines semaines nous allons parcourir ce top 10 et tenter d’expliquer simplement ces vulnérabilités aux personnes non « techniques”.
Le premier article de cette série est dédié aux failles de type injection. Vous avez probablement déjà entendu parler de cette vulnérabilité, il s’agit de la plus répandue, et également de la plus connue, pour de mauvaises raisons…

Les failles d’injection sont très faciles à exploiter. Dès lors qu’un pirate a détecté l’une d’elles (assez facilement), il peut encore plus facilement utiliser cette vulnérabilité afin d’abuser de l’application. Aucun outil spécifique n’est nécessaire pour l’exploitation, et bon nombre de choses peuvent être effectuées lors qu’elles sont exploitées :
– perte de données
– corruption ou vol de données
– injection de données
– déni de service
– prise de contrôle du système, dans le pire des cas.
L’impact de ces vulnérabilités peut donc être très important.
Nous entendons souvent parler d’injection “SQL”, directement liées à la base de données de votre application, mais d’autres types de vulnérabilités existent, comme l’injection XPath, de commandes, de logs et d’autres encore.
Quel que soit le type d’injection, le principe de base de cette vulnérabilité est toujours le même : on ne peut pas faire confiance aux données fournies par les utilisateurs. Par exemple, les données fournies dans un formulaire de login, ou dans tout autre formulaire, ou dans une URL, peut potentiellement contenir des caractères spécifiques qui pourraient abuser de la confiance que vous mettez sur vos utilisateurs.
Faisons une métaphore simple afin de comprendre la vulnérabilité, sans parler de choses techniques:
Imaginez pendant un instant que vous gérez une banque (ou une bijouterie) : des gens entrent et sortent de votre établissement pour déposer de l’argent, en retirer, accéder à des services ou en acheter.
Si une personne malintentionnée rentre dans votre banque, elle pourrait potentiellement braquer la banque, ou voler les biens de vos clients comme leurs bijoux ou leurs téléphones…
Vous ne pouvez tout simplement pas être certain que 100% des gens se présentant à l’entrée de votre banque ont de bonnes intentions, vous devez donc vous préparer à chaque scénario.
La même chose se passe lorsque des utilisateurs rentrent des données malicieuses (le braqueur) dans votre site web (votre banque).
La banque est votre application web, et les portes de la banque sont les formulaires ou URLs de votre site web.
Retournons à notre faille d’injection: les données rentrées par un utilisateur vont être prises en charge par votre site (par exemple pour poster un commentaire sur un blog), et peuvent potentiellement impacter la logique du code lui même pour réaliser des actions malveillantes (effacer tous les commentaires, récupérer des logins…). En entrant du code dans l’application web et en suivant une certaines syntaxe, le site web obéira aux ordres du pirate.

 

La bonne nouvelle est que votre application web est plus facile à protéger que la banque!
Tout comme vous pouvez en quelque sorte contrôler qui rentre dans votre banque, à quelles parties de la banque le public peut accéder et éviter d’exposer des éléments sensibles, les développeurs peuvent:
– filtrer les données rentrées dans l’application (nettoyage des données)
– gérer les données avec précaution pour éviter des risques (requêtes paramètres, procédures stockées)
– mettre en place une liste blanche (whitelist) des caractères acceptés.
– appliquer une politique de moindre privilège, afin de réduire les risques en cas d’attaque partiellement réussie (le personnel d’accueil de la banque n’a pas accès à l’argent).

 

Ce type de vulnérabilité est véritablement facile à éviter et à corriger. La difficulté réside dans le fait de savoir que vous êtes vulnérable, ce qui peut être fait en réalisant un test de pénétration web, ou une revue de code complète.
N’attendez pas que votre site fasse la une!

Pour approfondir:
– Owasp injection prevention cheat sheet
– Query parameterization cheat sheet
– Owasp Top 10 2013

Autres articles dans cette série :