SetAuthCookie crea in pratica un nuovo FormsAuthenticationTicket con il nome utente & opzioni di persistenza in dotazione, serializza esso, FormsAuthentication.Encrypt (s 'esso,) e la mette nella collezione Response.Cookies. SetAuthCookie e GetAuthCookie chiamano entrambi FormsAuthentication.Encrypt indirettamente.
Su richieste successive, FormsAuthentiationModule gestisce l'evento AuthenticateRequest. Se vede un cookie (potrebbe essere scaduto), tenta di decifrare il suo valore con machineKey (potrebbe essere stato manomesso) e lo ha deserializzato in FormsAuthenticationTicket (potrebbe essere danneggiato). Se nessuna di queste (cose cattive) accade, il ticket contiene il nome utente, la data di emissione, le informazioni di scadenza, ecc. Se il ticket non è scaduto, un IIdentity e IPrincipal vengono creati e assegnati a HttpContext.Current.User e Thread. CurrentThread.Principal. In .NET 4.5 e versioni successive (penso), questo è basato sulle attestazioni (ClaimsIdentity, ClaimsPrincipal). In precedenza, era un (GenericPrincipal, FormsIdentity) penso.
Qualsiasi manomissione sul lato utente causerà il trattamento della richiesta come anonima. Non riuscirà a decifrare. L'unica cosa che comprometterebbe questa convalida sarebbe se la macchinaKey in web.config/machine.config venisse in qualche modo nelle mani di un utente malintenzionato o se ci fosse un bug nel codice framework (cercare Padding Oracle per un esempio storico di questo).
A parte questo, l'altra cosa a cui prestare attenzione sarebbe il dirottamento di sessione. Ad esempio, se qualcuno ruba il tuo cookie su un wifi pubblico, può presentarlo al server e il server si comporterà come se fossi tu. Questo generalmente implica lo sniffing del traffico di rete. Per questi motivi, è consigliabile utilizzare SSL per l'intero sito e impostare il cookie solo su HTTP e Secure (presentato solo tramite connessioni https) in web.config/system.web/authorization/forms. HTTP significa solo che non sarà disponibile per Javascript sul lato client. Solo HTTP e sicuro in modo efficace significa solo HTTPS. Questo funzionerà solo se utilizzi SSL sul tuo intero sito.
FormsAuthentication funzionerà correttamente sui browser Web mobili. Richiede semplicemente che il cliente accetti i cookie. Per quanto ne so, tutti i dispositivi mobili lo permetteranno.
Per quanto riguarda il dirottamento di sessione, l'AuthCookie sarà compromesso se alcune parti del mio sito sono pubbliche e sicure, ad esempio https (accessibili solo agli utenti registrati). Lo sto chiedendo perché so che una volta creato AuthCookie va avanti e indietro su ogni chiamata client-server. c'è un modo per evitarlo su certe pagine? Il mio piano è registrare il passo di autenticazione come filtro nel mio app_start; e fai alcune azioni [anonimo] ... i tuoi pensieri (grazie per la tua meravigliosa risposta!) – DotNet98
Puoi usare l'opzione Percorso in system.web/authorization/forms per far sì che il cookie venga presentato solo per un determinato percorso sul tuo luogo. Sfortunatamente, sei limitato a 1 percorso. Pertanto, se si dispone di una sezione del sito che si desidera consentire l'accesso anonimo e un'altra che richiede l'autenticazione/l'autorizzazione, è possibile inserire tutto il contenuto protetto in un percorso separato e limitare il cookie a tale percorso.Vorresti comunque impostarlo su secure e solo http. Il percorso dei cookie è il modo più affidabile per assicurarsi che il tuo cookie non si muova su un canale chiaro. – scottt732
sì, sembra che https sia la strada da percorrere. Immagino di poter avere pagine https senza autenticare l'utente; Presumo che questo avrà un impatto sulle prestazioni data la natura di https. Farai un po 'di luce su cosa succede con le mie chiamate AJAX allora? dovrò fare qualcosa di specifico per proteggere le mie chiamate Ajax (farò viaggiare AuthCookie insieme alle mie chiamate ajax) – DotNet98