Impara · Laboratorio web

Laboratorio Attacchi Web

Catalogo

Scegli cosa studiare oggi

Console — SQL Injection (simulata)

Prova con admin oppure incolla admin' OR '1'='1 nel campo utente. Il log descrive cosa farebbe il server vulnerabile.

Nome utente (input utente)

Password

[PRONTO] Ambiente didattico — nessun database reale coinvolto

[INFO] Premi il pulsante per vedere le 4 fasi illuminate sopra

Impatto tipico: critico

Percorso didattico

Fase 1 — Cosa fa l'applicazione

Il form di login invia nome e password al backend. Il backend costruisce una stringa SQL e la manda al database per chiedere: «esiste questa coppia?».

Fase 2 — Dove nasce il bug

Il programmatore concatena direttamente il testo del form nella query. Il database non distingue «comandi SQL» da «dati» — legge tutto come un unico messaggio.

"SELECT * FROM users WHERE user='" + input + "' AND pass='" + password + "'"

Fase 3 — Cosa fa l'input malevolo (in teoria)

Chiudendo la stringa con un apice e aggiungendo OR '1'='1, la condizione diventa sempre vera: il login può riuscire senza conoscere la password reale.

admin' OR '1'='1' --

Fase 4 — Cosa fa il difensore

Prepared statements: il DB tratta l'input solo come dato, mai come comando.
Account DB con permessi minimi (no DROP, no file read).
Validazione lunghezza e caratteri; messaggi d'errore generici.
Audit log sulle query anomale e WAF come strato aggiuntivo.

Console — XSS (simulata)

Inserisci un commento normale o prova <script>alert(1)</script>. Nessuno script viene eseguito sul tuo PC: solo il flusso viene narrato.

Commento pubblicato

Nickname

[PRONTO] XSS spiegato come catena browser → server

Impatto tipico: alto

Percorso didattico

Fase 1 — Superficie di attacco

Ogni campo che finisce nell'HTML visto da altri utenti: commenti, bio, parametri in URL riflessi nella pagina.

Fase 2 — Errore

Il server salva il testo e lo reinserisce nel DOM come HTML «vivo», non come testo escapato.

element.innerHTML = commentoSalvato; // pericoloso

Fase 3 — Effetto sulla vittima

Il browser della vittima interpreta tag ed eventi: furto cookie di sessione, redirect, clickjacking leggero.

Fase 4 — Difesa

Output encoding (trattare < come testo, non come tag).
Content-Security-Policy per bloccare script inline non autorizzati.
Cookie di sessione con flag HttpOnly e SameSite.

Console — Brute Force (simulata)

La wordlist sotto è solo didattica. La simulazione mostra tentativi e risposte HTTP fittizie, non invia richieste a login reali.

Username target (fittizio)

Wordlist (una password per riga)

[PRONTO] Ciclo tentativo/risposta simulato in locale

Impatto tipico: alto

Percorso didattico

Fase 1 — Cosa prova l'attaccante

Automatizza POST al form di login con liste di password comuni (rockyou, leak passate, varianti stagionali).

Fase 2 — Perché a volte funziona

Password umana prevedibile + assenza di limiti: il costo per l'attaccante diventa accettabile.

Fase 3 — Segnale di successo

Risposta diversa (200 vs 401), cookie di sessione, redirect alla dashboard — il simulatore li descrive nel log.

Fase 4 — Difesa

Rate limiting per IP e per account; CAPTCHA progressivo.
2FA (TOTP, WebAuthn) rende inutile solo la password rubata.
Alert su picchi di fallimenti; bloccare password in breach list (HIBP).

Console — Upload non sicuro (simulata)

Esempio didattico: file foto.jpg che in realtà contiene codice server. Nessun file viene caricato sul disco.

Nome file dichiarato

Content-Type inviato dal browser

Contenuto (solo testo dimostrativo)

[PRONTO] Validazione file spiegata passo-passo

Impatto tipico: critico

Percorso didattico

Fase 1 — Funzione legittima

L'utente carica un'immagine o un PDF; il server la memorizza e mostra un link pubblico.

Fase 2 — Controllo insufficiente

Si guarda solo l'estensione o il MIME inviato dal client — entrambi falsificabili.

Fase 3 — Escalation

Se la cartella /uploads esegue PHP o script, aprire l'URL del file può eseguire comandi sul server.

Fase 4 — Difesa

Whitelist estensioni + verifica magic bytes reali.
Storage su bucket senza interprete; servire file statici con Content-Disposition: attachment.
Nome random (UUID), scan antivirus, limiti dimensione.

Console — CSRF (simulata)

Domini fittizi (bank.example.com). Il log mostra come il browser «porta» la sessione senza che tu clicchi consapevolmente.

Sito dove sei loggato (esempio)

Pagina che visiti dopo (malevola)

Azione che il sito eseguirebbe

[PRONTO] Nessuna richiesta di rete verso domini reali

Impatto tipico: alto

Percorso didattico

Fase 1 — Sessione valida

Hai fatto login su bank.example.com; il browser conserva un cookie di sessione.

Fase 2 — Trappola cross-site

Apri un'altra pagina che contiene form o immagine che punta a un URL sensibile della banca.

Fase 3 — Richiesta «automatica»

Il browser allega i cookie: per il server sembra una tua azione, anche se non hai confermato nulla.

Fase 4 — Difesa

Token CSRF univoco per sessione e per form.
Cookie SameSite=Lax/Strict; verifica header Origin.
Conferma esplicita (password, 2FA) per operazioni irreversibili.

Stato: Laboratorio attivo (offline) Tema: SQL Injection Ultima simulazione: —