Perché ASP.NET accetta identificatori di sessione creati esternamente?

Question

Ho un sito Web ASP.NET 3.5 che utilizza il provider di appartenenza SQL standard.

L'applicazione deve passare IBM Rational AppScan prima di poter inviare alla produzione.

sto ottenendo l'errore:
Gravità: Alta Tipo
test: Applicazione
URL Vulnerabile: http://mytestserver/myapp/login.aspx
Operazioni di bonifica: non accettano di identificativi di sessione creati esternamente

Cosa posso fare risolvere questo?

Sto utilizzando SQL Membership Provider. Questo è collegato? Sto usando anche i controlli di login standard. Ho il "Ricordami" spento e nascosto.

Grazie.

Answer 1

Questa non è una vulnerabilità (e davvero non mi piace AppScan a causa del suo falso positivo es: il numero di volte che ho dovuto spiegare che i cookie CSRF non devono essere collegati a una sessione sul mio piccolo progetto open source sta diventando fastidioso).

Tutto ciò che accadrà in questo caso è la prima volta che qualsiasi elemento viene memorizzato nello stato di sessione con un identificativo di sessione creato una nuova sessione verrà aperta sul server, con nulla in esso. Se sei preoccupato per la fissazione della sessione, puoi cancellare il cookie dopo l'autenticazione.

Session.Abandon(); 
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", "")); 

Ma con autenticazione basata su form i dettagli di autenticazione non sono tenuti in sessione e quindi la fissazione non è un problema a tutti.

Francamente se si deve eseguire scansioni di sicurezza senza che nessuno valuti se i risultati non sono falsi positivi, allora si tratta di un problema completamente diverso.

Answer 2

Potrebbe essere necessario modificare le impostazioni dei cookie di default di essere solo te App

provate ad impostare un percorso di cookie unico:

<forms name="YourAppName" 
     path="/FormsAuth" ... /> 

http://msdn.microsoft.com/en-us/library/ms998310.aspx#paght000012_additionalconsiderations

Più lettura ... http://msdn.microsoft.com/en-us/library/ms998258.aspx

Answer 3

Sembra che la proprietà sia controllata da RegenerateExpiredSessionId. Impostalo su vero. Mantenere anche il time-out a un valore basso, il più stretto possibile dagli utenti (ad esempio 10-15 minuti).