¿Debo rechazar URLs más largas de lo esperado?

Question

Estoy desarrollando una aplicación y tengo URL en el formato www.example.com/some_url/some_parameter/some_keyword. Sé por diseño que hay una longitud máxima que estas URL tendrán (y aún serán válidas). ¿Debo validar la longitud de la URL con cada solicitud para protegerme contra los ataques de desbordamiento/inyección de buffer? Creo que este es un sí obvio, pero no soy un experto en seguridad, así que quizás me esté perdiendo algo.

Answer 1

Si no está esperando esa entrada, rechace.

Siempre debe validar sus entradas, y ciertamente descartar cualquier cosa fuera del rango esperado. Si ya sabe que su URL honestamente no será más allá de cierta duración, rechazarla antes de que llegue a la aplicación parece prudente.

Answer 2

¿cómo estás tan seguro de que todos URL mayor que N no es válido? Si puede estar seguro, no debería doler limitarlo solo como un control de cordura, pero no deje que esto lo engañe al pensar que ha impedido una clase de exploit.

Answer 3

Creo que esto puede darte un poco de seguridad y puede ahorrarte un poco de ancho de banda si la gente te envía locas URLs largas, pero en gran medida también debes validar tus datos en la aplicación real. Múltiples niveles de seguridad generalmente son mejores, pero no cometa el error de pensar que, debido a que tiene una protección (débil) al principio, no tendrá problemas con el resto.

Answer 4

Yo diría que no. Es solo seguridad falsa. Simplemente programe bien y verifique sus solicitudes de cosas malas. Debería ser suficiente.

Además, no es a prueba de futuro.

Answer 5

Sí. Si es demasiado largo y está seguro, entonces bórrelo lo antes posible. Si puede, rechazarlo antes de que llegue a su aplicación (por ejemplo, IISLockdown lo hará).

Sin embargo, se debe tener en cuenta la codificación de los caracteres.

Answer 6

Mejor que verificar la longitud, creo que deberías consultar el contenido. Nunca se sabe cómo va a usar su esquema de URL en el futuro, pero siempre puede desinfectar sus entradas. Para poner algo muy complejo muy simple: No confíes en los datos proporcionados por el usuario. No lo coloque directamente en las consultas de DB, no lo evalúe, no dé nada por sentado.

Answer 7

Si sabe que las URL válidas no pueden superar los N bytes, entonces parece una buena forma de rechazar rápidamente los intentos de creación de scripts entre sitios sin demasiado esfuerzo.

Answer 8

Lo único que puedo ver que podría causar problemas es que, aunque hoy su URL nunca superará N, no puede garantizar que ese no sea el caso para siempre. Y en un año, cuando vuelves a hacer una edición para permitir que una url tenga una longitud N + y, puedes olvidarte de modificar el código de rechazo de la url.

Siempre será mejor que verifique los parámetros de URL antes de usarlos.

Answer 9

Es mejor validar lo que es en la solicitud que validar la longitud de la URL.

Sus necesidades pueden cambiar en el futuro, en ese momento deberá eliminar o cambiar la validación de longitud de URL, posiblemente introduciendo errores.

Si termina como una vulnerabilidad de seguridad comprobada, puede implementarlo.

Answer 10

La defensa en profundidad es un buen principio. Pero las medidas de seguridad falsas son un mal principio. La diferencia depende de muchos detalles.

Si está realmente seguro de que cualquier URL sobre N no es válida, entonces también puede rechazarla. Pero si es cierto, y si el resto de la validación de su entrada es correcta, se rechazará más tarde de todos modos. De modo que todo lo que hace este control es potencialmente, tal vez, mitigar el daño causado por algún otro error en su código. A menudo es mejor dedicar su tiempo a pensar cómo evitar esos errores, que pensar en lo que N podría ser.

Si comprueba la longitud, es mejor no confiar en este límite de longitud en otro lugar de su código. Hacer eso empareja las diferentes verificaciones más estrechamente, y hace que sea más difícil cambiar el límite en la próxima versión, si cambia las especificaciones y necesita aceptar URL más largas. Por ejemplo, si el límite de longitud se convierte en una excusa para colocar las URL en la pila sin el cuidado y la atención debidos, entonces es posible que esté preparando a alguien para una caída.

Answer 11

Ok, supongamos que existe una N tal. Como señaló onebyone, una URL mal formada que tenga más de N caracteres será rechazada por otra validación de entrada de todos modos. Sin embargo, en mi opinión, esto abre una nueva situación en la que pensar:

Al usar esta constante, puede validar su otra validación. Sin embargo, si las otras validaciones no han podido detectar una determinada URL como no válida, la URL tiene más de N caracteres, entonces esta URL desencadena un error y debe registrarse (y quizás toda la aplicación se cierre, ya que podrían crear un URL inválida que es lo suficientemente corta).

Answer 12

Safari, Internet Explorer y Firefox tienen diferentes longitudes máximas que acepta.

Yo voto por el más corto de los tres.

http://www.boutell.com/newfaq/misc/urllength.html

sacado de enlace -

"Microsoft Internet Explorer (Navegador) - 2083 caracteres

Firefox (navegador) - Después de 65.536 caracteres, la barra de direcciones no muestra la URL en Windows Firefox 1.5.x. Sin embargo, las URL más largas funcionarán. Dejé de probar después de 100.000 caracteres.

Safari (Navegador) - Al menos 80,000 caracteres funcionarán ".

Answer 13

Oh mi, muchas respuestas, muchos puntos buenos, tan dispersos, así que déjame intentar consolidar todo esto. tl; dr imo, este es un nivel demasiado bajo como para preocuparse por el código de la capa de aplicación.

Sí, la URL podría ser de cualquiera longitud, pero en la práctica los navegadores tienen un límite. Por supuesto, eso solo lo protege de los ataques basados ​​en el navegador por parte de personas dispuestas a limitarse a esos vectores, por lo que necesita alguna forma de manejar los intentos de ataque activo.

Bueno, puede proteger contra desbordamientos de búfer. Bueno, solo si estás trabajando a un nivel bajo y sin pensar en esas preocupaciones. La mayoría de los idiomas en estos días soportan cadenas bastante bien y no les permitirán desbordarse.Si estuvieras lidiando con un sistema de muy bajo nivel, realmente leyendo los datos como bytes y poniéndolos en un tipo de 'cadena', entonces seguro, deberías tener alguna forma de detectar y manejar esto, pero no es tan difícil asignar memoria, y transfiera cantidades conocidas a la vez, solo haga un seguimiento de la cantidad de memoria que guarda. Francamente, si se trata de ese nivel bajo, realmente debería usar algo más.

Bien, ¿qué tal si solo rechazamos en función de la longitud de la cadena? La principal desventaja de esto es la posibilidad de una falsa sensación de seguridad. Es decir, algunas áreas del código pueden ser "descuidadas" y ser vulnerables a los mismos exploits que intenta evitar. Es evidente que debe tener cuidado para asegurarse de que este límite 'global' en realidad sea suficiente, pero teniendo en cuenta su formato URI, es posible que pueda hacer que esas 'partes' informen cuál es su longitud máxima y la verificación central de longitud (para ambos toda la cadena y sus componentes); al menos de esta manera, si una parte necesita permitir una cadena más larga, es más fácil manejar el cambio.

Esto, por supuesto, tiene algunas ventajas, por un lado, es muy rápido para poder comparar la longitud de un hilo y rechazar la solicitud de inmediato ... pero no se olvide de ser un "buen comportamiento" 'sitio debe devolver una respuesta adecuada explicando por qué el servidor está rechazando esto. Sin embargo, en la práctica, ¿de verdad crees que vas a tener que manejar muchos de estos tipos de URL "incorrectos"? Seguramente estarían equivocados de muchas otras maneras.

Por alguna razón, no desea decir el idioma que está utilizando. Los lenguajes de alto nivel como Java o Python tienen algunas bibliotecas muy buenas para tratar con 'elementos web'. Java le permitirá especificar patrones para el URI, incluido el uso de expresiones regulares para ese patrón, por lo que si desea un nombre en la URL, podría tener algo como @Path("/person/(.{0..100}") para limitar el parámetro a 100 caracteres. Me sorprendería si los gustos de Ruby o Python no tienen equivalente, les gusta promocionarse como buenos lenguajes 'webby'.

Finalmente, independientemente de la longitud, hay muchas cosas que deberá validar, no solo la longitud. Tener que preocuparse por la longitud del URI que causa un desbordamiento del búfer es algo de muy bajo nivel, y tendría que ser muy genérico, es decir, necesitar manejar cualquier solicitud, incluso una con URI de 1GB potencialmente; Nota: dije 'manejar' no 'aceptarlo y pasarlo a la capa de aplicación', podría rechazarlo en ese nivel bajo, y también podría desencadenar eventos del sistema.