¿Cuáles son algunos de los posibles ataques que se podrían realizar en un sitio web que no administra la codificación url correctamente?

Question

¿Cuáles son algunos de los posibles ataques que se podrían realizar en un sitio web que no administra la codificación url correctamente?

#1 de user166832 (3 votos)
#2 de regilero (2 votos)
#3 de Anders (0 votos)

2

Hace aproximadamente un mes estaba en medio de una de mis clases de "Aplicaciones distribuidas" y el profesor nos estaba explicando cómo "" "" "" "" autentificar correctamente a los usuarios en un servidor.

Para demostrar cómo evitar que los usuarios accedan a todos los archivos en un directorio determinado (es decir, con el nombre "privado"), el profesor nos mostró un código JSP que era similar al siguiente pseudocódigo:

String URI = uri.getRequest();
if (URI.contains("/private/") {
  if (userIsAuthenticated()) grantAccess();
  else redirectToLogInPage();
 }

Por supuesto, me di cuenta de lo que estaba mal allí y de lo que podría ser una falla de seguridad. Si un usuario solicita una URL como mysite.com/private%2Fmypage , el URI no contendría la cadena literal "/ private /" para que se le otorgue acceso al usuario.

Ayer recordé esa clase, así que, como tenía curiosidad, me di cuenta de que no solo todos mis proyectos web anteriores en Uni tenían esta vulnerabilidad, sino que incluso algunos sitios web de empresas serias también tienen este problema. Puede acceder a una gran cantidad de páginas donde no debería poder hacerlo (básicamente, páginas de perfil de usuario cuando no ha iniciado sesión), solo con el porcentaje de codificación de algún carácter en la URL.

Entonces, cuando me di cuenta de que hay muchas personas que no se preocupan demasiado por este tema, estoy un poco confundido. ¿No es un gran defecto? ¿Qué podrían ser algunos ataques que podrían hacerse aprovechando este problema? Simplemente me gustaría saber, desde un punto de vista teórico, si es posible, qué tan grave podría ser este problema para un sitio que no administra la codificación url correctamente.

P.S: Sé que una solución plausible podría ser también verificar si la URL solicitada está codificada en porcentaje y negarle el acceso. O incluso si quisiéramos ir más allá e implementar una solución más segura, podríamos usar un Centro de distribución de claves como Kerberos. Sin embargo, no entiendo por qué puedes encontrar sitios web serios con este defecto y no les parece un gran problema.

web-application url http encoding

pregunta Miquel Perez 17.01.2018 - 21:15

fuente

3 respuestas

Lea otras preguntas en las etiquetas web-application url http encoding

complejidad de la contraseña y políticas desde el punto de vista de los usuarios [duplicado] ¿Cómo puede un certificado SSL vencido hacer que el servidor y / o el cliente sean vulnerables a los ataques MITM? [duplicar]

score 3 · Answer 1

Lo que quiere lograr es imponer cierta seguridad a / private / y, de lo contrario, ofrecer contenido libremente. La página de inicio de sesión estará fuera de privado.

Los servidores que manejan la seguridad basada en rutas saben cómo manejar los escapes. Lo que buscan es llevar tanto el camino como el patrón a una forma "canónica". De esta manera, se aseguran de que comparen barra diagonal con barra diagonal y no con su escape de URL.

Por lo general, la seguridad declarativa supera la seguridad programada. Esto implica que la ruta de prueba se realiza en un solo lugar, fuera de la aplicación, en una biblioteca de terceros escrita teniendo en cuenta la seguridad. Lo más probable es que los que escribieron la biblioteca fueran conscientes del hecho de que una URL puede contener escapes. Otra ventaja de la seguridad declarativa es que no desordena tanto el código. No tendremos cosas como:

delete_entry() {
if (rights.check("delete"))
   actually_delete();
 else {
   log_failed_attempt();
   throw new SecurityException("Not allowed to delete, the attempt has been logged.");
 }
}

Un programador distraído puede olvidar la comprobación de una sola acción. Más bien, tenga un sistema de anotación de "acciones" que serán verificadas por el llamante. Si falta el controlador de seguridad, falla la llamada en tiempo de ejecución, esto significa que el programador ha olvidado "asegurar" la rutina. Las funciones "gratis para todos" tendrán una anotación @freeForAll.

En su caso, el servidor debe imponer que / private / solo se sirve si los visitantes tienen un token específico, que no pueden fabricarse ellos mismos. Por ejemplo, sería incorrecto buscar una cookie con el contenido "autenticado: verdadero", ya que los clientes pueden generar dicha cookie sin visitar el inicio de sesión.

score 2 · Answer 2

Como lo indica @Razvan_P, el componente de seguridad, si se basa en la ubicación, debe ser algo que sepa cómo manejar las ubicaciones :-).

Pero ese es efectivamente un problema muy actual (algo así como el truco reflejo para los jugadores de CTF). El 'dominio' de seguridad aquí es principalmente sin pasar por los filtros de seguridad . Todos los filtros basados en la ubicación están involucrados. Y puede encontrar problemas al respecto en muchos servidores HTTP (proxy inverso, balanceadores de carga), no solo aplicaciones. Porque para la mayoría de estos agentes, la seguridad no es la tarea principal.

Por ejemplo:

los administradores generalmente ignoran que usar reglas de reescritura con mod_rewrite en apache no es lo mismo para ubicaciones y argumentos de cadenas de consulta (el último no se descompone con URL antes de ejecutarse en reglas de reescritura). Y puede encontrar reglas de seguridad malas (demasiado simples) en las documentaciones en línea .
la codificación url se aplica solo en algunos caracteres por los navegadores, pero también PUEDE codificar cualquier carácter regular, es decir, usar %61 para a .
algunos caracteres siempre están urlencodificados por los navegadores, pero no todas las consultas provienen de navegadores, pueden ocurrir cosas extrañas cuando se usan caracteres prohibidos con bajo nivel de ascii, como el byte NULL o TAB (o retroceso, FormFeed, ...)

En términos de arquitectura de seguridad, se debe aplicar defensa en profundidad , y una aplicación no debe basarse en un filtrado anterior realizado solo por un servidor HTTP (como, su aplicación PHP debe aplicar las reglas de ACL, incluso si usaste una regla mod_rewrite en apache httpd).

Y para volver a tu primera pregunta, en el dominio de seguridad. Algunas preguntas relacionadas con los errores de sintaxis de ubicación y uri llevan a otros dominios, no solo a los filtros de seguridad que no se incluyen, como la inyección de crlf, el contrabando de HTTP o la contaminación de parámetros HTTP.

score 0 · Answer 3

¿Cómo solucionas esto? Como escribe Razvan P , debes compare la URL y el fragmento ( /private/ ) en la misma forma canónica. En la práctica, esto significa que debe decodificar la URL antes de compararla, de modo que %2F se convierta en / .

¿Qué tan malo es esto? Puede ser realmente malo. Básicamente significa que la información que se supone que es privada es pública. También puede significar que personas no autorizadas pueden modificar o eliminar información. Qué tan malo es esto depende de lo que está protegiendo, y va desde una vergüenza hasta una catástrofe.

¿Por qué es tan común esta vulnerabilidad, incluso en sitios grandes? Bueno, ¿por qué seguimos viendo a las personas ser víctimas de SQLi o XSS, a pesar de que se ha sabido durante décadas cómo enfrentarlo? ¿correctamente? Supongo que la seguridad es compleja, los humanos son falibles y el resto es historia.

¿Qué haces ahora? En primer lugar, deberías reconsiderar si buscar en otros sitios web es una buena idea. Dependiendo de la jurisdicción, tratar de evitar los filtros de seguridad de esa manera puede ser ilegal. En segundo lugar, debe considerar divulgación responsable para los sitios donde encontró la vulnerabilidad. Simplemente no lo hagas de una manera que te incrimine.