22'
Préparation aux audits de sécurité
10 Décembre 2021
29 Novembre 2024
Johan Brun BRUN
Connaissez-vous quelques vulnérabilités web ?
❓
Les vulnérabilités
Liées aux CWEs (mitre)
(B : Base, C : Classe, V : Variant, ? : Composite)
Exemple avec XSS
Quelques exemples de vulnérabilités web
CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
<script>document.alert('Hacked');</script>
CWE-639: Authorization Bypass Through User-Controlled Key
(Aussi assimilée à IDOR)
GET /edit/<id-user>
CWE-352: Cross-Site Request Forgery (CSRF) (Composite)
redirection + cookie + /delete/2
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
/users/cwe/profiles/../../../etc/passwd
Dans chaque cas, plusieurs niveaux de complexité
(attr html ; insecure api ; formulaire)
C'est quoi donc la sécurité des apps ?
❓
L'AppSec
C'est quoi chef ?
↗️ Ensemble de pratiques œuvrant à la sécurité des applications
🔩 Process qui s'appliquent tout au long du cycle de vie :
* Fonctionnel : Abusers stories / Threat modeling
* Architecture : Review / Threat modeling
* Dév : Reviews, Checklists, SAST, SADT, Dépendances, Skills & Connaissance... ✨
* Tests : Test d'intrusion, Vérifications process,
* Release : Configuration sécurisée, Réponse à incident, Composants à jour
L'AppSec
Buts
🎯 Identifier, corriger et prévenir toute vulnérabilité
💾 La donnée est au cœur de la bataille. Elle doit s'accompagner de la triade CIA :
"Confidentiality, Integrity, Availability"
💻 DevSec : ne pas introduire de vulnérabilités
(tech / business logic)
Comment se passe un test d'intrusion ? (ou pentest)
❓
Phase 1 : Définition du besoin
🔢 Pourquoi un audit ?
🎫 Ce qui est critique (vol de PI / IP, rupture de service etc..)
👷♀️ Architecture globale
Le but est d'orienter le pentest vers ce qui est le plus important à protéger
Phase 2 : Proposition
🔢 Boite blanche / grise / noire
🎫 2-5 jours
👷♀️ Scan de vuln vs pentest
L'auditeur propose une solution sur mesure basée sur les besoins (CIA)
Phase 3 : Hack, eat & repeat
🔢 Structure de la BD (routes, introspection
🎫 Routes API / paramètres (oh, un :id)
👷♀️ Stack technique
Phase 3.1 Reconnaissance
🔢 Champ utilisateurs ? (on va mettre n'importe quoi)
🎫 Gestion de droits ? (ownership / rôles)
👷♀️ Configuration ? (JWT, entêtes...)
Phase 3 : Hack, eat & repeat
Phase 3.2 On appuie partout
👷♀️ Versions des composants
🔢 Selon comment le système réagit...
🎫 ... on va en déduire des vulnérabilités...
👷♀️ ... qui seront classés par criticité
Phase 3 : Hack, eat & repeat
Phase 3.3 Exploitation
Outils : proxy web, fuzzer, scan de vulns
Phase 4 : Restitution & contre-audit
Mesure de la criticité
🐛
Matrice des risques
Score de Criticité (CVSS)
L'OWASP ?
Open Web Application Security Project
👪 Communauté en ligne libre et ouverte oeuvrant pour la sécurité des applications web.
🧰 Propose des outils et solutions pour aider à la sécurisation :
* Web Security Testing Guide
* Juice Shop
* Zed Attack Proxy
* Top10 des vulnérabilités web
Et bien d'autres...
Top10 ?
📘Listing des différentes catégories de vulnérabilités web les plus communes
🕑Mis à jour tous les ~4 ans
🧠Vous n'allez pas tout retenir, mais ce n'est pas grave.
A10:2021-Server-Side Request Forgery
Résumé
- Survient quand le serveur interroge une ressource par une URL utilisateur non validée (réseau local par exemple)
Exception : Introduite par le Top10 Community Survey
Comment s'en protéger ?
- Défense en profondeur :
- (1) Segmentation du réseau ;
- (2) Validation des inputs ; Liste blanche ; Désactiver redirections
Exemple de scénario
- Injection d'url comme "file:///etc/passwd" ou domaine local (Sensitive Data Exposure / DDOS)
- Anecdote - Accès au panel d'AWS
A09:2021 – Security Logging and Monitoring Failures
Résumé
- Pas de détection lors d'une attaque (énumération)
- Pas assez de logs pour constater l'ampleur des dégâts, ni les moyens utilisés
Comment s'en protéger ?
- Logs : logins, erreurs de validation, altération / suppression de données
- Logs dans un format exploitable
- Rate limiter
- Détection d'activités suspicieuses
Exemple de scénario
- Brèches non colmatés : accés aux données durant des années
A08:2021 – Software and Data Integrity Failures
Résumé
- S'appuyer sur des sources non fiables
- Pas de vérification d'intégrité
Comment s'en protéger ?
- Signatures numériques
- S'assurer de la fiabilité des sources / mainteneurs
Exemple de scénario
- Une mise à jour vérolé contenant l'installation d'un malware (cf Supply-chain attacks)
A07:2021 – Identification and Authentication Failures
Résumé
- Pas de défense contre bruteforce ; Pass par défaut / non protégés
- Pas de 2FA, identifiant de session dans l'url, pas d'invalidation de session..
Comment s'en protéger ?
- Rate-limiter sur les routes de connexion / inscription
- Hasher, saler, les pass utilisateurs / pas de défaut
- Ne pas coder soi même mais utiliser des outils éprouvés (passport)
- Utiliser les cookies avec HttpOnly, Secure
- Session token (ou JWT...) sûrs + Vérification + refus par défaut
Exemple de scénario
- Accès à un compte admin à partir
d'une seclist
A06:2021 – Vulnerable and Outdated Component
Résumé
- Une seule CWE mais très critique
- Utiliser des composants non à jour, qui peuent être exploités par un exploit
Comment s'en protéger ?
- Et bien... Mettre à jour ses composants
Exemple de scénario
- Utilisation d'un exploit sur un composant outdated pour exécuter du code arbitraire sur le serveur
Top2 du Top10 Community Survey
A05:2021 – Security Misconfiguration
Résumé
- Mauvaise gestion des permissions (cloud), ports / services / comptes non désactivés, messages d'erreurs trop parlants, password par défaut, features sec pas configurées
A04:2021 – Insecure Design
Résumé
- Ne pas assez intégrer la sécurité dans les process
Comment s'en protéger ?
- SSDLC
A03:2021 – Injection
Résumé
- Injection de code, commande etc... dans une page web / serveur / BD ...
Comment s'en protéger ?
- "Sanitize" les entrées utilisateurs
A02:2021 – Cryptographic Failures
Résumé
- Pass dans le code, pas de https ou de HSTS, faible hashage, pas de vérification du certificat...
- Possibilité d'avoir le réseau en clair avec MITM (SSL Stripping)
Comment s'en protéger ?
- Chiffrer les données sensibles et communications (HTTPS + HSTS)
- Désactiver le cache pour données sensibles
- Secure cookies
- Hash faible, clés par défaut ou trop faibles
- SSL Stripping
A01:2021 – Broken Access Control
Résumé
- Tous les pbs relatifs à l'autorisation d'accès à une ressource (modif id dans url, modification token d'auth, connexion à la place de
- Mauvaise config CORS, accès à une page non sécurisée
Comment s'en protéger ?
- Rate-limiter pour limiter le bruteforce
- CORS, check auth + autorisation (idor)
- Serveur : désactiver listing des dossiers
- JWT : faible durée de vie OU révokation
- Attention aux queries / mutation
- => Anecdote
- => Anecdote
Procédure de test
🐛
Contrôle d'accès
- Ownership des données
- Droits sur les rôles
- Informations renvoyées
- Configuration CORS (si cookies)
- Configuration JWT
- Invalidation à la déconnexion
Chiffrement
- HTTPS partout + Entête HSTS
- TLS v1.2
- bcrypt
- Algo à forte entropie pour les tokens
Injections
- Fuzzing sur les inputs (=> Validation des données en entrée)
- Recherche de vuln selon le context (XSS, SQLi, SSTI, CRLRi, file upload...)
Mauvaises configurations de sécurité
- Entêtes HTTPs
- Configuration != par défaut (permissions)
- cf doc
- pas de séparation staging / prod
- envoi des sources map
- messages d'erreur verbeux
- configuration oauth
- limitateur de débit
Composants pas à jour
- Revue des versions logicielles et leurs CVEs
- npm audit
Problèmes liés à l'auth
- Bruteforce
- Credentials par défaut
- identifiants / tokens dans l'url (!logs)
- invalidation session
- politique mdp faible
SSRF
- Valider les appels HTTP effectués par le serveur (! si insertion input)
Bisous
22' : OWASP Top10
By lonestone
