我应该拒绝比预期时间长的URL吗?

如果您不期望该输入,请拒绝它。

您应该始终验证您的输入,并且一定要丢弃超出预期范围的任何内容。如果你已经知道你的URL的真实长度不会超过一定长度,那么在它到达应用程序之前拒绝它似乎是明智的。

纵深防御是一个很好的原则。但是,错误的安全措施是一个糟糕的原则。区别取决于很多细节。

如果您真的确信任何超过n的URL都是无效的,那么您也可以拒绝它。但是如果它是真的,并且您的输入验证的其余部分是正确的,那么稍后它将被拒绝。因此,所有这些检查都有可能减轻代码中其他bug造成的损害。花时间思考如何避免这些错误通常比思考n可能是什么要好。

如果您确实检查了长度,那么最好还是不要在代码的其他地方依赖这个长度限制。这样做将不同的检查更紧密地结合在一起,如果您更改了规范,并且需要接受更长的URL,那么在下一个版本中更难更改限制。例如,如果长度限制成为在没有适当注意和注意的情况下将URL放在堆栈上的借口,那么您可能正在设置某人进行坠落。

你怎么这么肯定 全部的 超过n的URL无效?如果你能确定,那么限制它作为一个健全的检查应该不会有什么害处——但不要让这个愚弄你以为你阻止了一类剥削。

我能看到的唯一可能导致问题的地方是,虽然今天你的网址永远不会超过N,但你不能保证永远不会出现这种情况。在一年内,当您返回进行编辑以允许URL长度为n+y时,您可能会忘记修改URL拒绝代码。

在使用URL参数之前,最好先验证它们。

Safari、Internet Explorer和Firefox都有不同的最大长度。

我选了三个中最短的一个。

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

从链接中提取-

“ Microsoft Internet Explorer(浏览器) -2083个字符

火狐(浏览器) -在65536个字符之后,位置栏不再显示Windows Firefox 1.5.x中的URL。但是,URL将工作更长时间。我在10万个字符后停止了测试。

Safari(浏览器) -至少80000个字符可以工作。”

我认为这可能会给你带来一些安全性,如果人们给你发送了疯狂的长URL,可能会节省你一点带宽,但在很大程度上,你也应该在实际的应用程序中验证你的数据。多层次的安全性通常更好,但不要误以为,因为一开始你有一个(弱)的安全保障,而其他的安全保障就不会有问题了。

我会说不,这只是虚假的安全。只要做好计划,检查你的请求是否有坏东西。这应该足够了。

而且,这不是未来的证据。

对。如果时间太长,而且你确定,那么尽快拒绝它。如果可以,请在它到达应用程序之前拒绝它(例如iislockdown将执行此操作)。

不过,记住要考虑到字符编码。

比起检查长度,我认为你应该检查内容。您永远不知道将来如何使用URL模式,但您可以随时清理输入。简单地说一件非常复杂的事情:不要相信用户提供的数据。不要把它直接放到数据库查询中,不要eval()它,不要想当然。

如果您知道有效的URL不能结束 n 字节那么,这听起来是一个快速拒绝跨站点脚本尝试的好方法,而不需要太多的努力。

最好验证一下 在请求中 验证URL长度。

您的需求可能在将来发生变化,此时您必须删除或更改URL长度验证,可能会引入错误。

如果它最终被证明是一个安全漏洞,那么您可以实现它。

好,假设存在这样一个n。正如onebyone指出的那样,长度超过n个字符的格式错误的URL无论如何都将被其他输入验证拒绝。然而,在我看来,这打开了一个全新的思路:

使用这个常量,您可以验证其他验证。如果其他验证无法检测到某个URL无效,但是该URL超过n个字符,那么该URL会触发一个bug并应进行记录(可能整个应用程序应该关闭,因为它们可能会创建一个足够短的无效URL)。

哦,我的,很多答案,很多好的观点,所以分散开来,所以让我尝试巩固这一切。 DR IMO,这对于应用层代码来说太低了。

是的,网址可以是 任何 长度,但实际上浏览器是有限制的。当然,这只会保护你免受那些愿意把自己限制在这些载体上的人基于浏览器的攻击,所以你确实需要某种方式来处理主动攻击尝试。

好的,它可以防止缓冲区溢出。好吧,只有当你在一个低水平的工作并且没有考虑到这些问题的时候。现在大多数语言都很好地支持字符串,不允许它们溢出。如果您处理的是一些非常低级的系统,实际上是以字节的形式读取数据并将其放入“字符串”类型,那么当然,您应该有某种方法来检测和处理这一点,但是分配内存和一次传输已知数量并不难,只需跟踪您预留的内存量。坦率地说,如果你正在处理这个低水平的问题,你真的应该使用其他东西。

好吧,那就根据字符串长度拒绝呢?这一点的主要原因是有可能产生一种错误的安全感。也就是说,代码的某些区域可能变得“草率”,并且容易受到您试图避免的漏洞攻击。显然,您必须小心确保这个“全局”限制是足够的,但是考虑到您的URI格式,您可能能够让这些“部分”报告它们的最大长度是多少,以及长度检查的中心(对于整个字符串及其组件);至少这样,如果一个部分需要允许更长的str嗯,更容易处理变化。

这当然对它有一些好处,例如,能够很快比较字符串的长度并立即拒绝请求…但是别忘了要成为一个“行为良好”的站点,你应该发送一个正确的响应来解释服务器为什么拒绝这个。实际上,你真的认为你必须处理这些类型的“错误”的URL吗?当然,它们在很多其他方面都是错误的。

出于某种原因,你不想说你用的是什么语言。像Java或Python这样的高级语言有一些非常好的库来处理“Web的东西”。Java将允许您为URI指定模式,包括为该模式使用正则表达式,因此,如果您想在URL中输入名称,则可以使用类似的方法。 @Path("/person/(.{0..100}") 将参数限制为100个字符。如果像ruby或python这样的语言没有等价的语言,我会感到惊讶,因为它们喜欢将自己提升为优秀的“webby”语言。

最后,不管长度是多少, 许多的 你需要验证的东西,不仅仅是长度。必须担心导致缓冲区溢出的URI的长度是一个非常低级的问题,并且需要非常通用,即需要处理任何请求,甚至可能具有1GB URI的请求;注意,我说的“handle”不是“accept it a pass it up to the application layer”,它可能在该低级拒绝它,也可能触发系统事件maybe.