¿Por qué es necesario validar los datos en un servlet obtenido llamando a HttpSession.getAttribute ()?

3

Soy nuevo en la programación de aplicaciones web y estoy tratando de entender las implicaciones de seguridad de no validar los datos obtenidos al llamar al método de la interfaz javax.servlet.http.HttpSession.getAttribute (). Sé que, como regla general, siempre se deben validar los datos obtenidos de una fuente no confiable, pero supongo que no entiendo por qué los contenidos de la sesión no son de confianza. Esto se basa en mis suposiciones (probablemente no justificadas) de que la única forma en que se podrían agregar datos a la sesión sería llamando a HttpSession.setAttribute () y que solo el código de confianza que se encuentre dentro del alcance de la misma aplicación debería poder hacerlo. .

Supongo que lo que realmente estoy preguntando es cómo un atacante aprovecharía mi falla para realizar la validación correcta de los datos obtenidos de la HttpSession. ¿Se debe a que la implementación es desconocida y no se puede garantizar que los contenidos de la sesión no se construyan de alguna manera a partir de los datos en la solicitud HTTP (aparte de un ID de sesión) y, por lo tanto, estén sujetos a manipulación? ¿O es porque confiar en el contenido de la sesión significa confiar de manera implícita en el ID de sesión, que puede estar comprometido y apuntar a la sesión incorrecta? (aunque para que eso suceda, parece que el atacante tendría que tener algún medio para crear una sesión alternativa que contenga los datos comprometidos).

Suponiendo que el contenido de la sesión no se construye a partir de los datos de la solicitud, ¿es posible que la única forma de aprovechar esta vulnerabilidad sea si existe otra vulnerabilidad que permita a un atacante crear una sesión incorrecta? P.ej. ¿Cargar código ejecutable y hacer que el servidor lo ejecute y devuelva un ID de sesión que se capture y reproduzca?

    
pregunta user16047 16.11.2012 - 00:53
fuente

3 respuestas

1

No, tienes razón, no hay forma de que un atacante externo inyecte contenido en un atributo de sesión.

No veo ninguna razón para validar los datos del almacenamiento de la sesión. Si tiene un código de atacante ejecutándose en su contenedor de servlets, ya está en una situación mucho peor que cualquier otra cosa que tenga que ver con la validación de entrada.

    
respondido por el bobince 16.11.2012 - 11:38
fuente
1

Tiene dos opciones: (a) validar todos los datos antes de almacenarlos en la sesión, o (b) validar los datos después de leerlos fuera de la sesión. Creo que la opción (a) tiene mucho más sentido. Si ese es el enfoque que sigue, entonces no, no necesita validar los datos que saca de la sesión, ya que ya se habrá validado (antes de que se almacenara en la sesión).

    
respondido por el D.W. 16.11.2012 - 12:08
fuente
1

En la mayoría de los casos su derecho. Validar correctamente los datos antes de que entren en la sesión generalmente le permitiría confiar en la sesión. Una cosa a considerar es que en estos días muchas aplicaciones usan fuentes de datos externas para sincronizar sesiones usando fuentes de datos externas (redis, mongo, etc.) para escalar aplicaciones horizontalmente. Si esa fuente de datos está comprometida, un atacante podría explotar su aplicación a través de los atributos de la sesión

    
respondido por el David Welch 17.11.2012 - 08:59
fuente

Lea otras preguntas en las etiquetas