Guida alla risoluzione dei problemi delle sessioni delle app self-hosted per modifiche a proxy e cookie

L’approccio sicuro consiste nel trattare il confronto strato per strato tra richieste dirette e inoltrate tramite proxy, cookie di risposta, archiviazione del browser e stato della sessione sul backend come una sequenza di verifiche osservabili, non come un singolo comando.

In un’applicazione web self-hosted dietro un reverse proxy, il rischio concreto è che gli utenti vengano disconnessi, rimangano bloccati in un ciclo di reindirizzamento o non riescano a stabilire una sessione dopo modifiche al proxy o ai cookie. Registra l’identità attuale e il punto di ripristino, inizia dal discriminatore meno invasivo, interpreta i risultati positivi e negativi prima di modificare un’altra variabile e fermati quando lo stato di archiviazione diventa instabile o l’unica copia recuperabile verrebbe esposta. Il flusso di lavoro seguente termina solo quando il carico di lavoro originale ha esito positivo o le evidenze raggiungono una soglia di escalation.

Riproduci un percorso di sessione e conserva le evidenze

Scegli un utente, un profilo del browser, un hostname e un percorso di accesso. Registra la prima richiesta che fallisce, la sequenza degli stati, le destinazioni dei reindirizzamenti, le intestazioni di risposta Set-Cookie con i valori oscurati, i cookie della richiesta, i log del proxy, i log dell’applicazione e l’esatta modifica alla configurazione che ha preceduto il problema.

Non iniziare cancellando tutti i cookie o ruotando il segreto dell’applicazione. Usa un profilo del browser privato come controllo pulito, conservando il profilo che presenta il problema per il confronto. Verifica se l’accesso diretto al backend funziona: questo distingue l’autenticazione dell’applicazione dal comportamento di URL e cookie derivato dal proxy.

Fermati se l’applicazione espone token nei log, il proxy accetta intestazioni di inoltro contraffatte da client non attendibili o l’accesso aggira TLS. Proteggi le credenziali e correggi il confine di sicurezza prima di continuare la risoluzione funzionale del problema.

Verifica schema, host e attendibilità dell’inoltro

Confronta l’URL esterno con ciò che l’applicazione ritiene di vedere: schema, host, porta, percorso di base e indirizzo IP del client. Esamina Host, X-Forwarded-Proto o le intestazioni di inoltro standardizzate e l’elenco dei proxy attendibili dell’applicazione. Un backend che considera HTTP le richieste HTTPS potrebbe rifiutare i cookie Secure o generare un reindirizzamento infinito verso HTTPS.

Usa un unico proxy attendibile per impostare o sostituire le intestazioni di inoltro e configura l’applicazione affinché si fidi solo di quel passaggio. Non aggiungere ciecamente valori forniti dal client. Testa un accesso e un reindirizzamento assoluto dopo ogni modifica, invece di cambiare contemporaneamente le intestazioni del proxy e l’URL di base dell’applicazione.

La guida di ZimaSpace sulla diagnosi dell’accesso diretto e tramite proxy utilizza lo stesso confronto tra accesso diretto e tramite proxy dopo il riavvio di un proxy. L’esempio con Immich è più circoscritto, ma il percorso delle evidenze è applicabile anche altrove: dimostra che la sessione del backend funziona, quindi esamina le intestazioni di inoltro, il routing e lo stato del browser.

Esamina l’ambito dei cookie e le decisioni del browser

Controlla il nome del cookie, Domain, Path, Secure, HttpOnly, SameSite, la scadenza e l’eventuale presenza di cookie duplicati con lo stesso nome a percorsi o domini diversi. Gli strumenti per sviluppatori del browser mostrano se un cookie è stato memorizzato, rifiutato o omesso dalla richiesta successiva; i soli log del server non possono rivelare questa decisione.

Il documento di OWASP sul comportamento dei cookie SameSite spiega come i valori SameSite controllino l’invio dei cookie tra siti. Se l’autenticazione attraversa siti diversi o utilizza un flusso incorporato, SameSite=None richiede anche Secure; per una semplice applicazione dello stesso sito, ampliare inutilmente l’ambito del cookie indebolisce il progetto.

Nel profilo di controllo, elimina solo il cookie interessato dopo averlo registrato, quindi ripeti l’accesso. Se un cookie nuovo funziona mentre il profilo conservato continua a non funzionare, confronta ambito e scadenza; se entrambi falliscono, torna alle intestazioni di risposta o all’archiviazione della sessione sul backend invece di cancellare ripetutamente lo stato.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Controlla lo stato condiviso della sessione e convalida la correzione

Per applicazioni multi-container o replicate, verifica che ogni istanza utilizzi lo stesso segreto per la firma della sessione, la stessa sorgente temporale e lo stesso backend condiviso per le sessioni, quando necessario. Un proxy che alterna tra più istanze può sembrare la causa di disconnessioni casuali quando un’istanza non riesce a convalidare il cookie dell’altra.

La trattazione di PortSwigger sul confine di sicurezza SameSite è incentrata sulla sicurezza, ma chiarisce che SameSite è un confine imposto dal browser, non un generico interruttore per riparare l’accesso. Mantieni la protezione CSRF adattandola all’origine effettiva dell’applicazione e al flusso di reindirizzamento.

Convalida accesso, disconnessione, scadenza per inattività, riavvio del browser, modifica della password e accesso tramite gli hostname interni e remoti previsti. Chiudi il problema solo quando i vecchi cookie falliscono in modo sicuro, le nuove sessioni sopravvivono al routing normale e nessuna intestazione di inoltro o attributo dei cookie è stato reso meno restrittivo oltre quanto richiesto e documentato.