Sécurité – OWASP Top 10 en 2-2

Dans le précédent article, nous avons posé les bases permettant de comprendre comment évaluer les risques de sécurité pesant sur nos applications. Il est temps maintenant de passer en revue les 10 risques de l’OWASP.

Ici, vous trouverez une photographie aérienne à 10 000 mètres d’altitude qui va nous fournir une vue d’ensemble du chemin que nous allons parcourir. Je vais vous présenter chacun des gagnants du Top 10 de manière succincte. Vous saurez alors de quoi nous allons parler par la suite et serez à même de juger si vous êtes concernés ou non.

1 – Injection

En gros, c’est quand une donnée entrée dans votre application (par une saisie utilisateur, par un middleware, lors de la lecture d’un fichier ou par n’importe quel autre moyen) est à un moment traitée comme du code. Si votre application contient une telle vulnérabilité, l’attaquant pourra entrer une commande dommageable, telle qu’une suppression en masse, ou déjouer des contrôles d’accès mis en place. Le type d’injection le plus connu est l’injection SQL. Cela dit, il en existe bien d’autres. On recense notamment l’injection LDAP, l’injection XPath, l’injection XSLT, l’injection de commande système, l’injection de code, etc.

2 – Violation de gestion d’authentification et de session

Une grande majorité de nos logiciels permettent aux utilisateurs de s’authentifier. C’est ce qui nous permet de leur proposer des services et fonctionnalités spécifiques à leur identité. Il est cependant fréquent de ne pas implémenter l’étape d’authentification correctement, laissant la possibilité à un attaquant de voler identités, sessions et codes d’accès à des utilisateurs innocents.

3 – Cross-Site Scripting (XSS)

Pourquoi XSS demanderont les curieux ? Probablement parce que CSS n’inspirait par suffisamment la peur dans l’esprit des professionnels de l’IT*… On voit que les gourous de la sécurité n’ont pas bossé sur de gros projets Web. Personnellement, j’ai connu des feuilles de styles qui m’ont fait faire des cauchemars! Mais on s’égare… Ici, l’attaquant fait  exécuter au navigateur de l’utilisateur des scripts qui ne font pas partie de notre application. Cela lui permet, entre autre, de l’espionner, de voler sa session ou son mot de passe, de le rediriger de manière plus ou moins transparente sur un site malveillant, etc…

* La minute intello: la lettre X est une croix. Croix en anglais se dit « Cross », d’où XSS pour Cross Site Scripting  L’utilisation de l’abréviation XSS au lieu de CSS permet de différentier l’attaque de la technologie de mise en forme.

4 – Références directes non sécurisées à un objet

Là, c’est très simple. Votre programme dévoile à l’utilisateur (ou autre client) un ID spécifique pour aller chercher un objet particulier – tel qu’un enregistrement en base de données ou un fichier – et ne vérifie pas si le demandeur a le droit d’accéder à la ressource. Un utilisateur astucieux peut alors récupérer des informations auxquelles il n’a pas accès.

5 – Mauvaise configuration de sécurité

La sécurité de nos applications ne se limite pas au code que nous écrivons. Celles-ci doivent être déployées sur des environnements protégés et maintenus. L’utilisation d’une vieille version de Java (sans vouloir troller) peut permettre à un attaquant de prendre contrôle de votre machine.

6 – Exposition de données sensibles

Nos utilisateurs nous font confiance avec leurs données sensibles. Il convient donc de les manipuler et de les stocker avec soins. Interdit donc d’enregistrer les mots de passe et numéros de cartes de crédit en clair dans la base de données…

7 – Manque de contrôle d’accès au niveau fonctionnel

Vos applications ne permettent pas à tous les utilisateurs d’accéder à l’intégralité des fonctionnalités qui la composent. Souvent, ça se traduit par des menus plus ou moins fournis dans l’interface graphique. Lorsque le seul contrôle d’accès à une fonctionnalité est fait côté client, l’application est vulnérable : un attaquant peut aisément déjouer la vérification et utiliser le programme à sa guise.

8 – Falsification de requête intersite (CSRF ou XSRF)

L’attaque XSRF est probablement ma favorite ! Basée sur le fonctionnement même du protocole http, elle consiste à capturer une requête légitime à un site – comme, par exemple, la requête qui est envoyée au serveur lorsque vous cliquez sur « ajouter à mes âmes sœurs » sur Rencontric. Avec un peu de ruse, l’attaquant peut forcer les utilisateurs qui tomberont dans son piège à effectuer l’action capturée, s’ajoutant ainsi aux âmes sœurs de millions d’utilisateurs.

* La minute interro: Pourquoi XSRF alors qu’on parle de Cross Site Request Forgery? Vous ne devinerez jamais…

9 – Utilisation de composants avec des vulnérabilités connues

A moins que vous ne fassiez partie de ces furieux qui veulent tout recoder pour comprendre ou parce que « vous savez que vous pouvez faire mieux », vous utilisez probablement dans vos applications des composants développés par d’autres. Ces composants peuvent être vulnérables et rendre votre système perméable à une attaque.

10 – Redirections et transferts non valides

De nombreuses applications redirigent les utilisateurs vers de nouvelles pages ou vers d’autres sites. Il est commun de faire cette redirection via paramètre d’URL. Lorsque l’URL cible n’est pas validée, un attaquant peut profiter du système pour rediriger un utilisateur de votre site – site en lequel l’utilisateur a pleinement confiance – vers un site malveillant.

Référence: OWASP Top 10 2013