Protezione cookie e sessioni

Il problema che sto avendo, che non può essere risolvibile, è la seguente:Protezione cookie e sessioni

Ho un cliente che è una grande organizzazione di 1.500 + utenti a 7-8 posizioni differenti. L'applicazione è un'applicazione PHP costruita sul framework v3.0 di Kohana. L'organizzazione si trova dietro un server di filtraggio proxy a livello di ISP. Ogni posizione ha un indirizzo IP pubblico principale che passa attraverso il proxy e poi sul web. Ogni utente ha una workstation Mac o Windows rilasciata dal datore di lavoro.

Quello che stanno vivendo sembra essere collisioni di biscotti. Esempio: un utente accede alla propria workstation quindi un altro utente accede dalla stessa posizione, workstation diversa, con lo stesso sistema operativo e il tipo di browser. Il secondo utente riceve la sessione attiva dei primi utenti ricevendo un cookie appena generato (token) che corrisponde al primo utente. Questo sembra essere solo correlato al cookie 'authautologin' (impostato quando la casella di controllo remember me è impegnata nella schermata di accesso), ma sto mantenendo le mie opzioni aperte al caching dal proxy (non posso provare che il il proxy è ancora nella cache).

A causa dell'impostazione della rete, il server vede centinaia di utenti che accedono dallo stesso indirizzo IP allo stesso agente utente. Il mio pensiero iniziale è che il modo in cui Kohana v3 genera i cookie che sono unici per il browser (user agent) non è abbastanza unico per questa applicazione reale.

Qualcuno ha mai sperimentato qualcosa di simile? E quali sarebbero le azioni corrette da intraprendere nella generazione di cookie e sessioni? Sarebbe meglio gestire i cookie e le sessioni attive nel database?

Moduli Kohana: Jelly-Auth, gelatina, e Auth
Server: Apache/2.2.9 (Debian) mod_fastcgi/2.4.6 mod_jk/1.2.26 PHP/5.2.6-1 + lenny8 con Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
Browser noti: IE 8 & 9, Firefox (OS e Win) e Safari (OS)

fonte

2011-12-19 ixasilent

+1: domanda con attenzione - con buoni dettagli disponibili. Molto bene. –

Accetto, ma non si tratta di un problema con il proxy applicabile a qualsiasi servizio che utilizza un cookie di accesso automatico? –

@Pekka che è stato il mio pensiero/frustrazione per l'ultima settimana. Poi, dopo aver chiesto al personale IT interno, ho appreso che lo scopo del filtro proxy era bloccare siti come GMail, Facebook, Twitter, ecc ... Quindi sono portato a credere che non abbiano accesso a siti al di fuori rete dove effettuano l'accesso. Questa applicazione potrebbe essere l'unica in cui è possibile che venga rilasciato un cookie di accesso automatico esterno alla rete. – ixasilent

È solo un'idea ma c'è/era (a seconda della versione di Debian e PHP) un bug con le sessioni PHP.Quello che suggerisco di provare:

check this link - questo non può essere correlato al tuo problema, ma vale la pena di provare
Passare al driver del database - darei il 90% di possibilità che questo possa risolvere tutto
test su diversi server Debian allora - questo potrebbe non essere facile da realizzare se

fonte

2011-12-19 18:14:48 matino

Non credo che il collegamento sia applicabile, ma debitamente indicato per riferimento futuro. L'applicazione utilizza MySQL PDO attraverso i moduli Kohana 3.0 Database e Jelly. Qualche altro guidatore in mente? Ci sono circa 15 altri siti identici (- il contenuto del database) su questo server per altri client che non segnalano questo problema, quindi sono abbastanza sicuro che abbia a che fare con il make-up della rete e la necessità di ottimizzare la generazione di cookie per questo sito. Buon collegamento! Inserirò il segnalibro, perché potrebbe risolvere un problema di timeout della sessione con un wiki che è stato sul mio masterizzatore posteriore per un mese. – ixasilent

Intendevo passare al driver del database di sessione, non rinunciare a PDO/Jelly se è quello che pensavi;) – matino

hai ragione nel memorizzare la sessione nel database corregge questo. Ad essere onesti, non sono contento di questa soluzione, ma per ora lo divertirò come un trucco. Ovviamente quando migliaia di utenti ricominceranno a utilizzare l'applicazione e finirò per sembrare un pazzo ... Tornerò! Per sicurezza, riscriverò il metodo set della classe kohana_cookie per essere compatibile con RFC 2109. Questa è almeno la cosa responsabile da fare. Grazie! – ixasilent

Wow i thats una brutta vulnerabilità, buona pesca!

Il modo migliore per generare i cookie in PHP è lasciare che PHP lo faccia: session_start(). E questo è tutto! Se stai generando il tuo cookie, allora sei davvero incasinato da qualche parte. Ora puoi usare il $_SESSION[] super globale. La procedura consigliata è chiamare session_start() in un file di intestazione comune prima di accedere a $ _SESSION nella propria applicazione.

Ci sono probabilmente altri problemi da prendere in considerazione come owasp a9, csrf e i flag dei cookie: HTTP_Only e il flag "sicuro" (forzando il cookie su https).

fonte

2011-12-19 16:51:16 rook

@Rock grazie! Ho scavalcato il codice un paio di volte e posso verificare che sì sto utilizzando PHP per gestire le sessioni (session_start(), session_name(), session_set_cookie_params(), session_destroy(), ecc ...). Ma solo perché me ne hai parlato, andrò a scavare di nuovo, a ricontrollare e a dare credito dove è il merito quando torno in aria. È un sito SSL e sono impostati i flag secure e HTTP_ONLY. – ixasilent

Siamo spiacenti, @Rook non intendeva digitare il tuo nome lì. – ixasilent

@ixasilent Non si dovrebbe mai aver bisogno di impostare un valore del cookie. Penso che tu stia facendo affidamento sulla classe kohana_cookie per identificare un utente. Questo sta usando setcookie(), che è cattivo. – rook

non sono sicuro se ho capito bene, ma ... ho capito che la richiesta va in questo modo:

utente (workstation) ==> proxy() ==> internet ==> sito web della società (e risposta in direzione inversa).

Verificare se il proxy imposta "HTTP_X_FORWARDED_FOR" (nella variabile superglobale $ _SERVER). Potrebbe essere l'unico modo per determinare l'indirizzo IP della workstation dell'utente. Se è così, hai finito.

fonte

2011-12-27 21:30:07

Chiudi, ma poiché il proxy funge anche da ISP, non esiste un HTTP_X_FORWARDED_FOR. – ixasilent

risposta

Problemi correlati