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

=> Souvent les tests sont basés sur l'OWASP

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

Calculette en ligne

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

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
       

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