ASP.NET MVC4 Nome utente archivio stato sessione

Question

Ho creato la mia prima piccola webapp uber con MVC4. Finora ho usato il layout per configurare la webapp e aggiunto alcuni controller di visualizzazioni e un modello per registrarmi e consentire agli utenti di effettuare il login.

Una volta che un utente ha effettuato l'accesso/registrato, memorizzo il suo nome utente nella sessione. Ho letto questa proprietà dalla sessione per determinare se un utente è stato registrato o meno.

È una cattiva pratica? Ho letto molto su webapps RESTful e senza stato. Ho la sensazione che non dovrei salvare nulla nella mia sessione.

ad es.

@if (string.IsNullOrEmpty(Session["User"] as string)) 
{ 
    <dl> 
     <dt><a href="/Account/Register">Register</a></dt> 
     <dt><a href="/Account/Login">Login</a></dt> 
    </dl> 
} 
else 
{ 
    <dl> 
     <dt><a href="/Account/ShowAccount/@Session["User"]">@Session["User"]</a></dt> 
     <dt><a href="/Account/Logout">Log out</a></dt> 
    </dl>  
} 

Q1: questa è una cattiva pratica?

Q2: è questo "hack safe"? Com'è, è facile hackerare la sessione corrente e memorizzare un valore nella Sessione ["Utente"] per escludere l'accesso?

Answer 1

per rispondere alle vostre domande:

1) In generale, utilizzando lo stato della sessione non è cattiva pratica, fino a quando ne avete bisogno per le vostre applicazioni e capisci le sue implicazioni sulle prestazioni e la scalabilità. Tuttavia, nel tuo caso, se tutto ciò che devi memorizzare è il nome dell'utente, non ne hai davvero bisogno, se la tua applicazione utilizza un provider di appartenenze ASP.Net, allora questa informazione è disponibile nella proprietà User nel MVCController classe di base:

var username = User.Identity.Name 

ci sono tre modi in cui i dati della sessione possono essere memorizzati: "InProc", in cui è memorizzato nel processo di applicazione, "StateServer", dove viene immagazzinato processo di output su un server separato, e "SQLServer", in cui è memorizzato in un DB di SQL Server. Quale si dovrebbe usare dipende da se si sta utilizzando una server farm, se la sessione deve essere duratura (ovvero sopravvivere al riavvio del computer) e quali sono i requisiti di prestazioni per l'app (StateServer e SQLServer sono meno performanti di InProc). Ulteriori informazioni possono essere trovate here

2) È necessario utilizzare SSL per proteggere i dati della sessione. I dati inviati su SSL (HTTPS) sono completamente crittografati, intestazioni incluse (quindi cookie). Una buona discussione su come prevenire gli attacchi di dirottamento di sessione è found here.