È pericoloso consentire le richieste HTTP con lunghe sequenze di query in IIS?

Question

È pericoloso consentire le richieste HTTP con lunghe sequenze di query in IIS?

#1 da (4 voti)
#2 da (0 voti)

2

Sto sviluppando un sito Web con una funzione di ricerca che potrebbe generare richieste HTTP di caratteri molto lunghi (fino a 15.000). Tuttavia, IIS ha un limite predefinito di 2048 caratteri per querystrings. Questo può essere facilmente modificato in un file web.config usando le impostazioni elencate di seguito.

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

La mia domanda è se ci sono dei problemi di sicurezza di cui dovrei essere a conoscenza se permetto lunghe sequenze di querys nelle richieste HTTP?

Aggiornamento: dovrei aggiungere alcuni bit di informazioni.

Il sito web sarà disponibile solo per gli utenti a pagamento che hanno effettuato l'accesso al sito web.
La probabilità che qualcuno possa creare una ricerca con più di 2048 caratteri nell'URL è MOLTO magra, ma teoricamente possibile.

http iis webserver

posta jessegavin 25.09.2012 - 00:13

fonte

2 risposte

Leggi altre domande sui tag http iis webserver

Usando tor con SET per bypassare i criteri del firewall? Cookie HTTPOnly: la sicurezza dipende dalla collaborazione con i clienti?

score 4 · Answer 1

Gli URL di 15.000 caratteri non funzioneranno molto bene nel cross-browser: link

Supponendo che tu sappia già che, in un'applicazione ASP.NET, un limite di 16.000 caratteri aumenterà la vulnerabilità agli attacchi di esaurimento della coda del buffer delle richieste 8x. Ora, 8x non è così significativo rispetto agli attacchi DoS migliori generalmente aperti su un sito Web ASP.NET.

La corrispondenza delle espressioni regolari non è probabilmente un grosso problema. La maggior parte degli attacchi regexp funziona egualmente bene con 64 caratteri e 64.000 stringhe di caratteri: sfruttano un pattern di backtrack esponenziale e il timeout della richiesta rende la lunghezza dell'URL del tutto insignificante. Al rialzo, la maggior parte di questi tipi di problemi si mostrerà rapidamente in termini di prestazioni. Inoltre, le regex generalmente vengono applicate solo al percorso, non alla querystring.

Le espressioni ree del percorso sono generalmente piuttosto veloci e in genere escono dalla corrispondenza al primo confronto tra numeri interi, sebbene vi siano eccezioni.

Se aumenti il limite, assicurati che tutta la riscrittura degli URL, i percorsi, la corrispondenza dei percorsi e gli eventi pre-HandleRequest siano efficienti, abbiano percorsi di uscita veloci e non eseguano lavori a latenza elevata come l'accesso al disco o al db.

score 0 · Answer 2

Dichiarazione di non responsabilità: permettimi di prefigurare ammettendo che non sono affatto un esperto, ma qui sono comunque i miei due centesimi.

Il motivo per cui limiti i querystrings, a mio avviso, è evitare l'elaborazione di stringhe inutilmente lunghe per l'app. Ad esempio, la tua app potrebbe avere alcune regole di routing URL molto complesse (ad esempio, in MVC3) che dicono, valutare la stringa con un gruppo di RegEx. Per le stringhe brevi, questo non è un grosso problema, ma può diventare difficile se si sta valutando una grande stringa. Altre volte, come nel tuo caso, potrebbe essere necessario prendere quella stringa di query e fare qualcos'altro con esso, come una ricerca DB, ecc. Queste cose possono richiedere tempo e risorse e potenzialmente mettere un grande sforzo sul tuo server web.

Nel tuo caso, senza sapere quale sarà il routing (cioè come gestisce la stringa di query), è difficile sapere quale impatto avrebbe avuto. Diciamo che tutto il tuo percorso è stato inviare indietro la lunghezza della querystring. Quindi, ovviamente, questo non è vulnerabile a un attacco in stile DDoS come se dovessi generare tutte le permutazioni di quella querystring. Questi sono esempi estremi, ma cose come la ricerca, la ricerca di db, ecc. Potrebbero porre problemi reali e potresti essere lasciato vulnerabile a DDoS.