owasp top 10 proactive

23
1 TOP 10 CONTRÔLES PROACTIFS POUR LA SÉCURITÉ DES APPLICATIONS WEB B Y ABDESSAMAD TEMMAR (TMR) TEMMAR.ABDESSAMAD@GMAIL.COM

Upload: abdessamad-temmar

Post on 07-Aug-2015

88 views

Category:

Technology


5 download

TRANSCRIPT

Page 1: OWASP TOP 10 Proactive

1

TOP 10 CONTRÔLES PROACTIFS POUR LA SÉCURITÉ DES APPLICATIONS WEB

BY ABDESSAMAD TEMMAR (TMR)

[email protected]

Page 2: OWASP TOP 10 Proactive

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é

Page 3: OWASP TOP 10 Proactive

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.

Page 4: OWASP TOP 10 Proactive

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).

Page 5: OWASP TOP 10 Proactive

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

Page 6: OWASP TOP 10 Proactive

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

Page 7: OWASP TOP 10 Proactive

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

Page 8: OWASP TOP 10 Proactive

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 Sheet 1

Page 9: OWASP TOP 10 Proactive

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 Sheet 2

Crypter crypter = new Crypter("/path/to/your/keys"); String ciphertext = crypter.encrypt("Secret message");

Page 10: OWASP TOP 10 Proactive

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 :

Page 11: OWASP TOP 10 Proactive

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 }

Page 12: OWASP TOP 10 Proactive

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 ».

Page 13: OWASP TOP 10 Proactive

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 ».

Page 14: OWASP TOP 10 Proactive

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é

Page 15: OWASP TOP 10 Proactive

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}$

Page 16: OWASP TOP 10 Proactive

16

2: Encoder les données

<

Page 17: OWASP TOP 10 Proactive

17

2: Encoder les données

&lt;

Page 18: OWASP TOP 10 Proactive

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

Page 19: OWASP TOP 10 Proactive

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>

Page 20: OWASP TOP 10 Proactive

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.

Page 21: OWASP TOP 10 Proactive

21

1: Requêtes paramétrées

‘ ;

Page 22: OWASP TOP 10 Proactive

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();

Page 23: OWASP TOP 10 Proactive

23

Pour plus d’informations ...

https://www.owasp.org/index.php/OWASP_Proactive_Controls