1
TOP 10 CONTRÔLES PROACTIFS POUR LA SÉCURITÉ DES
APPLICATIONS WEB
BY ABDESSAMAD TEMMAR (TMR)
TEMMAR.ABDESSAMAD@GMAIL.COM
2
OWASP Top Ten Proactive Controls
1A1 – Requêtes
Paramétrées
A2 – Encoder les
données
A3 – Valider toutes les
données ent...
3
10: Conception et architecture de sécurité
Lors de la conception et de l'architecture logique/physique d’une application...
4
9: Inclure les exigences de sécurité spécifiques
Trois catégories principales d'exigences de sécurité peuvent être défin...
5
• 8: Exploiter les fonctionnalités de sécurité des frameworks et API de sécurité
 Il est recommandé d’utiliser des API ...
6
7: Implémenter la journalisation et la détection d’intrusion
 La journalisation ou « Logging » joue souvent un rôle fon...
7
7: Implémenter la journalisation et la détection d’intrusion
 Les système de détection/prévention d’intrusion permet de...
8
6: Protéger les données et la vie privée
 La protection des données doit être assurée au niveau des deux axes suivants ...
9
6: Protéger les données et la vie privée
 La protection des données doit être assurée au niveau des deux axes suivants ...
10
5: Etablir les contrôles d’identité et d’authentification
 Complexité des mots de passe : au minimum 8 caractères, une...
11
4: Implémenter les contrôles d’accès appropriés
 Le contrôle d’accès est le mécanisme qui permet d’autoriser/interdire...
12
4: Implémenter les contrôles d’accès appropriés
if (user.isManager() || user.isAdministrator() || user.isEditor() || us...
13
4: Implémenter les contrôles d’accès appropriés
Problématique
Solution
L’application doit garantir l’accès uniquement p...
14
3: Valider toutes les données entrantes
 Il est absolument essentiel de considérer toutes les données extérieures à l’...
15
3: Valider toutes les données entrantes
Exemples pratique :
Utilisation des expressions régulières (méthode liste blanc...
16
2: Encoder les données
<
17
2: Encoder les données
&lt;
18
2: Encoder les données
 L’encodage des données permet d’éviter les failles de types XSS en transformant des chaînes de...
19
2: Encoder les données
Problématique
Solution
Une page Java JSP est vulnérable au XSS
1) <input type="text" name="data"...
20
1: Requêtes paramétrées
 L’injection consiste à envoyer des données non prévues à une application afin de détourner le...
21
1: Requêtes paramétrées
‘ ;
22
1: Requêtes paramétrées
 L’Utilisation des requêtes paramétrées permet d’assurer une protection fiable contre les inje...
23
Pour plus d’informations ...
https://www.owasp.org/index.php/OWASP_Proactive_Controls
Prochain SlideShare
Chargement dans…5
×

OWASP TOP 10 Proactive

679 vues

Publié le

Top 10 des contrôles proactives pour la sécurisation des applications Web.

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
679
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5
Actions
Partages
0
Téléchargements
25
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

OWASP TOP 10 Proactive

  1. 1. 1 TOP 10 CONTRÔLES PROACTIFS POUR LA SÉCURITÉ DES APPLICATIONS WEB BY ABDESSAMAD TEMMAR (TMR) TEMMAR.ABDESSAMAD@GMAIL.COM
  2. 2. 2 OWASP Top Ten Proactive Controls 1A1 – Requêtes Paramétrées A2 – Encoder les données A3 – Valider toutes les données entrantes A4 – Implémenter les contrôles d'accès appropriés A5 – Établir les contrôles d'identité et d'authentification A6 – Protéger les données et la vie privée A7 – Implémenter la journalisation et la détection d'intrusion A8 – Exploiter les fonctionnalités de sécurité des Frameworks et bibliothèques de sécurité A9 – Inclure les exigences de sécurité spécifiques A10 – Conception et architecture de sécurité
  3. 3. 3 10: Conception et architecture de sécurité Lors de la conception et de l'architecture logique/physique d’une application Web, on retrouve plusieurs domaines pour lesquels il est nécessaire de se préoccuper de la sécurité Maitrise des outils de développement : Le choix de langage(s) et de plate-formes (OS, serveur web, messagerie, base de données) peut entraîner des risques de sécurité spécifiques que l'équipe de développement devra comprendre et gérer. Hiérarchisation, confiance et dépendances : Décider quel contrôle doit être appliqué au client, à la couche Web, à la couche de logique métier, à la couche de gestion des données, et où établir la confiance entre les différents systèmes ou différentes parties d'un même système (la frontière de confiance). Gérer la surface d'attaque : Comprendre la façon dont les attaquants peuvent rentrer dans le système et les données qu'ils peuvent récupérer. Une appréciation des risques peut ensuite être réalisée afin de modéliser et d’anticiper les menaces liées au contexte d’utilisation et au fonctionnement de l’application Web.
  4. 4. 4 9: Inclure les exigences de sécurité spécifiques Trois catégories principales d'exigences de sécurité peuvent être définies lors de la phase de l’analyse fonctionnelle du cycle de développement : 1. Éléments et fonctions de sécurité : les contrôles de sécurité visibles de l’application, tels que l’authentification et le contrôle d’accès. Exemples : Vérifier l’identité de l’utilisateur lors du changement de mots de passe, ou Modification/édition d’une donnée est correctement journalisée. 2. Cas d'abus de la logique métier : les « uses cases » ou « user stories » doivent prendre en considération les scénarios d’utilisation malveillante, afin de pouvoir déterminer les faiblesses dans la validation et le traitement des erreurs qui impacteront la fiabilité et la sécurité de l'application. Exemple : qu'arrive-t-il si une étape échoue / expire ou si l'utilisateur tente d'annuler ou de répéter une étape ? 3. Classification des données & exigences de confidentialité : l’application doit assurer la protection des données à caractère personnel (respect des obligations de la CNIL).
  5. 5. 5 • 8: Exploiter les fonctionnalités de sécurité des frameworks et API de sécurité  Il est recommandé d’utiliser des API / Framework de « sécurité » qui évitent d’avoir à recréer des mécanismes de sécurité de base (authentification, filtrage des données, etc.).  Exemple d’API / Framework de sécurité :  Une attention particulière doit être portée lors de l’utilisation des API ou des frameworks, notamment :  Le choix du Framework / API : privilégier l’utilisation des Framework / API les plus documentés, testés et éprouvés afin de s’assurer qu’ils ne portent pas de vulnérabilités ou de code malveillant.  Suivi des mises à jours. il est essentiel de garder ces Frameworks et API à jour comme décrit dans le chapitre "Utilisation de composants avec des vulnérabilités connues" du document OWASP Top Ten 2013. Gestion des privilèges des utilisateurs Un API souple et sécurisé pour la cryptographie OWASP Java Encoder Project OWASP Java HTML Sanitizer Project
  6. 6. 6 7: Implémenter la journalisation et la détection d’intrusion  La journalisation ou « Logging » joue souvent un rôle fonctionnel essentiel dans la sécurité des applications Web.  La fonctionnalité de « journalisation » ne doit pas être limitée uniquement au débogage et diagnostic des erreurs de code. Elle doit pouvoir retracer les éléments suivants :  La surveillance des applications  Analyse et compréhension des affaires  Les activités d’audit et de vérification de la conformité  La détection d’intrusion dans les systèmes  Informatique légale (Forensics)  Définir une politique de gestion des fichiers log rigoureuse (stockage, rotation, rétention) afin de se protéger.  Encoder les données non sécurisées avant de les journalise Pour vous prémunir contre l'injection de journaux de log (également appelé Log Forging / Forgeage de log).  Utiliser un API flexible et sécurisé : Apache Log4j2 OWASP – Logging Cheat Sheet
  7. 7. 7 7: Implémenter la journalisation et la détection d’intrusion  Les système de détection/prévention d’intrusion permet de surveiller le trafic Web en « Temps Réel », par opposition à la consultation des traces (« logs ») qui se fait forcement en différé, sans parler des difficultés de repérer des failles.  Le rôle d’un IDS/IPS : l’émission d’alertes qui permettront la détection de la préparation d’une attaque, (scans massifs à la recherche de failles sur un ensemble de machines …), une attaque en cours (trafic sur des ports correspondants à des failles).  Le projet OWASP AppSensor Project décrit comment mettre en œuvre la détection d'intrusion dans le contexte d’une application Web :  les sondes ou les points de détection : plus de 50 points d’entrés qui peuvent être utilisés pour identifier les attaques Web.  Réponse sur incident/attaque : les mesures/actions à prendre en cas de problèmes de sécurité rencontrés dans l’application.  Mesures de défense proactives : identifier et éliminer le risque lié à une vulnérabilité avant qu’elle soit exploitée par un attaquant
  8. 8. 8 6: Protéger les données et la vie privée  La protection des données doit être assurée au niveau des deux axes suivants :  Protection des échanges  Afin de garantir la protection des données sensibles transmissent au client (navigateur), il est fortement recommandé de protéger le canal de communication via le protocole SSL.  Les avantages de l’utilisation du HTTPs :  Confidentialité : un pirate ne peux pas lire les données  Intégrité : un pirate ne peux pas altérer les données échangés entre le serveur et le navigateur  Authenticité :  S’assurer que la configuration du SSL au niveau du serveur respecte les exigences de sécurité :  Eviter l’utilisation d’une implémentation obsolète.  Utiliser un certificat valide et signé par une autorité de confiance reconnue.  HTTP Strict Transport Security (HSTS) : Forcer l’utilisation du protocole HTTPS. OWASP – Transport Layer Protection Cheat Sheet1
  9. 9. 9 6: Protéger les données et la vie privée  La protection des données doit être assurée au niveau des deux axes suivants :  Stockage des données  Le stockage des données sensibles représente un point crucial pour la sécurité des applications Web. Le choix des algorithmes cryptographique utilisés doit respecter les exigences de sécurité afin de se prémunir contre les attaques de cassage des mots de passe.  Bonnes pratiques pour le stockage sécurisé des mots de passe :  Salage des mots de passe : Protect ( [salt] + [password] )  La longeur du salt : 32 ou 64 caractéres  Algorithme de hash performant : HMAC-SHA-256([private key], [salt] + [password])  Utilisation d’une implémentation sécurisé des algorithmes de chiffrements : Google KeyCzar  Librairie open source sécurisé et simple à utiliser :  Robuste en terme de gestion des clés (rotation, versioning & lengths )  Implémentée en Java, Python et C++. OWASP – Password Storage Cheat Sheet2 Crypter crypter = new Crypter("/path/to/your/keys"); String ciphertext = crypter.encrypt("Secret message");
  10. 10. 10 5: Etablir les contrôles d’identité et d’authentification  Complexité des mots de passe : au minimum 8 caractères, une alternance de lettres majuscules, minuscules et chiffres.  Sécurisé le processus de recouvrement d’un mot de passe : Le processus recommandé par l’OWASP est constitué des étapes suivantes :  Etape 1) Demande d’informations sur l’identité de l’utilisateur (exemple email ou réponse à une question secret).  Etape 2) Vérification de l’identité de l’utilisateur.  Etape 3) Envoi d’un jeton d’accès temporaire à travers un moyen sécurisé (exemple email).  Etape 4) Enfin, l’application doit forcer l’utilisateur à changer son mot de passe suite à l’utilisation du jeton d’accès fourni précédemment (étape 3).  Protection de la session des utilisateurs : le transport, la création, le renouvellement et la destruction de la session d'un utilisateur dans l'application. L'authentification est le processus consistant à vérifier qu'une personne ou une entité est bien celui qu'elle prétend être. Dans le contexte des applications Web, on retrouve les mesures/recommandations suivantes :
  11. 11. 11 4: Implémenter les contrôles d’accès appropriés  Le contrôle d’accès est le mécanisme qui permet d’autoriser/interdire l’accès à une ressource/fonctionnalité au niveau de l’application.  Exemple de « Mauvaises Pratiques » ou « Anti-Patterns » de contrôle d’accès :  Codage en dur des règles d’accès au niveau du code source.  Absence d’un système centralise (couche de sécurité) pour le contrôle d’accès.  Une règle de contrôle d’accès qui nécessite la modification de plusieurs fichiers de code de source  Un système de contrôle d’accès ouvert par défaut.  Effectuer des décisions directement à partir des données non validées. if ( $_GET[user] === "tmr" ) { echo "Welcome Admin !" } if (user.isManager() || user.isAdministrator() || user.isEditor() || ... ) { //execute action }
  12. 12. 12 4: Implémenter les contrôles d’accès appropriés if (user.isManager() || user.isAdministrator() || user.isEditor() || user.isUser()) { //execute action } Problématique Solution Implémenter un mécanisme de contrôle d’accès sécurisé et centralisé. if ( currentUser.hasRole( "admin" ) ) { log.info(" Welcome Admin ! " ); } else { log.info( " You don’t have access " ); } Définir une politique d’accès au niveau du fichier de configuration « shiro.ini ».
  13. 13. 13 4: Implémenter les contrôles d’accès appropriés Problématique Solution L’application doit garantir l’accès uniquement pour un objet unique. int winnebagoId = request.getInt("winnebago_id"); if ( currentUser.isPermitted( "winnebago:drive:" + winnebagoId) ) { log.info("You are permitted to 'drive' the 'winnebago'. Here are the keys."); } else { log.info("Sorry, you aren't allowed to drive this winnebago!"); } Définir une politique d’accès au niveau du fichier de configuration « shiro.ini ».
  14. 14. 14 3: Valider toutes les données entrantes  Il est absolument essentiel de considérer toutes les données extérieures à l’application (données entrantes) comme non-fiables.  Pour les applications Web, cela inclut les entêtes HTTP, cookies et paramètres GET ou POST. En effet, tout ou partie de ces données peuvent être modifiées par un attaquant.  En pratique, comment réaliser l’opération?  Identifier toutes les entrées provenant des utilisateurs  Formaliser les familles d’entrées (type, longueur, etc..)  Classer les entrées en fonction de l’exposition des formulaires  Accès public  Accès client lambda  Accès administrateur  Mettre en œuvre les contrôles du côté serveur : les contrôles côté client permettent de simplifier la navigation et d’anticiper des erreurs de saisie n’apportent rien en terme de sécurité
  15. 15. 15 3: Valider toutes les données entrantes Exemples pratique : Utilisation des expressions régulières (méthode liste blanche) L'expression régulière suivante permet de valider le nom d'utilisateur : L'expression régulière suivante permet de valider le mot de passe : Utilisation de l'OWASP Java HTML Sanitizer : une librairie open source pour parser et nettoyer le code HTML. ^[a-z0-9_]{3,16}$ PolicyFactory policy = new HtmlPolicyBuilder() //Définir votre politique de filtrage .allowElements("a") .allowUrlProtocols("https") .allowAttributes("href").onElements("a") .requireRelNofollowOnLinks() .build(); String safeHTML = policy.sanitize(untrustedHTML); //Appliquer le filtre HTML ^(?=.*[a-z])(?=.*[A-Z])(?=.*d)(?=.*[@#$%]).{10,64}$
  16. 16. 16 2: Encoder les données <
  17. 17. 17 2: Encoder les données &lt;
  18. 18. 18 2: Encoder les données  L’encodage des données permet d’éviter les failles de types XSS en transformant des chaînes de caractères contenant du code malicieux (par exemple JavaScript) en chaîne purement littérales et non interprétables par le navigateur.  L’encodage permet de se protéger contre toutes la famille des attaques de type XSS :  Session Hijacking.  Site Defacement.  Redirection vers URLs/Pages de Phishing.  Chargement de script malveillant à partir d’un site distant  Vole de session  KeyStorke Logging  Il est recommandé d’utiliser les APIs fournis par l’OWASP  OWASP Java Encoder Project  OWASP Java HTML Sanitizer Project
  19. 19. 19 2: Encoder les données Problématique Solution Une page Java JSP est vulnérable au XSS 1) <input type="text" name="data" value="<%= Encode.forHtmlAttribute(datavalue) %>" /> 2) <textarea name="text"><%= Encode.forHtmlContent(textValue) %></textarea> 3) <button onclick=alert('<%= Encode.forJavaScriptAttribute(alertMsg) %>') Click me </button> 4) <script type="text/javascript"> var msg= "<%= Encode.forJavaScriptBlock(message) %>"; alert(msg); </script>
  20. 20. 20 1: Requêtes paramétrées  L’injection consiste à envoyer des données non prévues à une application afin de détourner le comportement attendu  L’injection d’un code SQL malicieux peut avoir des conséquences graves sur l’intégrité/confidentialité de la base de données.
  21. 21. 21 1: Requêtes paramétrées ‘ ;
  22. 22. 22 1: Requêtes paramétrées  L’Utilisation des requêtes paramétrées permet d’assurer une protection fiable contre les injections de code SQL  Exemple d’utilisation des requêtes paramétrées sous PHP  Exemple d’utilisation des requêtes paramétrées sous JAVA  Attention : mauvaise utilisation des requêtes paramétrées $email = $_REQUEST['email']; $id = $_REQUEST['id']; $stmt = $dbh->prepare("update users set email=:new_email where id=:user_id "); $stmt->bindParam(':new_email', $email); $stmt->bindParam(':user_id', $id); String newName = request.getParameter("newName"); String id = request.getParameter("id"); PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?"); pstmt.setString(1, newName); pstmt.setString(2, id); Statement stmt = conn.createStatement("INSERT INTO students VALUES('" + user + "')"); stmt.execute();
  23. 23. 23 Pour plus d’informations ... https://www.owasp.org/index.php/OWASP_Proactive_Controls

×