Sensibilisation aux vulnérabilitésapplicatives Web – Know your enemy
Sensibilisation aux vulnérabilitésapplicatives Web – Know your enemy
0 0
dsic-securite.github.com
On Github dsic-securite / dsic-securite.github.com
Sensibilisation aux vulnérabilitésapplicatives Web
Les vulnérabilités
sont issues de faiblesses d'implémentationà différents niveaux
- Choix d'architecture (infrastructure ou logicielle)- non implémentation d'un DMZ et donc exposition de serveurs sensibles
- Configuration des serveurs (OS, applicatif)- système non patché, installation par défaut avec des droits trop permissifs, des mots de passe par défaut
- Développement logiciel- ce qui nous intéresse, détails à suivre...
Quelques chiffres anxiogènes...
Les conséquences
de l'exploitation des vulnérabilités
L'exploitation d'une faiblesse de développement, de configuration, d'infrastructure, peut mener à :
- Une fuite de données- notamment personnelles comme les mots de passe, qui font régulièrement les choux gras de la presse spécialisée, mais aussi de plus en plus de la presse grand public, ce qui conduit directement à...
- Une atteinte à l'image- la reprise sur les réseaux sociaux de failles de sécurité, avérées ou non, le défaçage (defacement), le relai d'une fausse information (ex: piratage de comptes Twitter de Reuters ou d'Associated Press qui a fait plonger le DJ)
- Une interruption de service- attaque ciblée par déni de service (DoS et par extension DDoS), blocage de comptes utilisateurs suite à attaque par brute force, qui entraine une coupure de service et donc une perte directe du chiffre d'affaire
Quelques malheureux exemples récents
- Home Depot - 60 millions de cartes de crédit volées, fuite la plus importante à ce jour (sept 2014)
- Domino's Pizza - 650 000 comptes client, une demande publique de rançon à la clef, relayée dans toute la presse
- eBay - 145 millions de comptes, tous les utilisateurs ont été invités à changer leur mot de passe, EBay Inc. perd 2,6% à l'ouverture de Wall Street soit environ 166 M$ de capitalisation
- Adobe - 152 millions de comptes
- Target - 110 millions de clients, des données de carte de crédit volée (40 millions)s
- Heartbleed - le bug de sécurité le plus important à ce jour, impacts impossibles à quantifier (potentiellement plus de 2 ans d'antécédent, bug introduit fin 2011), plusieurs millions de serveurs...
Know your enemy
Pour éviter les vulnérabilités, il faut tout d'abord les connaitre Il existe des référentiels qui font l'unanimité :
- OWASP : Classification des vulnérabilités - Top 10 OWASP
- CWE : Common Weakness Enumeration - Top 25 des erreurs de conception/développement
- SANS : Critical Security Controls - Top 20 des contrôles de sécurité
- WASC : Web Application Security Consortium - Classification des menaces et attaques
OWASP
- Open Web Application Security Project
- Un organisme indépendant, acceptant toute contribution, mais qui n'est lié à aucun éditeur de solution
- Qui produit et met à disposition toute sorte de ressources
- une base documentaire riche et régulièrement mise à jour
- des fiches synthétiques sur les principales failles de sécurité (top 10 en anglais ou en français)
- des exemples de code sécurisé, des framework pour se prémunir des attaques (ex: ESAPI)
- des outils d'intrusion pour tester le degré de vulnérabilité de son système (ex: ZAP Proxy)
- ...
Les bons réflexes
Les contrôles sur lesquels doit se concentrer tout développeur : OWASP Proactive Controls
Les 3 principales vulnérabilité à connaitre :
- Cross site Scripting (XSS) : injection sur le navigateur client, persistente ou non
- Injections : SQL Injection, Command Injection, LDAP Injection...
- Cross Site Request Forgery (CSRF) : manipulation de la session d'un utilisateur à l'insu de son plein gré
All input is evil
S'il ne fallait retenir qu'une règle, c'est celle de ne jamais faire confiance aux sources externes, à commencer par les entrées utilisateur. La bonne pratique consiste soit à :
- filtrer pour n'accepter que l'attendu (de préférence en liste blanche, attention aux expressions rationnelles...)
- encoder pour éviter toute injection (SQL injection, XSS, ...)
Ne pas réinventer la roue, des framework de filtrage/encodage existent (ESAPI par ex.)
Recommandations pour les applications Web
En plus des guides de l'OWASP, des bonnes pratiques existent pour gérer la sécurité des applications Web
- Utiliser des framework dédiés à la sécurité (il est trop dangereux et coûteux de chercher à réinventer la roue)Exemple : Spring Security
- Transférer et Stocker les données sensibles de manière sécurisée (securing data at rest / in transit)Exemple : HTTPS, "stockage" des mots de passe selon un algorithme de hashage sécurisé (bcrypt, scrypt, ...)
- Tracer (et si possible analyser les traces...)Exemple : centraliser les logs avec Syslog, Logstash, ...
Page wiki : recommandation pour la sécurité des applications Web
Pour résumer
- Connaitre les vulnérabilités pour pouvoir s'en protéger (référentiel OWASP), être curieux des techniques d'attaque et pourquoi pas se mettre dans la peau d'un pirate...
- Avoir une position défensive sur toute donnée en entrée du système, particulièrement celle fournie par le navigateur (formulaire, paramètre d'URL, fichier...), se poser la question "comment pourrais-je contourner le bon fonctionnement de mon application ?"
- Utiliser des framework/bibliothèque sécurité, ne pas réinventer la roue