Preocupaciones de seguridad de la URL relativa proporcionada por el usuario en la ubicación: encabezado

Question

Preocupaciones de seguridad de la URL relativa proporcionada por el usuario en la ubicación: encabezado

#1 de Sjoerd (1 votos)
#2 de CBHacking (1 votos)
#3 de tim (1 votos)

1

Esto es similar a esta pregunta , pero un poco más específico.

TL; DR; ¿Existe algún problema de seguridad con el hecho de permitir que las URL relativas proporcionadas por el usuario se encuentren en el encabezado Location: en la redirección?

Background:

Estoy escribiendo un pequeño proxy para usar delante de CouchDB . Para autenticarse en la API de CouchDB, se debe enviar un POST al punto final /_session como se describe aquí .

Este punto final toma un parámetro de consulta opcional, next , que, cuando está presente, provocará que una solicitud de autenticación exitosa responda con 302 y un red co% Location: , en lugar de un simple 200 .

Ahora CouchDB tiene lo que me parece una implementación insegura de esto. El valor next simplemente se agrega al nombre de host del servidor (¡sin barra diagonal!). Así que una solicitud como esta:

POST /_session?next=foobar

Obtendrá una respuesta que incluye:

Location: http://someserver.comfoobar

Creo que esto es claramente malo, pero al menos el daño solo se limita a solicitudes autenticadas, por lo que un phisher al azar probablemente no pueda hacer mucho con él. Pero todavía me hace sentir un poco incómodo.

Por lo tanto, me parece que es necesario hacer alguna validación. Como mínimo, debe indicarse / en la URL proporcionada por el usuario. Pero estoy pensando que un enfoque más simple podría ser simplemente validar que la URL proporcionada por el usuario es relativa, y luego responder solo con eso.

Así que para mi ejemplo:

POST /_session?next=foobar

Respondería con:

Location: /foobar

¿Es este un enfoque seguro?

http url-redirection

pregunta Flimzy 12.03.2017 - 12:35

fuente

3 respuestas

Lea otras preguntas en las etiquetas http url-redirection

PCI DSS 3.2 SAQ A y SAQ A-EP - 2 tiendas web diferentes ¿Cuál es el efecto en un dominio cuando el servidor de nombres secundario está comprometido?

score 1 · Answer 1

Dejar que su sitio redirija a otra URL determinada por la entrada del usuario solo se considera una vulnerabilidad si Se puede utilizar para redirigir al usuario fuera del sitio.

Las redirecciones no seguras se pueden usar en intentos de phishing: en un correo electrónico de suplantación de identidad (phishing), un enlace a https://realbank.com/?next=http://evil.attacker tendrá una mayor posibilidad de ser seguido que un enlace a http://evil.attacker .

Además, se pueden usar redirecciones no seguras para omitir CSP. Si un sitio tiene una regla CSP que dice que solo puede cargar Javascript desde ese host, la carga de una página que redirecciona al script en otro host todavía funcionará.

Nuevamente, estas vulnerabilidades asumen que puedes redireccionar fuera del sitio. Si limita las redirecciones a su propio sitio, generalmente es seguro.

score 1 · Answer 2

Hay otros peligros de este enfoque. Realmente suena como que el código CouchDB es terriblemente inseguro (lo que no me sorprende en lo más mínimo; nunca he visto una base de datos NoSQL con seguridad tolerable, excepto en el caso de DynamoDB).

Además del peligro que ya ha reconocido (redirigir a otro dominio al abusar de la falta de un carácter de ruta de acceso / ), también existe un riesgo de inyección de encabezado. Si el servidor simplemente toma el parámetro de consulta y lo agrega sin ningún tipo de validación, entonces un atacante podría inyectar nuevas líneas seguidas de encabezados HTTP adicionales, o incluso una línea en blanco seguida de una respuesta HTTP (como un documento HTML). El impacto de estas cosas dependería del cliente; por ejemplo, una respuesta con dos encabezados Location: no es compatible, pero la mayoría de los clientes seguiría uno de ellos, y si es el segundo, entonces tu atacante tiene un redireccionamiento totalmente arbitrario, pero puedo pensar en algunas formas en las que es casi seguro que se pueden explotar.

La solución estándar para redireccionamientos abiertos es, si es posible, crear una tabla de búsqueda de destinos y hacer que la solicitud especifique el índice de esa tabla. Eso solo funciona si tiene un número finito (y al menos algo predecible) de posibles destinos, pero es fácil de implementar y no es vulnerable al tipo de chanchullos que estamos hablando aquí. Tampoco es necesario que sea una tabla de búsqueda real; cosas como ?next=userprofile,privacysettings o similar (para especificar que el usuario debe ser redirigido a la página de configuración de privacidad de su perfil) funcionan tan bien como las búsquedas indexadas, siempre que valide las cadenas proporcionadas y no haga nada tonto cuando se encuentre con otras no reconocidas.

score 1 · Answer 3

Abrir redireccionamiento

¿De dónde proviene originalmente el valor next ? Las solicitudes POST generalmente no son vulnerables a la redirección abierta.

Pero suponiendo que sea controlable por una solicitud GET anterior:

Su enfoque resuelve un problema. Antes, un atacante podía inyectar .evil.com y, por lo tanto, ser redirigido a someserver.com.evil.com , que está bajo el control del atacante. Incluso si . no está permitido, si la url es, por ejemplo, someserver.co , un atacante podría inyectar m y redirigirse a someserver.com .

Sin embargo, tu solución introduce un nuevo problema. Si un atacante inyecta /evil.com , será redirigido a //evil.com , que es una URL relativa al protocolo.

Otros problemas

Aparte de los problemas de redireccionamiento abiertos, ser capaz de redirigir internamente no es demasiado beneficioso para un atacante. Si la autenticación está abierta a CSRF, puede proporcionar algún beneficio en los ataques CSRF de inicio de sesión (por ejemplo, para redirigir a la víctima a una página que contiene algo de carga XSS). También puede ser posible eludir la protección CSRF basada en la comprobación de referencia para las solicitudes GET.