Exploitation externe - aka Web

Exploitation externe - aka Web#

XSS#

Késako: Injection de code HTML et/ou JavaScript malveillant dans une page web

Ce que l’on vise avec ce genre d’attaque:

  • Vol de cookies / session

  • Usurpation d’identité

  • Actions à la place de l’utilisateur

Comment trouver une XSS:

  • Tester toutes les entrées, en particulier celles reprises dans la réponse

  • Injecter des caractères spéciaux (et leurs versions encodées) et vérifier s’ils sont repris / sous quel format

    • <script>alert("hello")</script>

    • %3Cscript%3Ealert%28%22hello%22%29%3C%2Fscript%3E

  • Tenter d’injecter “dans le flot” de la page (en javascript si dans du code javascript, dans une balise, etc.)

    • Exemple: si le code source est <img src="*notre input*">, essayez d’injecter truc" href="http://mechant.com/" pour former <img src="truc" href="http://mechant.com/">

Ce qui pourrait vous bloquer et comment remédier à ces attaques:

  • Valider les entrées côté serveur : contrôler les entiers, les caractères autorisés dans une chaîne, etc.

  • Échapper les données utilisateur : < deviennent &lt;

  • Mettre en place une Content Security Policy (CSP)

    • Cependant il existe des bypass !

  • Éviter les fonctions dangereuses : innerHTML, eval(), document.write()

Injection SQL aka “SQLi”#

3 types principaux :

  • In-band SQLi (extraction directe des données)

    • SELECT * FROM users;

  • Blind SQLi (pas de retour direct, inférence via comportements)

  • Time-based SQLi (utilisation de délais pour extraire l’info)

    • SLEEP(10)

  • Error-based SQLi (utilisation des erreurs pour extraire l’info)

Retrouvez une liste complète d’exemples d’injections SQL à sur Payload All the Things

Ce que l’on vise avec ce genre d’attaque:

  • Vol de données

  • Possibilité de rebond sur le serveur si les droits du compte sont trop élevés

Comment trouver une SQLi:

  • Tester toutes les entrées et en particulier ceux qui peuvent être utilisées dans une requête

    • des requêtes à des /get-users?id=truc, /api/add_to_cart?item=truc, /profile?user=truc, etc

  • Comprendre comment pourrait être utilisée l’entrée : int, char, etc.

  • Chercher des erreurs, des comportements identiques malgré l’injection de code, etc.

  • Tenter d’injecter du code en respectant le format de la requête suspectée

Comment palier à ces attaques:

  • Utiliser des requêtes paramétrées (prepared statements)

  • Validation stricte des entrées utilisateur

  • Éviter la concaténation de chaînes SQL

  • Utiliser des droits minimaux sur la base de données (least privilege)

  • Masquer les erreurs SQL

Local File Inclusion, aka LFI#

Vulnérabilité permettant d’inclure des fichiers locaux du serveur.

Elle apparaît quand une application utilise une entrée utilisateur pour charger un fichier sans contrôle.

Ce que l’on vise :

  • Lecture des fichiers sensibles sur le serveur

  • Accès au code source

Comment trouver une LFI:

  • Identifier toutes les entrées laissant penser à l’utilisation directe de fichiers : file=, page=, view=, include=

  • Tenter d’utiliser des caractères spéciaux utilisés dans les arboresences : ./, ../, etc.

  • Essayer de parcourir l’arborescence vers des fichiers standards : /.git/.gitignore, /etc/passwd, .env, etc.

Correction / Remédiation - Ne jamais inclure directement une entrée utilisateur dans un chemin de fichier - Mapper les choix utilisateur à des fichiers internes : ex : 1 → home.php, 2 → about.php - Désactiver les wrappers dangereux (PHP) : allow_url_include = Off - Normaliser et valider les chemins (realpath) et les noms des fichiers (basename)

Insecure Direct Object Reference, aka IDOR#

L’application expose des références à des objets (ID) manipulables par l’utilisateur et aucun contrôle ne vérifie si l’utilisateur à le droit d’accès à cet objet.

Exemple: Un utilisateur A ayant accès à l’objet id=123, qui aurait aussi accès à l’objet 122, 124, etc.

Ce que l’on vise avec une IDOR:

  • Fuite de données

  • Modification/Suppression des données d’autres personnes

Comment trouver une IDOR:

  • Identifier les références vers les objets dans les entrées

  • Tester la modification des ces IDs :

    • Incrémenter / décrémenter

    • Changer vers ceux d’un autre utilisateur

  • Contrôler la propriété des objets

Ce qui pourrait nous bloquer:

  • Utilisation des identifiants non prédictibles (UUID, exemple: 67ac387b-d211-4527-9ce5-c50172704c4b)

  • Contrôle d’accès centralisé (RBAC / ABAC)

Server-Side Request Forgery, aka SSRF#

Vulnérabilité où le serveur est forcé de faire des requêtes (souvent HTTP) par l’attaquant.

Ce que l’on vise avec une SSRF:

  • Accès à des services internes non exposés

  • Vol de données techniques senisbles

Comment trouver une SSRF:

  • Chercher des URL que l’on contrôle ou une ressource appelée par le serveur qui est manipulable dans une entrée

  • Identifier les fonctions et les entrées permettant de récupérer des ressources distantes (internes ou externes)

  • Tester des IP internes : 127.0.0.1, 10.0.0.0/8, 169.254.169.254, etc. (autres bypass possible ::1)

Bypass Auth / JWT#

Ensemble de vulnérabilités liées à une authentification mal conçue ou insuffisante.

Problèmes fréquents :

  • Absence de vérification de la session (cookie) / moyen d’authentification (jwt) sur les pages / fonctions

  • Sessions / moyens d’authentification forgeables ou prévisibles

  • Sessions / moyens d’authentification non protégés ou réutilisables

Ce que l’on vise :

  • Usurpation de comptes

  • Elévations des privilèges

Comment trouver un bypass:

  • Trouver les éléments permettant de maintenir l’authentification

  • Vérifier les accès aux pages / fonctions sans les moyens d’authentification / session

  • Observer les requêtes entre 2 authentifications / 2 utilisateurs

  • Contrôler les éléments : prédictibilités, signature vérifiée, clé non triviale

Ne pas oublier qu’un JWT est juste des données au format base64url accompagné d’une signature.

XXE#

Hell nah.

Server Side Template Injection, aka SSTI#

Injection dans un moteur de template de rendu côté serveur

Ce que l’on vise:

  • Fuite d’informations

  • RCE dans certains moteurs

Comment trouver une SSTI:

  • Tester toutes les entrées avec des balises correspondants à leur moteur: {{7*7}} / ${7*7} / <%= 7*7 %> - Observer si le contenu est évalué - Identifier le moteur de template utilisé - Tester accès à objets système via templates

Correction / Remédiation:

  • Ne jamais injecter directement des variables utilisateur dans les templates

  • Utiliser les modes « safe rendering »

  • Désactiver les fonctions dangereuses du moteur

  • Séparer données et logique (no code execution in templates)

File Upload#

Téléversement de fichiers sans validation suffisante

Ce que l’on vise:

  • Envoi de fichiers dangereux : - Scripts (PHP, JSP, ASP, etc.) - EXE, BAT, etc. - Fichiers mal nommés écrasant le nom d’un autre fichier

  • XSS stockés

  • RCE si possibilité de faire exécuter le fichier par le serveur

  • stockage de malware / fichiers illicites / etc.

Ce qui pourrait vous bloquer:

  • Validation stricte côté serveur : type MIME + extension + contenu réel

  • Renommage des fichiers côté serveur

  • Stockage des uploads hors web root

  • Limite de taille et de type

Comment arriver à ses fins:

  • Extensions interdites contournées (.php.jpg)

  • Modification MIME type

  • Payloads dans metadata

  • Path Traversal dans le nom du fichier ../

Remote Code Execution#

Vulnérabilité permettant d’exécuter des commandes sur le serveur distant.

Peut provenir de multiples sources :

  • Failles présentées ci-dessus

  • Désérialisation

  • Utilisation d’entrée utilisateur dans un lancement de programme non sécurisé

Impact :

  • Accès à des fichiers sensibles

  • Compromission du serveur

  • Rebond sur le réseau interne

Comment trouver une possible RCE via lancement d’un programme non sécurisé:

  • Identifier les entrées qui pourraient être utilisées dans un programme, commande système, etc.

  • Tester les caractères spéciaux utilisées pour séparer les commandes : &, |, etc.

  • Vérifier les erreurs, les temps d’attente, les retours