¿No es seguro redirigir a la URL del remitente?

Navega tus respuestas
3

¿Es un problema cuando las URL de una aplicación web redirigen a la URL especificada en el encabezado Referer ?

No es una redirección abierta como cualquiera de los ejemplos /whatever?url=evil.com que he visto, que pueden explotarse teniendo usuarios haga clic en un enlace a la aplicación legítima (o al menos no tan sencillo). Esta respuesta parece indicar (hacia el final) que las referencias no pueden ser falsificadas arbitrariamente, al menos no sin la ayuda del usuario , en cuyo caso, la redirección probablemente no sea un problema.

MSA-15-0019 ( publicación de blog relacionada ) parece ser lo que estoy preguntando , pero no se explica por qué es un problema. Según tengo entendido, es más probable que la adición de la URL Referer al botón que se muestra en la página resulte en una vulnerabilidad potencial reflejada de XSS.

Tenga en cuenta que no se trata de posibles problemas de CSRF en ninguna URL que no muestre una respuesta, sino que, por el contrario, es probable que actúe sobre la entrada de alguna manera; pero específicamente sobre el encabezado Location redirigido a la URL Referer . ¿Es que un problema? Si es así, ¿cómo / por qué?

Si importa, la aplicación está escrita en Java y el código que me preocupa es básicamente equivalente a myHttpServletResponse.sendRedirect(myHttpServletRequest.getHeader("Referer")) . Suponiendo que no suceda nada más de interés en el servidor como resultado de esta solicitud, ¿cómo puede ser un problema?

    
pregunta mwl 10.08.2017 - 03:18
fuente

3 respuestas

3

Estás creando una vulnerabilidad de redireccionamiento abierta pero no hay un defecto de XSS. Sin embargo, no puedo pensar en un caso de uso legítimo para emitir un redireccionamiento a la página de referencia en primer lugar. Como mínimo, te arriesgas a crear un bucle de redireccionamiento.

Tenga en cuenta que en otros contextos, puede ser peligroso permitir que las URL controladas por el usuario, especialmente porque un atacante puede aprovechar los pseudo esquemas como data: y javascript: para lograr XSS. Por ejemplo, la impresión <a href="[referrer]">Click me</a> es vulnerable incluso si se escapan las comillas y los corchetes.

Pero no te arriesgas a que un pseudo esquema termine en tu encabezado Referer porque los navegadores nunca los envían. Además, un encabezado como Location: javascript:alert(1) se considera inválido y no tiene efecto en ningún navegador principal.

MDN también sugiere ese comportamiento pero es menos detallado:

  

Los navegadores no envían un encabezado Referer si:

     

  • el recurso de referencia es un "archivo" local o "URI de datos",

    •   

  • se utiliza una solicitud HTTP no segura y la página de referencia se recibió con un protocolo seguro (HTTPS).

    •   

(Source)

    
respondido por el Arminius 10.08.2017 - 04:51
fuente
0

Los encabezados de referencia HTTP se pueden falsificar. Preguntó si era inseguro, pero luego excluyó uno de los principales puntos vulnerables que lo haría inseguro, por lo que no tengo claro exactamente lo que le gustaría saber, pero a mi entender, la respuesta a corto plazo a su pregunta es sí. Este enlace también está relacionado con su respuesta, aunque no estoy seguro de cómo la aplicación que se codifica en java figura en la ecuación cuando la compara con una aplicación web enlace

    
respondido por el Anonymous 10.08.2017 - 03:43
fuente
0

La única vulnerabilidad será una redirección automática, que tendrá un impacto muy bajo.

Tienes razón, no puedes falsificar un referer con javascript o Ajax, el navegador sobrescribirá el cambio. Por lo tanto, no es posible abrir la redirección de una víctima a otro sitio web.

    
respondido por el Florian 10.08.2017 - 04:22
fuente

Lea otras preguntas en las etiquetas

¿Las mejores prácticas para proteger contraseñas de DB para múltiples aplicaciones web? ¿POR QUÉ la represión de VPN por parte de China, Rusia, etc., cuando es posible el análisis del tráfico? [cerrado]