Il sottodominio di amministrazione non ferma il CSRF: quattro verifiche prima del rilascio

Spostare l’interfaccia amministrativa su admin.example.com è un miglioramento reale: tiene i cookie amministrativi lontani dalle pagine pubbliche, dà alle due applicazioni cache separate e permette di indirizzare una politica di rete più severa su un solo nome host. Non è però un controllo CSRF e non rende il codice del sito pubblico sicuro da lasciare aperto davanti a un amministratore che ha effettuato l’accesso. La separazione cambia ciò che il browser considera un confine, non ciò che il server verifica, quindi fate queste quattro verifiche prima di dichiarare il lavoro finito.

Leggete origine e sito come due parole diverse

Un’origine è schema, host e porta, quindi https://www.example.com e https://admin.example.com sono origini diverse. Un sito, nel senso di SameSite, è schema più dominio registrabile, quindi quegli stessi due nomi host sono di solito lo stesso sito. Questa differenza è tutta la trappola: l@APOS;attributo SameSite non vi aiuterà tra sottodomini fratelli, perché il browser non considera affatto la richiesta come tra siti. Indirizzate l@APOS;interfaccia amministrativa verso un dominio registrabile davvero diverso, come admin-example.net, e la richiesta diventa davvero tra siti, ed è lì che SameSite=Lax o Strict inizia a fare un lavoro su cui potete contare.

Provatelo nel browser invece di ragionarci sopra.

Caricate il sito pubblico, aprite gli strumenti per sviluppatori e guardate quali cookie il browser allega a una richiesta verso l@APOS;host amministrativo. Se il cookie non ha l@APOS;attributo Domain è solo per l@APOS;host e resta sul suo nome; se porta Domain=example.com viaggia verso ogni fratello, e il nuovo sottodominio non vi ha dato nulla per quel cookie.

Separate poter leggere la risposta da poter inviare la richiesta

La politica della stessa origine limita la lettura delle risposte tra origini. Non impedisce che una richiesta venga inviata e non impedisce a un modulo di portare credenziali che il browser già possiede. Una richiesta semplice, con tipo di contenuto da modulo o un GET semplice, viene consegnata senza verifica preliminare; CORS decide poi se lo script chiamante può leggere la risposta. Il CSRF vive interamente dal lato dell@APOS;invio.

Per questo il server ha bisogno di una verifica esplicita per le operazioni che cambiano stato. Un token di sincronizzazione legato alla sessione, o un cookie a doppio invio confrontato lato server, copre il caso; un confronto di Origin o Referer vale come secondo cancello ma non come unico, perché non ogni richiesta porta l@APOS;intestazione e non ogni proxy la conserva. La guida OWASP alla prevenzione del CSRF tratta SameSite come uno strato tra diversi proprio per questo motivo.

Decidete che cosa il cancello di rete dimostra davvero

Una lista di uscite VPN consentite davanti all@APOS;host amministrativo è un buon controllo e una debole affermazione di identità. Dimostra che la richiesta è arrivata da un indirizzo che la VPN assegna, che può essere condiviso da tutti su quell@APOS;uscita, e non dice nulla su quale persona o dispositivo ci sia dietro. Trattatela come filtro di ingresso, non come autenticazione.

Tenetela indipendente dalle verifiche a livello di richiesta. Se la lista è l@APOS;unica cosa tra un attaccante e un endpoint che cambia stato, una rotta mal configurata, un client in split-tunnel o un portatile preso in prestito elimina del tutto il controllo.

Registrate anche i rifiuti fuori dagli intervalli attesi. Un@APOS;ondata di questi è il segnale più utile che qualcuno sta sondando il confine appena costruito, e il silenzio è il segnale che il filtro non viene raggiunto affatto.

Tenete espliciti cookie, accesso e autorizzazione

La portata del cookie decide la maggior parte dell@APOS;esito. Un cookie del dominio padre viene inviato all@APOS;host amministrativo, quindi un@APOS;iniezione di script sul sito pubblico può agire con la sessione di un amministratore; un cookie solo per l@APOS;host non può. Preferite la forma solo per l@APOS;host, aggiungete l@APOS;attributo Secure e usate il prefisso __Host- dove la piattaforma lo supporta, perché quel prefisso richiede Secure, Path=/ e nessun attributo Domain. Leggete l@APOS;intestazione di risposta invece del barattolo dei cookie: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, senza attributo Domain. Il browser scarta un cookie __Host- che porti Domain, quindi un cookie che appare ancora su host fratelli è prova che il prefisso non è mai stato applicato.

Poi tenete l@APOS;autorizzazione sul server, per ogni richiesta, su ogni endpoint amministrativo, non solo all@APOS;accesso. Una richiesta da una rete consentita deve comunque essere autenticata e autorizzata per l@APOS;operazione che chiede; il nome host non è un attore. Se le applicazioni pubblica e amministrativa condividono un flusso di accesso o un archivio di sessioni, scrivete quella relazione, perché è il percorso più breve da un difetto del sito pubblico a un@APOS;azione amministrativa.

Ricontrollate il confine dopo la separazione

Eseguite i test negativi, non solo il percorso felice: un modulo tra siti senza token deve essere rifiutato, un token di un@APOS;altra sessione deve essere rifiutato e nessun GET deve cambiare stato. Controllate gli attributi dei cookie negli strumenti per sviluppatori, confermate che la verifica di Origin scatti su una richiesta non corrispondente e provate l@APOS;host amministrativo da fuori dell@APOS;intervallo VPN per vedere il filtro in azione.

Niente di tutto questo elimina un difetto XSS dentro l@APOS;applicazione amministrativa stessa. Un nome host separato è un confine di isolamento lato browser con un valore reale, e non sostituisce la prevenzione dell@APOS;esecuzione di codice non sicuro né la protezione delle richieste lato server. Dopo la separazione la lista è più corta di quanto sembri: origine distinta, cookie solo per l@APOS;host, un token a ogni modifica, un filtro di ingresso di cui non vi fidate come identità e un@APOS;autorizzazione decisa per ogni richiesta.