Vulnérabilités

OWASP 2017 – A3 – A5 – A6

CHAPITRE 5
Par : Ali GHORBEL
Ali.ghorbel@esprit.tn

1
 Plan

A3:2017-Exposition de données sensibles

A5:2017-Violation de contrôle d'accès

A6:2017-Mauvaise configuration Sécurité

A3:2017-Exposition de données sensibles
Exposition de données sensibles
OWASP TOP 10 - 2017
Beaucoup d'applications web et d'APIs ne protègent pas
correctement les données sensibles telles que les
données bancaires, les données relatives aux soins de
santé, les données personnelles d'identification. Les
pirates peuvent alors voler ou modifier ces données mal
protégées pour effectuer une usurpation d'identité, une
fraude à la carte de crédit ou d'autres crimes. Les
données sensibles méritent une protection
supplémentaire tel un chiffrement statique ou en
transit, ainsi que des précautions particulières lors de
l'échange avec le navigateur.
 Exposition de données sensibles
L’exposition de données sensibles concerne surtout les attaques
cryptographiques, voire le manque de chiffrement sur les réseaux et données
stockées. Comme vu dans le chapitre précédent (cf. Panorama de la sécurité web -
La sécurité des navigateurs et serveurs web), les attaques du type homme du
milieu (MITM) sont assez simples à mettre en place et efficaces si l’application
n’utilise pas de chiffrement SSL/TLS avec un HSTS (Strict Transport Security) bien
configuré. La confusion entre les protocoles de chiffrement, le hachage et
l’encodage peut créer des brèches, par exemple l’utilisation de fonctions base64
pour traiter des données sensibles au lieu d’un chiffrement.
 Exposition de données sensibles
Scénarios:
Utilisation de protocoles de transport de données sécurisées faibles (SSLv2)
Confusion entre encodage et chiffrement, par exemple, des mots de passe
encodés en base64 dans la base de donnes
Aucun salage mis en place pour les mots de passe
Algorithme de hachage dépassé (MD5, SHA1-0)
Utilisation de faibles clés de chiffrement
Pas de désactivation de l’attribut autocomplete dans les formulaires collectant
des données sensibles
Stockage sur le serveur web de données sensibles avec rapport avec
l’application.
Utilisation de données sensibles de l’utilisateur dans les stockages localStorage,
SessionStorage et indexDB HTML5
Utilisation de caches dans les en-têtes HTTP pour le transfert de données
sensibles
 Exposition de données sensibles
Comment s'en prémunir ?
On veillera au minimum à suivre les recommandations suivantes, mais il reste
nécessaire de consulter les références.
Classifier les données traitées, stockées ou transmises par l'application.
Identifier quelles données sont sensibles selon les lois concernant la protection
de la vie privée, les exigeances réglementaires, ou les besoins métier.
Appliquer des contrôles selon la classification.
Ne pas stocker de données sensibles sans que cela ne soit nécessaire. Les
rejeter ou utiliser une tokenisation conforme à la norme de sécurité de
l’industrie des cartes de paiement (PCI DSS) ou même une troncature. Les
données que l’on ne possède pas ne peuvent être volées !
S'assurer de chiffrer toutes les données sensibles au repos.
Choisir des algorithmes éprouvés et générer des clés robustes. S'assurer
qu'une gestion des clés est en place.
 Exposition de données sensibles
Comment s'en prémunir ?
Chiffrer toutes les données transmises avec des protocoles sécurisés tels que
TLS avec des chiffres à confidentialité persistante (perfect forward secrecy -
PFS). Chiffrer en priorité sur le serveur. Utiliser des paramètres sécurisés. Forcer
le chiffrement en utilisant des directives comme HTTP Strict Transport Security
(HSTS).
Désactiver le cache pour les réponses contenant des données sensibles.
Stocker les mots de passe au moyen de puissantes fonctions de hachage
adaptatives, avec sel et facteur de travail (ou facteur de retard),
comme Argon2, scrypt, bcrypt ou PBKDF2.
Vérifier indépendamment l'efficacité de la configuration et des paramètres.
 Exposition de données sensibles
Comment s'en prémunir ?
Pour aller plus loin dans les contrôles de sécurité des données sensibles :
Recommandations ASVS :
https://www.owasp.org/index.php/ASVS, chapitre 7,9,10.

Owasp Cryptographic Storage Cheat Sheet :

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

MITRE CWE Weak encryption :

http://cwe.mitre.org/data/definitions/326.html
A5:2017-Violation de contrôle d'accès
 Violation de contrôle d'accès
OWASP TOP 10 - 2017

Les restrictions sur les droits des utilisateurs authentifiés

sont souvent mal appliquées. Les attaquants peuvent
exploiter ces failles pour accéder à des fonctionnalités
et/ou des données non autorisées. Par exemple, accéder
aux comptes d'autres utilisateurs, visualiser des fichiers
sensibles, modifier les données d'autres utilisateurs,
modifier les droits d'accès, etc.
 Violation de contrôle d'accès
Le manque de lié contrôle d’accès est un risque à des vulnérabilités
retrouvées dans la gestion des droits d’une application, des défauts de
conception ou l’utilisation de fonctions appropriées à l’intérieur du code.
L’attaquant peut alors accéder à des fonctionnalités non autorisées, voire
compromettre le site, avec des attaques du type déni de service (DoS,
DDoS).
Voici l’évaluation du risque selon l’OWASP :
 Violation de contrôle d'accès
Vecteurs d’attaque: l'exploitation des contrôles d'accès est une des principales
compétences des attaquants. Les outils SAST et DAST peuvent détecter l'absence
de contrôles d'accès, mais ne peuvent vérifier s'ils sont efficaces quand ils
existent. Les vulnérabilités de contrôles d'accès peuvent être détectés par des
tests manuels, leur absence peut être détectée par des contrôles automatiques
dans certains frameworks.
SAST https://owasp.org/www-community/Source_Code_Analysis_Tools
https://www.defensecode.com/thunderscan-sast/

DAST https://owasp.org/www-community/Vulnerability_Scanning_Tools
 Violation de contrôle d'accès
A4:2013–Références directes non sécurisées à un objet
et
A7:2013–Manque de contrôle d’accès au niveau fonctionnel
ont été fusionnés dans
A5:2017-Violation de Contrôles d'Accès.
 Violation de contrôle d'accès
A- Références directes non sécurisées à un objet (IDOR)
Les références directes non sécurisées à un objet sont des vulnérabilités
s’attaquant à la mauvaise gestion des droits et d’identification dans une
application.
Chaque site web contenant des données dynamiques comme un back-office
pour l’administration en arrière-plan d’une application, doit être pourvu de
rôles d’utilisateurs, d’administrateurs ou de modérateurs suivant les
besoins de l’application.
Si une référence à un objet n’est pas contrôlée à chaque instanciation de
celui-ci, un cybercriminel pourrait donc obtenir et modifier des informations
auxquelles il ne devrait pas avoir accès.
 Violation de contrôle d'accès
A- Références directes non sécurisées à un objet (IDOR):
Types:
Il existe plusieurs types d'attaques IDOR, notamment:
Manipulation du corps, dans lequel les attaquants modifient la valeur d'une
case à cocher, des boutons radio, des API et des champs de formulaire pour
accéder facilement aux informations d'autres utilisateurs.
Falsification d'URL, dans lequel l'URL est modifiée à la fin du client en
ajustant les paramètres dans la requête HTTP.
Requêtes HTTP dans lequel les vulnérabilités IDOR se trouvent généralement
dans les verbes GET, POST, PUT et DELETE.
Affectation en masse, où un modèle d'enregistrement peut être utilisé de
manière abusive pour modifier des données auxquelles l'utilisateur ne devrait
pas pouvoir accéder. Bien que ce ne soit pas toujours le résultat de
vulnérabilités d'IDOR, il existe de nombreux exemples puissants de cette
situation.
 Violation de contrôle d'accès
A- Références directes non sécurisées à un objet (IDOR):
Exemple:
Une vulnérabilité du type Références directes non sécurisées a été découverte sur
YouTube par un chercheur en sécurité russe nommé Kamil Hismatullin en 2015. Celui-ci
pouvait détruire n’importe quelle vidéo en modifiant l’identifiant de la vidéo lors de la
demande de suppression sur sa page YouTube.

Même si l’identifiant de la vidéo ne lui appartenait pas, la vidéo était supprimée car la
vérification de l’utilisateur n’était pas faite.
 Violation de contrôle d'accès
A- Références directes non sécurisées à un objet (IDOR):
Démo bWAPP : entrées directes cachées et non contrôlées
 Violation de contrôle d'accès
A- Références directes non sécurisées à un objet (IDOR):
Démo bWAPP : entrées indirectes cachées et non contrôlées
 Violation de contrôle d'accès
A- Références directes non sécurisées à un objet (IDOR):
Démo bWAPP : entrées indirectes cachées et non contrôlées
<script type="text/javascript">
function ResetSecret()
{
var xmlHttp;
// Code for IE7+, Firefox, Chrome, Opera, Safari
if(window.XMLHttpRequest)
{
xmlHttp = new XMLHttpRequest();
}
// Code for IE6, IE5
else
{
xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
}
xmlHttp.open("POST","xxe-2.php",true);
xmlHttp.setRequestHeader("Content-type","text/xml; charset=UTF-8");
xmlHttp.send("<reset><login>bee</login><secret>Any bugs?</secret>
</reset>");
}
</script>
 Violation de contrôle d'accès
A- Références directes non sécurisées à un objet (IDOR):
Comment s’en prémunir?
N° Méthode Description
1 Contrôle des Afin de se protéger contre ce genre d’attaque, il est nécessaire
références de mettre des contrôles stricts sur les références utilisateurs,
l’utilisateur. Une pattern permettant de vérifier si l’utilisateur est
bien le propriétaire de l’objet peut s’avérer très utile.

2 champs Protéger les références avec la technique 1 présentée sur la

cachés colonne ci-dessus pour les champs cachés. Même ceux non
affichés dans le DOM. Les techniques Data biding ou Mass
assignment vulnerability ont la fonction d’envoyer des requêtes
avec des paramètres aléatoires essayant de trouver des
champs cachés et compromettre l’application.
3 Framework Les framework actuels bien utilisés comportent une gestion des
rôles sur les applications efficaces. Encore une fois ne pas
hésiter à se servir de ce type d’outil pour développer.
 Violation de contrôle d'accès
B- LFI/RFI

http://localhost/bWAPP/rlfi.php?language=lang_en.php&action=go

http://localhost/bWAPP/rlfi.php?language=../../../../../etc/passwd&action=go
 Violation de contrôle d'accès
B- LFI/RFI
http://localhost/bWAPP/rlfi.php?language=lang_en.php&action=go

http://localhost/bWAPP/rlfi.php?language=../../../../../etc/passwd&action=go
 Violation de contrôle d'accès
B- LFI/RFI
Comment s’en prémunir?
N° Méthode Description
1 Entrées Valider les entrées utilisateur et ne pas utiliser celles-ci
utilisateur dans des fonctions d’inclusion

2 Désactiver Désactiver les directives permet l’utilisation d’inclusion

des d’URL
directives Exemple en PHP:
allow_url_open,
allow_url_include.
 Violation de contrôle d'accès
C- Host Header Attack
Dans certains cas, une application peut faire confiance aux valeurs contenues
dans une en-tête HTTP pour utiliser celles-ci à l’intérieur du code afin de
générer des liens, réinitialiser des mots de passe, etc
Le problème, c’est qu’un attaquant peut exploiter les en-têtes HTTP afin
d’usurper ou modifier les valeurs utilisées par la suite dans le code.
C’est le cas du Web cache poisoning, qui a pour effet d’envoyer une requête
HTTP forgée, altérée, au serveur afin de s’emparer de celui-ci et de modifier le
comportement de l’application
Dans l’exemple suivant, le cybercriminel envoie une requête forgée en
modifiant la valeur du paramètre Host par son domaine pirate, ce qui permet
d’intéragir avec le code de l’application dans la variable
$_SERVER[‘HTTP_HOST’]
 Violation de contrôle d'accès
C- Host Header Attack

GET /login.html HTTP/1.1

1 User-Agent: Mozilla
Host: hack.com#

<a href=« <?=$_SERVER[‘HTTP_HOST’]?>/">authentification</a>

<body>
<a href="http://hack.com#"/>accueil</a>
<a href="http://hack.com#/about">contact</a>
<a href="http://hack.com#/login">authentification</a>
</body>
 Violation de contrôle d'accès
C- Host Header Attack
Comment s’en prémunir?

N° Méthode Description

1 Bannir Il est péférable d’utiliser les variables du type

HTTP-HOST SERVER_NAME à HTTP-HOST car celui-ci utilise sa
propre configuration de domaine et non pas celle
proposée par l’utilisateur
 Violation de contrôle d'accès
D- User-agent spoofing:
Permet de modifier, forger une requête HTTP afin de passer outre les règles de
redirection ou même utiliser des vulnérabilités XSS.
Un user-agent est l’identité du navigateur, envoyée à chaque requête HTTP
lors d’une navigation sur un serveur web.
Cela permet de rediriger l’utilisateur vers un site mobile par exemple si celui-ci
est un mobinaute.
Les user-agents sont propres au navigateur, il est donc très simple de spoofer,
d’usurper, cette identité à l’aide d’extensions, plugins ou logiciels comme Burp
Suite
 Violation de contrôle d'accès
E- Server Side Request Forgery (SSRF) :
Ce sont des vulnérabilités Web permettant de lire des fichiers sur le
serveur local.
Il ne faut pas les confondre avec les CSRF (Cross Site Request Forgery), qui,
elles, ont pour but l'exécution d'une requête à l'insu d'un autre utilisateur.
Un des gros avantages des SSRF est la possibilité de contourner les pare-feux.
En effet, les actions se faisant côté serveur, il est possible d'interroger des
services n'étant disponibles que localement tels que :
Des bases de données NoSQL : Redis, MongoDB.
Des bases de données relationnelles : Oracle, MSSQL, MySQL, PostgreSQL.
Des services mail : Postfix, Dovecot.
Des services Web accessibles localement.
Ce genre de faille est particulièrement présent sur les proxy Web : Un
utilisateur du service proxy peut avoir accès à des données internes au serveur,
données auxquelles il n'aurait normalement pas du avoir accès.
 Violation de contrôle d'accès
E- Server Side Request Forgery (SSRF) :
 Violation de contrôle d'accès
E- Server Side Request Forgery (SSRF) :
Comment s’en prémunir?

N° Méthode Description

1 Retour Contrôler au maximum les retours d’erreurs (try and

d’erreurs catch).

2 Désactiver les A l’aide d’une Whitelist, autoriser les protocoles

protocoles non nécessaires (HTTP, HTTPS) et interdire implicitement
nécessaires les protocoles non nécessaires. Ceci peut se faire sur
le serveur WEB ou bien le code lui-même.
A6:2017-Mauvaise configuration Sécurité
 Mauvaise configuration Sécurité
OWASP TOP 10 - 2017

La mauvaise configuration de la sécurité est le problème

le plus répandu. C'est généralement le résultat de
configurations par défaut non sécurisées, de
configurations incomplètes ou ad hoc, d'un stockage
dans un cloud ouvert, d'en-têtes HTTP mal configurés et
de messages d'erreur verbeux contenant des
informations sensibles. Non seulement tous les
systèmes d'exploitation, frameworks, bibliothèques et
applications doivent être configurés de façon sécurisées,
mais ils doivent également être corrigés et mis à jour en
temps et en heure.
 Mauvaise configuration Sécurité
La mauvaise configuration des éléments de sécurité arrive en cinquième position
du classement OWASP TOP 10. Le périmètre d’une mauvaise configuration de
sécurité peut dépasser le périmètre d’une application. La mise à jour des serveurs
web, des librairies, des comptes administrateur inactifs, l’affichage des messages
d’erreurs... sont des vulnérabilités associées à ce risque. Le principe des moindres
privilèges, la sécurité par défaut, la défense en profondeur et la réduction des
surfaces d’attaque aident à se protéger de ces risques et seront étudiés dans le
prochain chapitre en détail.
 Mauvaise configuration Sécurité
Scénarios possibles:
Le cybercriminel provoque une erreur sur l’application, ce qui lui permet d’obtenir
des informations importantes pour corrompre l’application.
Le serveur hébergeant l’application a des utilisateurs et mots de passe par
défaut sur les services SQL, SSH, FTP, Apache, IIS, etc.
Une application faite avec un framework est "poussée" en production mais la partie
préproduction avec des identifiants par défaut est aussi en production.
Le serveur WEB liste les répertoires de type index of et permet à un attaquant de
télécharger des fichiers et obtenir des informations.
Il manque des mises à jour de sécurité sur les serveurs WEB et de stockage de
données.
Le serveur WEB autorise les requêtes HTTP de type TRACE ce qui permet à
l’attaquant d’exploiter une vulnérabilités XST (Cross Site Tracing).
Le serveur de base de données utilise le même utilisateur pour toutes les bases de
données ce qui permet à un attaquant lors d’une injection de pivoter entre les bases.
Mauvaise configuration du fichier Robots.txt permettant de récupérer des
informations sur l'architecture de l’application.
 Mauvaise configuration Sécurité
Se protéger :

Utiliser les techniques de durcissement (hardening)

Recommandations ASVS :
https://www.owasp.org/index.php/ASVS,

Cheat sheet OWASP sur la configuration sécurisée

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

Hardening pour serveur Apache :

https://geekflare.com/apache-web-server-hardening-security/