Quali difetti si trovano dietro HttpContext.Current object i .NET?

"don't put session or System.Web into your business layers"

La ragione principale di questo è perché rende completamente le unità test un incubo. Il tuo livello aziendale dovrebbe essere completamente separato dal tuo livello Web, dovresti essere in grado di prendere quel BLL e inserirlo in un'app desktop e farlo funzionare correttamente.

Essere come HttpContext.Current è una raccolta di oggetti (Request, Response, Session, ecc.) e ognuno di essi ha le proprie fonti (intestazioni di richiesta, buffer di risposta, sessione legata al cookie dell'ID di sessione ASP.NET) che non esiste 'una risposta universale per solo HttpContext.

Tuttavia, le sessioni hanno alcuni problemi intrinseci, il dirottamento e la fissazione della sessione è uno di questi, causato principalmente dall'incapacità di ruotare gli ID di sessione al momento del login, Micrsoft ha rifiutato di risolvere questo problema e sarà necessario implementare la sicurezza attorno a ciò (ad esempio, la crittografia di Webforms dell'ID di sessione al momento del login è un esempio che ho esaminato brevemente (vorrai ricercarlo di più) o, come usiamo, un cookie di autenticazione legato alla tua sessione che è solo HTTPS. e ruota quando richiesto).

Per quanto riguarda gli elementi come User e Identity, quelli dipendono dai tuoi metodi di autenticazione, generalmente gestiti da Webforms, ma se usi di nuovo uno personalizzato, la sicurezza spetta a te usare pratiche standard.

Quindi, in senso stretto HttpContext.Currenty non è tecnicamente un limite di sicurezza, poiché è più che altro un limite di thread. Con il giusto (o forse sbagliato) posizionamento del codice (sul lato server) potrei entrare nella sessione di qualcun altro.

Come sottolineato da @StrangeWill riguardo al non rendere la sessione o qualsiasi cosa correlata visibile al livello aziendale, è più una decisione architettonica che una decisione di sicurezza.