Cookie & Privilege Escalation
Viola una finta dashboard scolastica: ispeziona i cookie di sessione, cambia role=student in role=admin e sblocca i privilegi per modificare i voti. La lezione vera: non fidarsi mai del client. Tutto simulato e locale.
I tuoi voti
| Materia | Voto |
|---|
⚙ Strumenti amministratore
Sblocco riservato al personale. Da qui i voti dell'intera classe sono modificabili. (In una vera app questo non dovrebbe MAI dipendere da un cookie.)
▸ Cookies · registro-pariovoti.it
(questi valori vengono inviati al server a ogni richiesta)
Ruoli che il «server» considera privilegiati: admin, professore, docente. Cambia role e ricarica.
Da studente ad amministratore
role da student a admin.💥 Privilege escalation riuscita!
Hai ottenuto privilegi da amministratore solo cambiando un valore lato client. Non hai forzato nessuna password: il sito si è fidato di un dato che l'utente può modificare a piacere. Questa è una vulnerabilità reale e molto comune (broken access control, in cima alla OWASP Top 10).
Perché non doveva funzionare
Il problema non è «nascondere meglio il cookie»: è aver delegato al client una decisione di sicurezza.
Regola d'oro: l'autorizzazione si verifica sempre sul server. Il ruolo non si legge da un cookie modificabile: si ricava da una sessione server-side (il client riceve solo un identificatore di sessione casuale e firmato, che non rivela né permette di scegliere il ruolo).
In pratica: ad ogni azione sensibile (modificare un voto) il server ricontrolla «questo utente può davvero farlo?». Token di sessione firmati, scadenza, controlli lato server, principio del privilegio minimo. Mai fidarsi di ciò che arriva dal browser — input, cookie o parametri che siano.