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.