Miscelazione sessione ASP.NET con StateServer (SCARY!)

Memorizziamo due oggetti in sessione. In qualche modo, uno degli oggetti di un altro utente è stato caricato nella sessione di un altro utente. L'utente non avrebbe avuto accesso a questi dati particolari e, non appena l'hanno visto, sapevano che c'era qualcosa di molto sbagliato.Miscelazione sessione ASP.NET con StateServer (SCARY!)

Abbiamo una prova visiva dei dati che gli sono stati presentati, e c'è certamente in nessun modo potrebbe essere successo a meno che le sessioni non siano confuse. Questa è una situazione molto spaventosa che non riusciamo a capire (non possiamo riprodurla). L'unica risposta per noi è dare la colpa a ASP.NET StateServer per il mix delle variabili di sessione, che è completamente inaccettabile e ci mette in una posizione negativa.

Le nostre applicazioni sono app ASP.NET 2.0 in esecuzione su Windows Server 2003 con IIS6, utilizzando la modalità sessione StateServer cookieless="false" e FormsAuthentication.

Qualcun altro ha avuto questo problema? Come possiamo risolverlo?

fonte

2009-10-29 Josh Stodola

Ho visto questo, ma in. NET 1.1. t era apparentemente risolto in 2.0. Ho alcune domande prima di tentare di pubblicare una risposta. Prima domanda, stai usando la sessione di cucina? – David

Grazie! Sì, senza cuoco (si dice nella domanda). –

Scusa ... Non l'ho letto. Poiché l'utilizzo di sessioni senza cookie significa che SessionID è incluso nell'URL come parametro querystring, hai verificato che il parametro querystring SessionID dell'URL sia diverso tra i due utenti quando questo accade? – David

ci siamo imbattuti in questo problema esatto in mia compagnia precedente e ha preso 3 settimane per eseguire il debug. ASP.NET forniva all'utente lo stato di sessione di qualcun altro. Era davvero impossibile duplicare in un ambiente di debug.

La correzione quando abbiamo trovato era solo qualcosa in web.config. Non me lo ricordo pienamente, quindi ho passato un po 'di tempo a cercare su Google. Credo che il problema abbia a che fare con il caching dell'output. Dai un'occhiata a questo articolo in "Sessioni e cache di output".

http://download.microsoft.com/download/3/a/7/3a7fa450-1f33-41f7-9e6d-3aa95b5a6aea/MSDNMagazineJuly2006en-us.chm (l'articolo è intitolato mantenere i siti senza intoppi da evitare questi 10 comuni ASP.NET insidie  da Jeff Prosise nel luglio all'edizione 2006 della rivista MSDN)

Se questo suona come lo scenario, la correzione rapida potrebbe semplicemente disabilitare l'opzione enableKernelOutputCache in web.config.

Buona fortuna.

fonte

2009-10-29 21:38:37 Linus

Credo che tu abbia ragione! In effetti, abbiamo attivato la memorizzazione nella cache abilitata su un modulo web * uno * e il modulo era quello responsabile per compilare la nostra variabile di sessione discrepanza. Sei un santo, uno studioso, un gentiluomo, un genio, e non posso ringraziarti abbastanza !! –

+1. Anche se Josh ha detto che è stata scambiata solo una variabile, non l'intera sessione, come indicato sul tuo link. – wtaniguchi

Per chiarire, ho solo * prova * che una variabile è stata scambiata. –

Cercare i bug nel proprio codice prima - questa è di gran lunga la spiegazione più probabile. Per esempio. utilizzando campi statici o altra memoria condivisa come la cache ASP.NET per dati specifici dell'utente.

fonte

2009-10-29 20:20:01 Joe

Ho appena trascorso gli ultimi dieci giorni facendo proprio questo. Ho sottolineato la parola "certamente" nella mia domanda per un motivo. Fidati di me, il nostro codice è a prova di proiettile. –

Inoltre, questa app è in produzione da anni e abbiamo riscontrato questo problema solo una volta. –

+1 Ogni volta che ho visto qualcosa di simile a ciò che Josh sta descrivendo, questo è il colpevole. – kemiller2002

Quante volte si è verificato? Hai controllato gli utenti utilizzando il browser o inviando link tra loro con gli ID di sessione?

Un modo per verificare con sicurezza il bug di State Server è passare a un altro gestore di sessione, eseguire il fallback su in-proc se è possibile o utilizzare SQL Server, ma sarebbe meglio trovare un modo per riprodurre il bug prima, quindi potrebbe testarlo

fonte

2009-10-29 20:32:33 Wagner

Si è verificato solo una volta. Il back browser non lo è, perché l'autenticazione degli utenti non consentirebbe l'accesso a questi dati in qualsiasi momento. Non c'è modo che stiano facendo qualcosa come hacking ID di sessione, i nostri utenti sono vecchi uomini d'affari che non sanno nemmeno cosa sia una sessione. –

Possibile risposta - isea simile riportata utilizzando lo stato di sessione senza cookie.

session showing something wrong

Modifica - Aggiunta

Un'altra possibile risposta:

An ASP.NET page is stored in the HTTP.sys kernel cache in IIS 6.0 when the ASP.NET page generates an HTTP header that contains a Set-Cookie response

fonte

2009-10-29 20:50:18 David

David, mi sono sbagliato. La modalità di sessione NON è senza cookie. –

+1 perché il secondo link modificato in sembra promettente. – GBegen

I due utenti incrociati utilizzano entrambi lo stesso proxy di cacheing? In tal caso, un utente potrebbe vedere i dati memorizzati nella cache di un altro utente se gli URL corrispondono, specialmente se il proxy non si comporta bene.

Non era questo il problema principale del progetto Google Web Accelerator (ora fuori produzione)?

fonte

2009-10-29 21:57:26 GBegen

Questo problema si è rivelato essere un attributo OutputCache in una vista parziale.

fonte

2014-02-24 06:49:21 stuartdotnet

Miscelazione sessione ASP.NET con StateServer (SCARY!)

risposta

Problemi correlati