Devo rejeitar URLs por mais tempo do que o esperado?

Question

Estou desenvolvendo um aplicativo e tenho URLs no formato www.example.com/some_url/some_parameter/some_keyword.Eu sei por design que há um comprimento máximo que esses URLs terão (e ainda serão válidos).Devo validar o comprimento do URL com cada solicitação para proteger contra ataques de buffer overflow/injeção?Acredito que seja um sim óbvio, mas não sou especialista em segurança, então talvez esteja faltando alguma coisa.

Answer 1

Se você não está esperando essa entrada, rejeite -a.

Você sempre deve validar suas entradas e certamente descartar qualquer coisa fora do intervalo esperado. Se você já sabe que seu URL está honestamente não estará além de um certo comprimento, rejeitá -lo antes que ele chegue ao aplicativo parece sábio.

Answer 2

A defesa em profundidade é um bom princípio.Mas as falsas medidas de segurança são um mau princípio.A diferença depende de muitos detalhes.

Se você estiver realmente confiante de que qualquer URL acima de N é inválido, é melhor rejeitá-lo.Mas se for verdade e se o restante da validação de entrada estiver correto, ela será rejeitada mais tarde de qualquer maneira.Portanto, tudo o que essa verificação faz é potencialmente, talvez, mitigar o dano causado por algum outro bug no seu código.Muitas vezes é melhor gastar seu tempo pensando em como evitar esses bugs do que pensando no que N poderia ser.

Se você verificar o comprimento, ainda é melhor não confiar nesse limite de comprimento em outras partes do seu código.Isso une as diferentes verificações de maneira mais estreita e torna mais difícil alterar o limite na próxima versão, se você alterar as especificações e precisar aceitar URLs mais longos.Por exemplo, se o limite de comprimento se tornar uma desculpa para colocar URLs na pilha sem o devido cuidado e atenção, então você pode estar preparando alguém para cair.

Answer 3

Como você tem tanta certeza disso tudo URL mais longo que n é inválido? Se você pode ter certeza, não deve doer limitá -lo apenas como uma verificação de sanidade - mas não deixe que isso o engane pensasse que você impediu uma classe de exploração.

Answer 4

A única coisa que posso ver que pode causar problemas é que, embora hoje seu URL nunca exceda n, você não pode garantir que esse não será o caso para sempre. E em um ano, quando você volta para fazer uma edição para permitir que um URL tenha n+y de comprimento, você pode esquecer de modificar o código de rejeição de URL.

Você sempre será melhor verificar os parâmetros da URL antes de usá -los.

Answer 5

Safari, Internet Explorer e Firefox têm diferentes comprimentos máximos que aceita.

Eu voto, vá para o mais curto dos três.

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

Retirado do link -

"Microsoft Internet Explorer (navegador) - 2.083 caracteres

Firefox (navegador) - Após 65.536 caracteres, a barra de localização não exibe mais o URL no Windows Firefox 1.5.x. No entanto, URLs mais longos funcionarão. Parei de testar depois de 100.000 caracteres.

Safari (navegador) - Pelo menos 80.000 caracteres funcionarão. "

Answer 6

Eu acho que isso pode lhe dar um pouco de segurança e pode economizar uma pequena largura de banda se as pessoas lhe enviarem URLs longos e loucos, mas, em grande parte, você deve apenas validar seus dados no aplicativo real também. Vários níveis de segurança geralmente são melhores, mas não cometem o erro de pensar que, porque você tem uma salvaguarda (fraca) no início de que não terá problemas com o resto.

Answer 7

Eu diria não. É apenas uma falsa segurança. Basta programar bem e verificar seus pedidos de coisas ruins. Deve ser suficiente.

Além disso, não é uma prova futura.

Answer 8

Sim. Se for muito longo e você tem certeza, rejeite -o o mais rápido possível. Se você puder, rejeite -o antes que ele atinja seu aplicativo (por exemplo, o iislockdown fará isso).

Lembre -se de explicar a codificação de personagens.

Answer 9

Melhor do que verificar o comprimento, acho que você deve verificar o conteúdo. Você nunca sabe como usará seu esquema de URL no futuro, mas sempre poderá higienizar seus insumos. Para colocar uma coisa muito complexa de maneira muito complexa: não confie em dados fornecidos pelo usuário. Não coloque -o diretamente em consultas de banco de dados, não avalie (), não tome nada como certo.

Answer 10

Se você sabe que os URLs válidos não podem acabar N Bytes, então, parece uma boa maneira de rejeitar rapidamente as tentativas de scripts entre sites sem muito esforço.

Answer 11

É melhor validar o que é no pedido do que validar o comprimento da URL.

Suas necessidades podem mudar no futuro; nesse momento, você terá que remover ou alterar a validação do comprimento da URL, possivelmente introduzindo bugs.

Se acabar como uma vulnerabilidade de segurança comprovada, você poderá implementá -lo.

Answer 12

Ok, vamos supor que esse N exista. Como o OneByone apontou, um URL malformado que é mais longo que N caracteres será rejeitado por outra validação de entrada de qualquer maneira. No entanto, aos meus olhos, isso abre uma coisa totalmente nova a se pensar:

Usando essa constante, você pode validar sua outra validação. Se as outras validações não conseguiram detectar um certo URL como inválido, no entanto, o URL é mais longo que N caracteres, então esse URL desencadeia um bug e deve ser gravado (e talvez todo o aplicativo deva desligar, porque eles podem criar um URL inválido que é curto o suficiente).

Answer 13

Nossa, muitas respostas, muitos pontos positivos, então espalhe, então deixe-me tentar consolidar tudo isso. dr. Na verdade, essa é uma preocupação de nível muito baixo para o código da camada de aplicativo.

Sim, o URL pode ser de qualquer comprimento, mas na prática os navegadores têm um limite.É claro que isso apenas protege você de ataques baseados em navegador por pessoas dispostas a se limitar a esses vetores, então você precisa de alguma maneira de lidar com as tentativas de ataque ativas.

Ok, ele pode proteger contra buffer overflows.Bom, só se você estiver trabalhando em um nível baixo e não pensando nessas preocupações.A maioria das linguagens hoje em dia suportam muito bem strings e não permitem que elas simplesmente transbordem.Se você estivesse lidando com algum sistema de nível muito baixo, lendo os dados como bytes e colocando-os em um tipo 'string', então com certeza você deveria ter alguma maneira de detectar e lidar com isso, mas não é tão difícil alocar memória, e transferir quantidades conhecidas de cada vez, basta controlar quanta memória você reservou.Francamente, se você está lidando com esse nível baixo, você realmente deveria usar outra coisa.

Bem, ok, que tal apenas rejeitar com base no comprimento da string?A principal desvantagem disso é o potencial para uma falsa sensação de segurança.Ou seja, algumas áreas do código podem ficar 'desleixadas' e vulneráveis ​​às mesmas explorações que você está tentando evitar.Você claramente precisa ter cuidado para garantir que esse limite 'global' seja realmente suficiente, mas considerando seu formato de URI, você poderá fazer com que essas 'partes' relatem qual é seu comprimento máximo e centralizem a verificação de comprimento (para ambos toda a string e seus componentes);pelo menos assim, se uma parte precisar permitir uma string mais longa, será mais fácil lidar com a mudança.

É claro que isso tem algumas vantagens: por um lado, é muito rápido poder comparar o comprimento de uma string e rejeitar a solicitação imediatamente...mas não se esqueça de ser um site 'bem comportado', você deve enviar uma resposta adequada explicando por que o servidor está rejeitando isso.Na prática, porém, você realmente acha que terá que lidar com tantos desses tipos de URL 'errados'? Certamente eles estariam errados de muitas outras maneiras.

Por algum motivo, você sentiu vontade de não dizer qual idioma está usando.Linguagens de alto nível como Java ou Python possuem algumas bibliotecas muito boas para lidar com 'coisas da web'.Java permitirá que você especifique padrões para o URI, incluindo o uso de regex para esse padrão; portanto, se você quiser um nome na URL, poderá ter algo como @Path("/person/(.{0..100}") para limitar o parâmetro a 100 caracteres.Eu ficaria surpreso se Ruby ou Python não tivessem equivalentes, eles gostam de se promover como linguagens 'webby' legais.

Finalmente, independentemente do comprimento, existem muitos coisas que você precisará validar, não apenas o comprimento.Ter que se preocupar com o comprimento do URI que causa um buffer overflow é algo de nível muito baixo e precisaria ser muito genérico, ou seja, precisaria lidar com qualquer solicitação, mesmo uma com um URI potencialmente de 1 GB;observe que eu disse 'lidar com' e não 'aceitar e passá-lo para a camada de aplicativo', ele poderia rejeitá-lo naquele nível baixo, talvez também acionando eventos do sistema.