¿Es perjudicial permitir solicitudes http con cadenas de consulta muy largas en IIS?

2

Estoy desarrollando un sitio web con una función de búsqueda que podría generar solicitudes HTTP de caracteres muy largos (hasta 15,000). Sin embargo, IIS tiene un límite predeterminado de 2048 caracteres para las cadenas de consulta. Esto se puede cambiar fácilmente en un archivo web.config usando las configuraciones enumeradas a continuación.

system.web > httpRuntime > maxRequestLength
system.web > httpRuntime > maxUrlLength
system.webServer > security > requestFiltering > maxQueryString
system.webServer > security > requestFiltering > maxUrl

Mi pregunta es si hay algún problema de seguridad que deba tener en cuenta si permito cadenas de consulta muy largas en las solicitudes HTTP.

Actualización: Debería agregar algunos bits de información.

  • El sitio web solo estará disponible para usuarios pagos que hayan iniciado sesión en el sitio web.
  • La probabilidad de que alguien cree una búsqueda con más de 2048 caracteres en la URL es MUY escasa, pero teóricamente posible.
pregunta jessegavin 25.09.2012 - 00:13
fuente

2 respuestas

4

15,000 URL de caracteres no funcionarán muy bien en todos los navegadores: enlace

Suponiendo que ya sabe que, en una aplicación ASP.NET, un límite de 16,000 caracteres aumentará su vulnerabilidad a los ataques de agotamiento del búfer de la cola de la solicitud 8x. Ahora, 8x no es tan importante en comparación con los mejores ataques DoS que generalmente se abren en un sitio web ASP.NET.

La coincidencia de expresiones regulares no es probablemente un gran problema. La mayoría de los ataques de expresiones regulares funcionan igual de bien con cadenas de 64 y 64 caracteres: explotan un patrón de retroceso exponencial, y el tiempo de espera de su solicitud hace que la longitud de la URL sea bastante importante. Por el lado positivo, la mayoría de estos tipos de problemas se mostrarán rápidamente en problemas de rendimiento. Además, las expresiones regulares en general solo se aplican a la ruta de acceso, no a la cadena de consulta.

Las expresiones regulares de ruta son generalmente bastante rápidas y generalmente salen de la coincidencia en la primera comparación de enteros, aunque hay excepciones.

Si aumenta el límite, solo asegúrese de que todos los eventos de reescritura de URL, rutas, coincidencia de ruta y Pre-HandleRequest sean eficientes, tengan rutas de salida rápidas y no realice ningún trabajo de alta latencia como el disco o el acceso a la db / p>     

respondido por el Lilith River 25.09.2012 - 05:13
fuente
0

Descargo de responsabilidad: permítame comenzar diciendo que no soy un experto, pero aquí están mis dos centavos de todos modos.

El motivo por el que pone límites a las cadenas de consulta, en mi opinión, es para evitar el procesamiento de cadenas innecesariamente largas para la aplicación. Por ejemplo, su aplicación puede tener algunas reglas de enrutamiento de URL muy complejas (por ejemplo, en MVC3) que dicen, evalúe la cadena con un montón de RegEx. Para cadenas cortas, esto no es un gran problema, pero puede ser difícil si está evaluando una cadena grande. Otras veces, como en su caso, es posible que tenga que tomar esa cadena de consulta y hacer otra cosa con ella, como una búsqueda de base de datos, etc. Estas cosas pueden llevar tiempo y recursos y potencialmente poner una tensión grande en su servidor web.

En su caso, sin saber qué hará el enrutamiento (es decir, cómo maneja la cadena de consulta), es difícil saber qué impacto tendría esto. Digamos que todo lo que hizo su ruta fue devolver la longitud de la cadena de consulta. Entonces, por supuesto, esto no es tan vulnerable a un ataque de estilo DDoS como si tuviera que generar todas las permutaciones de esa cadena de consulta. Esos son ejemplos extremos, pero cosas como búsqueda, búsqueda de db, etc. podrían plantear problemas reales y podría quedar vulnerable a DDoS.

    
respondido por el tacos_tacos_tacos 25.09.2012 - 03:22
fuente

Lea otras preguntas en las etiquetas