¿Cómo validar correctamente los redireccionamientos HTTP?

6

Estoy leyendo la Lista de verificación de prácticas de codificación seguras de OWASP y en su sección "Validación de entrada" tienen un elemento que dice:

  

Valide los datos de las redirecciones (un atacante puede enviar contenido malintencionado directamente al destino de la redirección, evitando así la lógica de la aplicación y cualquier validación realizada antes de la redirección).

¡Estoy haciendo un total vacío sobre lo que significan aquí!

¿Están diciendo que un atacante podría poner una solicitud de redireccionamiento dentro de una solicitud HTTP y simplemente hacer que el servidor web ejecute la redirección, omitiendo la URL normal a la que iría la solicitud (y cualquier validación del lado del servidor que la acompañe)? Si es así, ¿qué aspecto tendría una redirección integrada y cómo puedo detectarlo? ¿Qué significa validar contra esto (como dicen)?

Y, si estoy totalmente equivocado en mi interpretación, ¿de qué están hablando? ¿Puede alguien darme un ejemplo concreto? Gracias de antemano!

    
pregunta zharvey 09.08.2012 - 03:32
fuente

2 respuestas

4

Una práctica común después de una publicación de formulario es redirigir a un usuario a la página de éxito:

POST /my-form HTTP/1.1
Host: www.myhost.com


HTTP/1.1 302 Moved Temporarily
Location: https://www.myhost.com/form-success.html?message=%3Cb%3ESuccess!%3C/b%3E

En este ejemplo, el usuario se redirige a la página form-success.html, con el mensaje de:

<b>Success!</b> 

Tenemos javascript en form-success.html que toma el mensaje y lo agrega al documento. Sin sanear la respuesta, te abres a un ataque XSS .

Debido a que la persona que codificaba este sitio web ficticio asumió que solo se accedería a través del formulario y luego de la redirección, no colocaron las comprobaciones adecuadas en el parámetro del mensaje para evitar que una persona maliciosa sustituya una etiqueta de script para el mensaje de éxito benigno.

Debería siempre validar / eliminar cualquier contenido que provenga del navegador, en los parámetros de URL o en las publicaciones de formularios, independientemente de si se produce o no después de una redirección. Trata a todos los comentarios con sospecha y recorrerás un largo camino para protegerte de este estilo de ataque.

    
respondido por el alexwen 09.08.2012 - 05:28
fuente
5

Buena respuesta de alexwen, aunque creo que su respuesta es más bien un problema de desinfección de parámetros genéricos, no exactamente a lo que OWASP se refiere. Creo que OWASP puede estar refiriéndose a cualquiera de los siguientes conceptos.

Revalidación de datos de redireccionamiento

OWASP está hablando de un tipo diferente de esquema en el que una URL realiza algún proceso (es decir, la validación) y luego redirige a otra URL para completar. Por ejemplo, imagine dos URL, una es / checkout y la otra es / ship. La URL de / checkout verifica la información de la tarjeta de crédito, verifica que las partes estén en stock, etc. luego redirige a / ship. La URL / ship realmente crea un ticket de trabajo para extraer las partes y enviarlas.

Si el atacante conoce esta configuración, puede enviar POSTALES los datos de envío relevantes directamente a la URL de / ship, omitiendo toda la validación realizada en la primera URL y obteniendo algunos productos de forma gratuita.

Personalmente nunca he visto un esquema de validación tan tonto, pero parece ser a lo que OWASP se refiere.

Post-redirect-Get Pattern

El patrón de PRG significa redirigir a una solicitud GET después de procesar con éxito un POST. Esto se usa para evitar el horrendo problema de usabilidad de un usuario que hace clic en el botón de retroceso en un navegador y el navegador le pregunta al usuario una pregunta poco clara acerca de si debe o no "volver a publicar los datos del formulario". (He visto este viaje a tantos usuarios que ni siquiera es divertido).

Nunca he visto esto usado de tal manera que sea vulnerable a los ataques, pero en teoría, un esquema de autenticación deficiente podría usar PRG para procesar las credenciales de autenticación, luego redirigir a una página "solo para miembros" o algo estúpido como ese. Nuevamente, nunca lo he visto personalmente en la naturaleza, así que tampoco estoy 100% seguro de que OWASP esté hablando.

Redirección ciega

No estoy seguro de que esto sea de lo que habla OWASP, pero en realidad es una vulnerabilidad común. A diferencia de las dos vulnerabilidades anteriores que describí, en realidad lo he visto muchas veces. Este error común es que la URL a la que se redirecciona se especifica en la consulta de la URL original y no se valida, por ejemplo:

http://my.badsite.com/redirect.php?destination=http://google.com

Si redirect.php redirige incondicionalmente a cualquier URL que se pase (por ejemplo, en PHP, encabezado ("Ubicación: $ ubicación")), entonces un atacante puede crear una URL que parezca segura pero que en realidad conduzca a un sitio peligroso. Por ejemplo, si la secuencia de comandos de redirección oculta está en enlace , el atacante envía a la víctima un enlace como enlace y un usuario ingenuo mira el enlace y piensa que va al sitio web de NYT. (Dependiendo de la naturaleza exacta de la secuencia de comandos, el atacante podría codificar en parte o toda la URL de destino para ofuscarla).

Una secuencia de comandos de redireccionamiento debe inspeccionar la URL de destino para asegurarse de que sea apropiada, probablemente a través de algún tipo de lista blanca.

    
respondido por el Mark E. Haase 09.08.2012 - 18:17
fuente

Lea otras preguntas en las etiquetas