Devrais-je refuser les URL plus longs que prévu?

Question

Je développe une application et mes URL sont au format www.exemple.com/some_url/some_parameter/some_keyword . Je sais que par conception, ces URL ont une longueur maximale (et sont toujours valides). Devrais-je valider la longueur de l'URL avec chaque demande afin de me protéger contre les attaques d'injection par débordement de tampon? Je pense que c'est une évidence, mais je ne suis pas un expert en sécurité. Il se peut donc que je manque quelque chose.

Answer 1

Si vous n'attendez pas cette entrée, refusez-la.

Vous devez toujours valider vos entrées et certainement éliminer tout ce qui est en dehors de la plage attendue. Si vous savez déjà que votre adresse URL ne dépassera honnêtement pas une certaine longueur, il semble judicieux de la rejeter avant qu'elle ne parvienne à l'application.

Answer 2

La défense en profondeur est un bon principe. Mais les fausses mesures de sécurité sont un mauvais principe. La différence dépend de nombreux détails.

Si vous êtes vraiment sûr qu'une adresse URL supérieure à N n'est pas valide, vous pouvez également la rejeter. Mais si c'est vrai, et si le reste de votre validation d'entrée est correcte, elle sera rejetée de toute façon ultérieurement. Donc, toute cette vérification ne fait que potentiellement atténuer les dégâts causés par un autre bogue de votre code. Il est souvent préférable de passer votre temps à réfléchir à la façon d’éviter ces bugs plutôt qu’à ce que pourrait être N.

.

Si vous vérifiez la longueur, il est préférable de ne pas vous fier à cette limite de longueur ailleurs dans votre code. Faire cela couple les différentes vérifications plus étroitement ensemble, et rend plus difficile de changer la limite dans la prochaine version, si vous modifiez la spécification et devez accepter des URL plus longues. Par exemple, si la longueur limite devient une excuse pour mettre les URL sur la pile sans la prudence voulue, vous risquez alors de forcer quelqu'un à tomber.

Answer 3

comment êtes-vous si sûr que toutes les adresses plus longues que N n'est pas valide? Si vous pouvez en être sûr, ne vous limitez pas à le limiter comme un simple contrôle, mais ne vous laissez pas induire en erreur en pensant que vous avez empêché une classe d'exploit.

Answer 4

La seule chose qui puisse causer des problèmes, c’est qu’aujourd’hui, votre URL ne dépassera jamais N, mais vous ne pouvez pas garantir que ce ne sera pas toujours le cas. Et dans un an, lorsque vous revenez pour effectuer une modification afin de permettre à une URL d'être de longueur N + y, vous pouvez oublier de modifier le code de rejet de cette URL.

Il sera toujours préférable de vérifier les paramètres d'URL avant de les utiliser.

Answer 5

Safari, Internet Explorer et Firefox ont tous des longueurs maximales différentes acceptées.

Je vote aller pour le plus court des trois.

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

Tiré du lien -

& Microsoft Internet Explorer (navigateur) - 2 083 caractères

Firefox (navigateur) : après 65 536 caractères, la barre d’emplacement n’affiche plus l’URL dans Windows Firefox 1.5.x. Cependant, des URL plus longues fonctionneront. J'ai arrêté de tester après 100 000 caractères.

Safari (navigateur) : au moins 80 000 caractères fonctionneront. "

Answer 6

Je pense que cela peut vous donner un minimum de sécurité et vous faire économiser un peu de bande passante si les gens vous envoient de longues URL folles, mais vous devez en grande partie simplement valider vos données dans l'application réelle. Plusieurs niveaux de sécurité sont généralement meilleurs, mais ne commettez pas l'erreur de penser que, parce que vous avez une protection (faible) au début, vous n'aurez pas de problèmes avec les autres.

Answer 7

Je dirais non. C'est juste une fausse sécurité. Juste programmez bien et vérifiez vos demandes pour les mauvaises choses. Cela devrait suffire.

En outre, ce n'est pas une preuve pour l'avenir.

Answer 8

Oui. Si c'est trop long et que vous êtes sûr, refusez-le dès que possible. Si vous le pouvez, refusez-le avant qu'il n'atteigne votre application (par exemple, IISLockdown le fera).

N'oubliez pas de prendre en compte le codage des caractères.

Answer 9

Mieux que de vérifier la longueur, je pense que vous devriez vérifier le contenu. Vous ne savez jamais comment vous allez utiliser votre schéma d'URL à l'avenir, mais vous pouvez toujours nettoyer vos entrées. Pour résumer très simplement: ne faites pas confiance aux données fournies par l’utilisateur. Ne le mettez pas directement dans les requêtes de base de données, ne l’évaluez pas, ne tenez rien pour acquis.

Answer 10

Si vous savez que les URL valides ne peuvent pas contenir plus de N octets, cela semble être un bon moyen de rejeter rapidement les tentatives de script intersite sans trop d'effort.

Answer 11

Il est préférable de valider le contenu de la demande que de valider la longueur de l'URL.

Vos besoins peuvent changer dans le futur. Vous devrez alors supprimer ou modifier la validation de la longueur de l'URL, ce qui peut entraîner l'introduction de bugs.

Si cela s'avère être une vulnérabilité de sécurité avérée, vous pouvez le mettre en œuvre.

Answer 12

Ok, supposons qu'un tel N existe. Comme l’a souligné Onebyone, une URL mal formée de plus de N caractères sera rejetée par une autre validation d’entrée. Cependant, à mes yeux, cela ouvre une toute nouvelle chose à penser:

En utilisant cette constante, vous pouvez valider votre autre validation. Si les autres validations ont été incapables de détecter une certaine URL comme non valide, l'URL étant plus longue que N caractères, cette URL déclenche un bogue et doit être enregistrée (et peut-être que toute l'application devrait être fermée, car elles pourraient créer une URL non valide suffisamment courte).

Answer 13

Oh mon Dieu, beaucoup de réponses, beaucoup de points positifs, donc dispersés, alors laissez-moi tenter de consolider tout cela. tl; dr , le niveau de sécurité lié au code de la couche d'application est trop faible.

Oui, l'URL peut avoir une longueur quelconque , mais dans la pratique, les navigateurs ont une limite. Bien sûr, cela ne vous protège que des attaques basées sur le navigateur de la part de personnes prêtes à se limiter à ces vecteurs. Vous avez donc besoin d'un moyen de gérer les tentatives d'attaque actives.

Ok, il peut protéger contre les débordements de mémoire tampon. Eh bien, seulement si vous travaillez à un niveau bas et ne pensez pas à de telles préoccupations. De nos jours, la plupart des langues supportent plutôt bien les chaînes et ne leur permettent pas de déborder. Si vous travaillez avec un système de très bas niveau, lisez les données sous forme d'octets et les mettez dans un type 'chaîne', alors vous devriez avoir un moyen de détecter et de gérer cela, mais ce n'est pas si difficile d'allouer de la mémoire, et transférez des quantités connues à la fois, gardez simplement une trace de la quantité de mémoire que vous avez mise de côté. Franchement, si vous avez affaire à ce niveau bas, vous devriez vraiment utiliser autre chose.

Bien, qu’en est-il du rejet basé sur la longueur de la chaîne? Le principal inconvénient est la possibilité d’un faux sentiment de sécurité. C'est-à-dire que certaines parties du code peuvent devenir "bâclées" et être vulnérables aux exploits mêmes que vous essayez d'éviter. Vous devez clairement faire attention à vous assurer que cette limite "globale" est réellement suffisante, mais compte tenu de votre format d'URI, vous pourrez peut-être demander à ces "pièces" de rendre compte de leur longueur maximale et de centrer la vérification de la longueur (pour les deux). la chaîne entière et ses composants); Au moins de cette façon, si une partie doit autoriser une chaîne plus longue, il est plus facile de gérer le changement.

Cela a bien sûr quelques avantages, par exemple, il est très rapide de pouvoir comparer la longueur d’une chaîne et de rejeter la demande tout de suite ... mais n’oubliez pas d’être un "bien élevé" site, vous devriez envoyer une réponse appropriée expliquant pourquoi le serveur le refuse. Dans la pratique cependant, pensez-vous réellement que vous allez devoir gérer autant de ces types d'URL "erronées", elles seraient sûrement erronées à bien d'autres égards.

Pour une raison quelconque, vous avez eu envie de ne pas dire quelle langue vous utilisez. Les langages de haut niveau tels que Java ou Python ont de très bonnes bibliothèques pour gérer les 'contenus Web'. Java vous permettra de spécifier des modèles pour l’URI, y compris l’utilisation de regex pour ce modèle. Ainsi, si vous souhaitez un nom dans l’URL, vous pouvez obtenir quelque chose comme @Path ("/ person / (. {0. .100} ") pour limiter le paramètre à 100 caractères. Je serais surpris que Ruby ou Python, par exemple, n’ait pas d’équivalent, ils aiment se promouvoir comme de jolies langues "webby".

Enfin, quelle que soit la longueur, il y a beaucoup de choses à valider, et pas seulement la longueur. Avoir à s'inquiéter de la longueur de l'URI provoquant un dépassement de mémoire tampon est une chose de très bas niveau, et devrait être très générique, c'est-à-dire qu'il faut traiter toute requête, même avec une URI potentiellement de 1 Go; note J'ai dit 'gérer' pas 'l'accepter et le transmettre à la couche application', il pourrait le rejeter à ce niveau bas, provoquant peut-être également des événements système.