Devo rifiutare gli URL più a lungo del previsto?

Question

Sto sviluppando un'applicazione e ho gli URL nel formato www.example.com/some_url/some_parameter/some_keyword.So in base alla progettazione che esiste una lunghezza massima che questi URL avranno (e saranno comunque validi).Devo convalidare la lunghezza dell'URL con ogni richiesta per proteggermi dagli attacchi buffer overflow/injection?Credo che questo sia un ovvio sì, ma non sono un esperto di sicurezza quindi forse mi sto perdendo qualcosa.

Answer 1

Se non ti aspetti quell’input, rifiutalo.

Dovresti sempre convalidare i tuoi input e certamente scartare qualsiasi cosa al di fuori dell'intervallo previsto.Se sai già che il tuo URL non supererà una certa lunghezza, rifiutarlo prima che arrivi all'applicazione sembra saggio.

Answer 2

La difesa in profondità è un buon principio.Ma le false misure di sicurezza sono un cattivo principio.La differenza dipende da molti dettagli.

Se sei veramente sicuro che qualsiasi URL sopra N non sia valido, puoi anche rifiutarlo.Ma se è vero e se il resto della convalida dell'input è corretto, verrà comunque rifiutato in seguito.Quindi tutto ciò che fa questo controllo è potenzialmente, forse, mitigare il danno causato da qualche altro bug nel tuo codice.Spesso è meglio passare il tempo a pensare a come evitare questi bug, piuttosto che pensare a cosa potrebbe essere N.

Se controlli la lunghezza, è comunque meglio non fare affidamento su questo limite di lunghezza in altre parti del codice.In questo modo si accoppiano più strettamente i diversi controlli e si rende più difficile modificare il limite nella versione successiva, se si modificano le specifiche e si devono accettare URL più lunghi.Ad esempio, se il limite di lunghezza diventa una scusa per mettere gli URL in pila senza la dovuta cura e attenzione, potresti far cadere qualcuno.

Answer 3

come fai a esserne così sicuro? Tutto L'URL più lungo di N non è valido?Se puoi esserne sicuro, allora non dovrebbe far male limitarlo solo come controllo di integrità, ma non lasciarti ingannare facendoti credere di aver impedito una classe di exploit.

Answer 4

L'unica cosa che vedo che potrebbe causare problemi è che mentre oggi il tuo URL non supererà mai N, non puoi garantire che non sarà così per sempre.E tra un anno, quando torni indietro per apportare una modifica per consentire a un URL di avere una lunghezza N+y, potresti dimenticare di modificare il codice di rifiuto dell'URL.

Farai sempre meglio a verificare i parametri URL prima di utilizzarli.

Answer 5

Safari, Internet Explorer e Firefox accettano lunghezze massime diverse.

Io voto per il più corto dei tre.

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

Estratto dal collegamento -

"Microsoft Internet Explorer (browser) - 2.083 caratteri

Firefox (browser) - Dopo 65.536 caratteri, la barra degli indirizzi non visualizza più l'URL in Windows Firefox 1.5.x.Tuttavia, gli URL più lunghi funzioneranno.Ho interrotto il test dopo 100.000 caratteri.

Safari (browser) - Funzioneranno almeno 80.000 caratteri."

Answer 6

Penso che questo potrebbe darti un minimo di sicurezza e potrebbe farti risparmiare un po' di larghezza di banda se le persone ti inviano URL pazzeschi, ma in gran parte dovresti semplicemente convalidare i tuoi dati anche nell'applicazione reale.Più livelli di sicurezza sono generalmente migliori, ma non commettere l'errore di pensare che, poiché all'inizio hai una protezione (debole), non avrai problemi con il resto.

Answer 7

Direi di no.E' solo falsa sicurezza.Basta programmare bene e controllare le tue richieste per cose cattive.Dovrebbe essere sufficiente.

Inoltre, non è a prova di futuro.

Answer 8

SÌ.Se è troppo lungo e ne sei sicuro, rifiutalo il prima possibile.Se puoi, rifiutalo prima che raggiunga la tua domanda (ad esempio IISLockdown lo farà).

Ricordatevi però di tenere conto della codifica dei caratteri.

Answer 9

Meglio che controllare la lunghezza, penso che dovresti controllare il contenuto.Non sai mai come utilizzerai il tuo schema URL in futuro, ma puoi sempre ripulire i tuoi input.Per mettere una cosa molto complessa in modo molto semplice:Non fidarti dei dati forniti dagli utenti.Non inserirlo direttamente nelle query del DB, non eval(), non dare nulla per scontato.

Answer 10

Se sai che gli URL validi non possono essere finiti N byte, quindi sembra un buon modo per rifiutare rapidamente i tentativi di cross-site scripting senza troppi sforzi.

Answer 11

È meglio convalidare ciò che è nella richiesta piuttosto che convalidare la lunghezza dell'URL.

Le tue esigenze potrebbero cambiare in futuro, a quel punto dovrai rimuovere o modificare la convalida della lunghezza dell'URL, introducendo eventualmente bug.

Se si rivela una comprovata vulnerabilità della sicurezza, puoi implementarla.

Answer 12

Ok, supponiamo che tale N esista.Come sottolineato da qualcuno, un URL non valido che è più lungo di N caratteri verrà comunque rifiutato da altre convalide di input.Tuttavia, ai miei occhi, questo apre una cosa completamente nuova a cui pensare:

Usando questa costante, puoi convalidare l'altra tua convalida.Se le altre validazioni non sono state in grado di rilevare un determinato URL come non valido, tuttavia, l'URL è più lungo di N caratteri, allora questo URL attiva un bug e dovrebbe essere registrato (e forse l'intera applicazione dovrebbe spegnersi, perché potrebbero creare un URL non valido sufficientemente breve).

Answer 13

Oh mio Dio, molte risposte, molti punti positivi, quindi sparpagliati, quindi permettimi di provare a consolidare tutto questo. tl; dott imo, questo è un problema di livello troppo basso per il codice del livello dell'applicazione.

Sì, l'URL potrebbe essere di Qualunque lunghezza, ma in pratica i browser hanno un limite.Naturalmente, ciò ti protegge solo dagli attacchi basati su browser da parte di persone disposte a limitarsi a tali vettori, quindi è necessario un modo per gestire i tentativi di attacco attivi.

Ok, può proteggere dai buffer overflow.Bene, solo se lavori a un livello basso e non pensi a tali preoccupazioni.La maggior parte delle lingue oggigiorno supporta le stringhe piuttosto bene e non consente loro di traboccare.Se avessi a che fare con un sistema di livello molto basso, leggendo effettivamente i dati come byte e inserendoli in un tipo "stringa", allora certo, dovresti avere un modo per rilevarlo e gestirlo, ma non è così difficile allocare memoria, e trasferisci quantità note alla volta, tieni semplicemente traccia della quantità di memoria che metti da parte.Francamente, se hai a che fare con un livello così basso, dovresti davvero usare qualcos'altro.

Bene ok, che ne dici di rifiutare semplicemente in base alla lunghezza della stringa?Lo svantaggio principale di tutto ciò è il potenziale di un falso senso di sicurezza.Vale a dire, alcune aree del codice potrebbero diventare "sciatte" ed essere vulnerabili agli stessi exploit che stai cercando di evitare.Chiaramente devi stare attento per assicurarti che questo limite 'globale' sia effettivamente sufficiente, ma considerando il tuo formato URI, potresti essere in grado di fare in modo che quelle 'parti' riportino quale sia la loro lunghezza massima e centralizzino il controllo della lunghezza (per entrambi l'intera stringa e i suoi componenti);almeno in questo modo, se una parte deve consentire una stringa più lunga, è più semplice gestire la modifica.

Ciò ovviamente presenta alcuni vantaggi, ad esempio è molto veloce poter confrontare la lunghezza di una stringa e rifiutare immediatamente la richiesta...ma non dimenticare di essere un sito "ben educato", dovresti inviare una risposta adeguata che spieghi perché il server lo rifiuta.In pratica, però, pensi davvero che dovrai gestire molti di questi tipi di URL "sbagliati", sicuramente sarebbero sbagliati in tanti altri modi.

Per qualche ragione, avevi voglia di non dire quale lingua stai usando.Linguaggi di alto livello come Java o Python hanno alcune ottime librerie per gestire "cose ​​​​web".Java ti consentirà di specificare modelli per l'URI, incluso l'uso di regex per quel modello, quindi se volessi un nome nell'URL, potresti avere qualcosa come @Path("/person/(.{0..100}") per limitare il parametro a 100 caratteri.Sarei sorpreso se artisti del calibro di Ruby o Python non avessero equivalenti, a loro piace promuoversi come simpatici linguaggi "webby".

Infine, indipendentemente dalla lunghezza, ci sono molti cose che dovrai convalidare, non solo la lunghezza.Doversi preoccupare della lunghezza dell'URI che causa un overflow del buffer è una cosa di livello molto basso e dovrebbe essere molto generica, ovvero è necessario gestire qualsiasi richiesta, anche una con un URI potenzialmente da 1 GB;nota che ho detto "gestisci" non "accettalo e passalo al livello dell'applicazione", potrebbe rifiutarlo a quel livello basso, forse anche attivando eventi di sistema.