¿Pueden las solicitudes GET secretas ser forzadas brutalmente? [duplicar]

Básicamente, está preguntando si es seguro pasar parámetros secretos en una solicitud GET. Esto se clasifica realmente como una vulnerabilidad . No es factible forzar la fuerza bruta en una cadena pseudoaleatoria suficientemente larga, suponiendo que el servidor simplemente devuelva una respuesta 404 estática siempre que se especifique una ruta no válida, pero hay muchos otros problemas de seguridad en la práctica que hacen de esta una técnica peligrosa:

• El software de registro a menudo registra las solicitudes GET en texto sin formato, pero no en POST.

• El uso de GET hace que CSRF trivial ^* al procesar contenido activo.

• Los encabezados de los remitentes pueden filtrar valores secretos a otros sitios web.

• El historial del navegador conservará los secretos pasados en las solicitudes GET.

Tu segundo ejemplo tiene /admin/ en él. Esto me implica que el conocimiento de esta ruta solo sería suficiente para autenticarse en el servidor en un contexto de administrador. Esto es muy inseguro y no se debe hacer más que /?password=hunter2 , un gran paso de seguridad web faux pas .

En su lugar, los secretos deben enviarse en una solicitud POST. Si esto no es posible o si su modelo de amenaza es exclusivamente para evitar la fuerza bruta de la URL (por ejemplo, los enlaces de restablecimiento de contraseña que se invalidan inmediatamente después de su uso), entonces debería ser seguro si se hace con cuidado. No tengo conocimiento de ningún ataque de canal lateral que proporcione un método para obtener la cadena más rápido que la fuerza bruta.

_{* Evitar las solicitudes GET parametrizadas no evita los ataques CSRF, que es un malentendido común ya que hay varias formas de abusar de forma similar de POST (formas falsas, etc.), pero pasar secretos en GET hace que CSRF sea más fácil.}

Este es un enfoque común para compartir cosas públicas restringidas a aquellos que conocen la URL. Un ejemplo es Google Docs:

Lasegundaopción,"Cualquier persona con el enlace", crea un enlace similar al suyo. Lo mismo para Google Photos, Dropbox, ...

• La ventaja es que la difusión del contenido está un tanto limitada.
• El inconveniente es que este algo depende de con quién compartes el enlace, dónde se publica, etc.

Una cosa que debe considerar es la posibilidad de invalidarla fácilmente (cambiando / regenerando el enlace a sus datos)

Mala idea. Varias veces he visto una URL "secreta" obteniendo rápidamente resultados de búsqueda en el buscador, y luego se pueden encontrar en la búsqueda web. Una vez que vi a alguien configurar una copia de un sitio web de buena reputación en una subcarpeta de su dominio, compártelo con una persona uno , y pronto se le envió un aviso por correo electrónico advirtiéndole que su dominio podría haber sido comprometido por fines de phishing.

¿Cómo sucedió esto? En este último caso, el navegador web tenía una función anti-phishing integrada que enviaba las URL visitadas a los servicios de detección de fraudes. En otros casos, tal vez el navegador estaba recopilando datos de navegación y enviándolos a un motor de búsqueda para recopilar los hábitos de los usuarios.

Si haces esto , asegúrate de que tu archivo robots.txt (o encabezados / metaetiquetas) esté configurado para que los motores de búsqueda no indexen el contenido.

Internet es una forma maravillosa de acercar al mundo, pero desafortunadamente les da a todos acceso potencialmente permanente a cualquier cosa que estornude.

  

Si la parte secreta del camino es bastante larga, [...] será difícil de adivinar o forzarla bruscamente.

Sí. Un atacante tendría que adivinar todo para descubrirlo. Dado que hay muchas posibilidades, llevaría un tiempo no viable.

  

¿Cuáles son los problemas con este enfoque en general?

El problema con esto es que las URL no se consideran secretas, por lo que se almacenarán en el navegador, en los registros y por cualquier proxy intermedio. De esa manera, su URL "secreta" puede estar expuesta.

  

El uso de GET hace que CSRF sea trivial al procesar contenido activo.

No. En un ataque CSRF, el atacante falsifica una solicitud específica. Cuando se usa un secreto en la URL, el atacante ni siquiera conoce la URL correcta para falsificar la solicitud. Esto significa que CSRF es imposible siempre que la URL sea secreta.

Como han dicho otros, esto no es una buena idea. Dichos enlaces "secretos" que se usan para cancelar la suscripción o para fines de una sola vez similares suelen ser relativamente de corta duración y no tienen uso una vez que se han utilizado una vez.

Mi pensamiento inicial cuando leí esta pregunta fue que la URL no permanecería en secreto por mucho tiempo. Pensé que quizás Chrome (o cualquier otro navegador web moderno) usaría los datos de la línea de dirección para inicializar un rastreo. Resulta que no lo hacen . Sin embargo, los investigadores descubrieron que los complementos aún podrían desencadenar un rastreo:

  

Los resultados son bastante simples: Googlebot nunca visitó ninguna de las páginas en la prueba.

     

Resulta que dos personas en la prueba en realidad no deshabilitaron sus extensiones, y esto resultó en visitas desde Open Site Explorer (alguien tenía el Mozbar instalado y habilitado) y Yandex (debido a una persona diferente, aunque yo No tengo claro qué extensión tenían instalada y habilitada).

Esto significa que una vez que se usa un enlace, puede ser comprometido por las extensiones del navegador. Y entonces no hay necesidad de que los brutos obliguen nada.

¿Cuál es el propósito de hacer estos enlaces? ¿Qué estás tratando de lograr, OP? Estoy seguro de que hay otras formas de llegar ...

Sería difícil de adivinar / fuerza bruta, pero otras formas de obtener las rutas pueden ser posibles

Por ejemplo, la URL puede ser indexada por servicios como Google, Bing, etc. Esto haría que su URL "secreta" aparezca cuando un usuario busca en su página en Google. Se puede resolver configurando el archivo robots.txt , pero recuerde que los indexadores pueden ignorarlo

Los enlaces en la aplicación pueden redirigir a la ruta oculta

Además, las máquinas en la misma red que el usuario que accede a la página "secreta" o el servidor web pueden ver la URL, también cada proxy intermediario y el ISP del usuario (o VPN si usa uno)

Finalmente, la url puede persistir en el caché y / o historial del navegador y en los registros en el servidor web y los servidores proxy

  

¿Pueden las solicitudes GET secretas ser forzadas brutalmente?

Sí, pueden. Tanto como cualquier tipo de solicitud sin las medidas de seguridad adecuadas.

  

Si la parte secreta de la ruta es bastante larga, ¿puedo suponer que es seguro tener una página o área secreta y será difícil de adivinar o forzarla?

No, no es seguro tener una página o área secreta. Sí, será difícil de adivinar o fuerza bruta.

  

¿Cuáles son los problemas con este enfoque en general?

A diferencia de las solicitudes POST, las solicitudes GET se pueden encontrar fácilmente en el historial del navegador web.

Creo que será mejor implementar una contraseña automática o manual (para que usted decida quién puede acceder a la página) OTP One Time Password para enviar por correo electrónico.

En un escenario manual:
 - usted recibe la solicitud de [email protected]
 - Usted otorga acceso a [email protected]
 - el script crea el enlace con la OTP
 - El enlace se enviará a [email protected]
 - cuando el usuario [email protected] visitará la página, se marcará el OPT y nadie más podrá reutilizar ese enlace

Por supuesto, este sistema requiere una base de datos donde almacenar el correo electrónico autorizado, OPT y campo de marca