Implicación de la inyección de URL en un servicio de acortamiento de URL

1

EDIT Ha habido upvotes retraídos o downvotes debido a, creo, un grave malentendido de mi pregunta. A continuación, no me preocupa la URL que conduce a un sitio que contiene malware o exploits (no es que no sea una preocupación: simplemente no es de lo que trata esta pregunta): Me preocupa la inyección en la cadena de la URL. Lo que no quiero es que un pirata sea capaz de esquivar la seguridad de "cualquier marco" y poder inyectar, por ejemplo, código JavaScript en una URL que luego mostraría a otros usuarios. En otras palabras: estoy buscando una medida adicional para reducir el riesgo de que se ejecute JavaScript fraudulento como si viniera de mi aplicación web.

Con el fin de fortalecer una aplicación web, estoy pensando en no mostrar nunca las direcciones URL ingresadas por los usuarios y aún así permitirles ingresar direcciones URL, pero siempre usar un servicio de acortador de URL. Esto no pretende reemplazar otras buenas prácticas de seguridad, sino que debe utilizarse además de otras prácticas de seguridad.

Aquí hay un escenario muy simple:

  1. lo único que un usuario puede ingresar al sitio web es una única URL
  2. la URL enviada por el usuario se envía a un servicio de acortador de URL externo
  3. la URL abreviada se sirve desde mi sitio web

Si durante el primer paso consideramos que mi analizador no tiene fallas al analizar los parámetros POST enviados por el usuario, ¿qué puede fallar más adelante si hay un exploit exitoso en la URL que afectaría el servicio de acortamiento de URL?

Básicamente, mi idea sería servir, digamos, un codificado:

http://bit.ly/

seguido de una regla muy estricta que dice algo como: "inserta a lo sumo 9 caracteres y estos caracteres deben ser alfanuméricos" .

Lo haría para simplificar la regla sobre qué caracteres puede y no puede enviar el usuario: la salida de una URL bit.ly es mucho más sencilla de lo que permiten las URL legítimas ( Utilicé bit.ly como ejemplo, cualquier servicio de acortador de URL que utilice un subconjunto de caracteres muy estricto en las URL acortadas que devuelve haría).

Entonces, ¿cuál sería el peor de los casos si consideramos que el usuario deshonesto no puede explotar mi sitio web pero aún así puede explotar una falla en el servicio de acortamiento de URL?

Lo que me gustaría averiguar mejor es lo que significa cuando se trata de la misma política de origen / XSS y CSRF y otros tipos de explotaciones.

Y, supongo, mi pregunta podría resumirse de la siguiente manera: "Si la seguridad se realiza correctamente en mi sitio web, ¿la vulnerabilidad de XSS que afecta al servicio de acortamiento de URL seguirá siendo mi preocupación o no?"

La idea general sería agregar defensa en profundidad y considerar que el servicio de acortamiento de URL probablemente sepa cómo defenderse acerca de las inyecciones de URL.

    
pregunta Cedric Martin 09.04.2013 - 15:47
fuente

3 respuestas

2

Esta es una forma ineficiente de hacer las cosas. La única seguridad que obtendría de un servicio de acortamiento de URL externo es que solo acortarán las URLS válidas, no el código javascript, etc. Sin embargo, aún confía en su seguridad de que de hecho acortará la URL proporcionada por el usuario, aumentará el 100% del tiempo y tendrá 0 vulnerabilidades de seguridad. Por qué no escribe su propio pequeño analizador que verifica las URL. Algo como esto: enlace

Algunas cosas que puedes buscar:

1-Los usuarios han ingresado una URL que comienza con http: // y no un código de script java aleatorio.

2- También puede utilizar la API de navegación segura de Google para comprobar si hay malware en la URL. enlace , esto es muy útil ya que la API de Google safebrowsing devolverá malware para malware y 200 para URLS válidas, para cualquier otra cosa. como una URL no válida, la API de Google no devolverá nada.

    
respondido por el marcwho 09.04.2013 - 17:29
fuente
1

Depende de lo que haga el servicio de acortador de URL. Es de suponer que toma una entrada (la URL completa) y produce una salida (la URL más pequeña), almacenando la asignación de la URL más pequeña a la URL completa en la base de datos. También puede almacenar un hash de la URL más pequeña para que sea más eficiente y agilice las búsquedas. Solo estoy especulando porque la forma en que funcionaría realmente dependería de su implementación. Sin embargo, en cuanto a los componentes, es probable que el SQL utilice una base de datos para almacenar las asignaciones. Además, el servicio en sí podría tener acceso a esa base de datos para garantizar que no se produzcan asignaciones duplicadas. Sería posible producir una inyección de SQL si el servicio de URL utiliza directamente la base de datos y lo hace pobremente. La inyección de SQL se puede prevenir mediante consultas parametrizadas.

En segundo lugar, su servicio de acortamiento de URL sería vulnerable a los ataques de DOS donde se realizan más solicitudes de las que puede manejar. Esto se aplica especialmente si está mal escrito y no puede generar rápidamente URL únicas. Sin embargo, no me preocuparía demasiado por eso, los ataques DDoS se pueden lanzar contra cualquiera.

Creo que editó su publicación para indicar que se trata de un servicio de acortador externo. Esto cambia las cosas porque significa que no es su base de datos la que es vulnerable a la inyección de SQL, sino la de otra persona. Realmente, no hay mucho riesgo involucrado con este tipo de servicio. Si alguien puede inyectar la base de datos o hackearla, puede hacer que los usuarios sean redirigidos a la URL incorrecta, una que hayan configurado con código malicioso. Este servicio externo también podría ser un peligro para usted porque puede devolver cualquier URL antigua que desee. No hay nada que los obligue a implementar el mapeo de buena fe. Pueden enviarle fácilmente un 99% de URL buenas y un 1% de URL maliciosas a sitios maliciosos que el autor del servicio de acortamiento ha configurado. O el servicio de acortamiento en sí mismo podría verse comprometido, lo que afectará indirectamente a su sitio web. Básicamente, el servicio de acortamiento de URL que se aloja externamente le ahorra muchos dolores de cabeza porque tiene menos ataques de los que preocuparse. Pero el ataque más serio si el servicio externo se ve comprometido es que sus usuarios recibirán URL incorrectas o maliciosas. Dependiendo de cómo se autentique el servicio web para recuperar estas asignaciones de URL del servicio de URL, tiene la posibilidad de que se ejecute un ataque MITM para servirle también las URL falsas. Y su servicio web podría potencialmente ser explotado para hackear su servidor también. Una vez más, todas estas cosas dependen de la implementación del servicio de acortador de URL y de los servicios web y la autenticación ... hay muchos factores sobre los que no nos ha proporcionado información.

    
respondido por el KyleM 09.04.2013 - 16:39
fuente
0

¿Cómo sabría su servidor si la URL proviene del servicio de acortamiento o no? ¿No podría el atacante simplemente actuar como si fuera el servicio de acortamiento de URL y enviar información de una manera que pudiera romper su sistema?

No veo en qué se diferencia esto de aceptar las URL, pero luego hago una Reescritura de URL para garantizar que no se muestre la información que pasaron en la URL, a menos que me esté faltando algo sobre el escenario propuesto.

Si simplemente está utilizando el servicio de Acortamiento de URL para proporcionar tokens aleatorios para páginas particulares de su sitio, entonces ¿por qué no simplemente almacenar un marcador internamente en su base de datos? De esta manera usted controla la entrada que se utiliza para evitar el abuso. Incluso si está llamando directamente al servicio de acortamiento, ¿qué evitaría que un usuario malintencionado realice su propia URL corta para su dominio? (A menos que tenga un servicio de acortamiento que solo devolverá los resultados de su cuenta).

    
respondido por el AJ Henderson 09.04.2013 - 17:31
fuente

Lea otras preguntas en las etiquetas