我正在开发一个应用程序,并且 URL 格式为www.example.com/some_url/some_parameter/some_keyword
. 我从设计上知道这些 URL 将具有最大长度(并且仍然有效)。我是否应该验证每个请求的 URL 长度以防止缓冲区溢出/注入攻击?我相信这显然是肯定的,但我不是安全专家,所以也许我遗漏了一些东西。
13 回答
如果您不期望该输入,请拒绝它。
您应该始终验证您的输入,并肯定丢弃超出预期范围的任何内容。如果您已经知道您的 URL 确实不会超过某个长度,那么在它到达应用程序之前拒绝它似乎是明智的。
纵深防御是一个很好的原则。但是错误的安全措施是一个糟糕的原则。差异取决于很多细节。
如果您确实确信任何超过 N 的 URL 都是无效的,那么您不妨拒绝它。但是,如果它是真的,并且如果您的输入验证的其余部分是正确的,那么无论如何它都会在以后被拒绝。因此,所有这些检查可能会减轻代码中其他错误造成的损害。花时间思考如何避免这些错误通常比思考 N 可能是什么要好。
如果您确实检查了长度,那么最好不要在代码的其他地方依赖这个长度限制。这样做会将不同的检查更紧密地结合在一起,并且如果您更改规范并需要接受更长的 URL,则在下一个版本中更改限制变得更加困难。例如,如果长度限制成为将 URL 放入堆栈而不给予应有的注意和注意的借口,那么您可能正在让某人跌倒。
你怎么确定所有长于 N 的 URL 都是无效的?如果您可以确定,那么将其限制为一个健全性检查应该没有什么坏处——但不要让这愚弄您以为您已经阻止了一类漏洞利用。
我能看到的唯一可能导致问题的是,虽然今天你的 URL 永远不会超过 N,但你不能保证永远不会如此。一年后,当你回去进行编辑以允许 url 长度为 N+y 时,你可能会忘记修改 url 拒绝代码。
在使用 URL 参数之前,最好先验证它们。
Safari、Internet Explorer 和 Firefox 都有不同的可接受的最大长度。
我投票选择所有三个中最短的。
http://www.boutell.com/newfaq/misc/urllength.html
从链接中提取 -
" Microsoft Internet Explorer(浏览器) - 2,083 个字符
Firefox(浏览器) - 在 65,536 个字符之后,位置栏不再显示 Windows Firefox 1.5.x 中的 URL。但是,更长的 URL 也可以。我在 100,000 个字符后停止测试。
Safari(浏览器) - 至少 80,000 个字符可以使用。”
我认为这可能会给您一些安全性,并且如果人们确实向您发送了疯狂的长 URL,可能会为您节省一点带宽,但很大程度上您也应该在实际应用程序中验证您的数据。多级安全性通常更好,但不要错误地认为,因为一开始有一个(薄弱的)保护措施,其余的就不会出现问题。
我会说不。这只是虚假的安全。只需好好编程并检查您对坏东西的请求。应该够了。
此外,这不是未来的证据。
是的。如果它太长并且你确定然后尽快拒绝它。如果可以,请在它到达您的应用程序之前拒绝它(例如 IISLockdown 将执行此操作)。
记住要考虑字符编码。
比检查长度更好,我认为你应该检查内容。您永远不知道将来将如何使用您的 URL 架构,但您始终可以清理您的输入。把一个非常复杂的事情简单地说:不要相信用户提供的数据。不要将它直接放入数据库查询中,不要 eval() 它,不要认为任何事情都是理所当然的。
如果您知道有效的 URL 不能超过N个字节,那么这听起来是一种无需太多努力即可快速拒绝跨站点脚本尝试的好方法。
验证请求中的内容比验证 URL 长度更好。
您的需求将来可能会发生变化,此时您必须删除或更改 URL 长度验证,可能会引入错误。
如果它最终成为一个经过验证的安全漏洞,那么您可以实施它。
好的,让我们假设这样的 N 存在。正如 onebyone 指出的那样,长度超过 N 个字符的格式错误的 URL 无论如何都会被其他输入验证拒绝。然而,在我看来,这开启了一个全新的思考方式:
使用此常量,您可以验证您的其他验证。但是,如果其他验证无法将某个 URL 检测为无效,但该 URL 的长度超过 N 个字符,则该 URL 会触发错误并应被记录(并且可能整个应用程序应该关闭,因为它们可能会创建一个足够短的无效 URL)。
哦,我的,很多答案,很多好点,不过如此分散,所以让我尝试巩固所有这些。tl; dr imo,这对应用层代码来说太低级了。
是的,URL 可以是任意长度,但实际上浏览器有限制。当然,这只能保护您免受那些愿意将自己限制在这些向量中的基于浏览器的攻击,因此您确实需要某种方法来处理主动攻击尝试。
好的,它可以防止缓冲区溢出。好吧,只有当您在低级别工作并且不考虑此类问题时。如今,大多数语言都很好地支持字符串,并且不允许它们溢出。如果您正在处理一些非常低级的系统,实际上将数据读取为字节并将其放入“字符串”类型,那么当然,您应该有某种检测和处理它的方法,但分配内存并不难,并一次传输已知数量,只需跟踪您预留了多少内存即可。坦率地说,如果你正在处理那个低级别,你真的应该使用其他东西。
好吧,那仅仅根据字符串长度拒绝呢?对此的主要缺点是可能产生虚假的安全感。也就是说,代码的某些区域可能会变得“草率”,并且很容易受到您试图避免的漏洞的攻击。您显然必须小心确保这个“全局”限制实际上是足够的,但考虑到您的 URI 格式,您可能能够让这些“部分”报告它们的最大长度是多少,并集中长度检查(对于两者整个字符串,以及它的组成部分);至少这样,如果某个部分需要允许更长的字符串,则更容易处理更改。
This does of course have some advantages to it, for one, it's very quick to be able to compare the length of a string and reject the request right away... but don't forget to be a 'well behaved' site you should be sending back a proper response explaining why the server is rejecting this. In practice though, do you really think you are going to have to handle that many of these types of 'wrong' URL, surely they would be wrong in so many other ways.
For some reason, you felt like not saying what language you are using. High level languages like Java or Python have some very good libraries for dealing with 'web stuff'. Java will let you specify patterns for the URI, including the use of regex for that pattern, so if you wanted a name in the URL, you could have something like @Path("/person/(.{0..100}")
to limit the parameter to 100 characters. I'd be surprised if the likes of Ruby or Python didn't have equivalent, they like to promote themselves as nice 'webby' languages.
Finally, regardless of length, there are many things that you will need to validate, not just length. Having to worry about the length of the URI causing a buffer overflow is a very low level thing, and would need to be very generic, ie need to handle any request, even one with a 1GB URI potentially; note I said 'handle' not 'accept it an pass it up to the application layer', it could reject it at that low level, also triggering system events maybe.