==============================
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
<https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection>`_

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




.. toctree::
   :maxdepth: 2
   :caption: Contents:

   docs/recon
   docs/exploitation_externe
   docs/exploitation_interne
   docs/virtualisation_docker_kube