¿Qué fallas hay detrás de HttpContext.Current object i .NET?

  

"no ponga sesión o System.Web en sus capas empresariales"

La razón principal de esto es que hace que las pruebas unitarias sean una pesadilla. Se supone que su capa empresarial está completamente separada de su capa web, debería poder tomar ese BLL y colocarlo en una aplicación de escritorio y hacer que funcione bien.

Al ser como HttpContext.Current es una colección de objetos (Solicitud, Respuesta, Sesión, etc.) y cada uno tiene sus propias fuentes (Encabezados de solicitud, Búfer de respuesta, Sesión vinculada a la cookie de ID de sesión de ASP.NET) que no hay. No hay una respuesta universal solo para HttpContext.

Sin embargo, las sesiones tienen algunos problemas inherentes, el secuestro y la reparación de la sesión es uno de ellos, principalmente debido a la incapacidad de rotar los ID de sesión en el inicio de sesión, Micrsoft se ha negado a solucionar este problema y deberá implementar la seguridad. alrededor de eso (por ejemplo, el cifrado de formularios web de su ID de sesión al iniciar sesión es un ejemplo que examiné brevemente (querrá investigar más), o mientras usamos, una cookie de autenticación vinculada a su sesión que solo es HTTPS y gira cuando sea necesario).

En cuanto a elementos como Usuario e Identidad, estos dependen de sus métodos de autenticación, generalmente administrados por Webforms, pero si vuelve a usar uno personalizado, la seguridad depende de usted para usar las prácticas estándar.

Por lo tanto, estrictamente hablando, HttpContext.Currenty no es técnicamente un límite de seguridad, ya que es más que solo un límite de hilo. Con la ubicación correcta (o tal vez incorrecta) del código (del lado del servidor), podría ingresar en la sesión de otra persona.

Como señaló @StrangeWill con respecto a no hacer que la sesión o cualquier cosa relacionada sea visible para la capa empresarial, es más una decisión arquitectónica que una decisión de seguridad.