OWASP TOP 10 Proactive

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

17
2: Encoder les données
<

18
 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
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
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
‘ ;

22
 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
Pour plus d’informations ...
https://www.owasp.org/index.php/OWASP_Proactive_Controls

OWASP TOP 10 Proactive

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à OWASP TOP 10 Proactive

Similaire à OWASP TOP 10 Proactive (20)

OWASP TOP 10 Proactive