我应该拒绝比预期长的网址吗？

https://stackoverflow.com/questions/92561

01-07-2019
|

题

我正在开发一个应用程序，并且具有以下格式的 URL www.example.com/some_url/some_parameter/some_keyword. 。我知道根据设计，这些 URL 具有最大长度（并且仍然有效）。我是否应该验证每个请求的 URL 长度以防止缓冲区溢出/注入攻击？我相信这是一个明显的肯定，但我不是安全专家，所以也许我遗漏了一些东西。

解决方案

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

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

其他提示

纵深防御是一个很好的原则。但虚假的安全措施是一个糟糕的原则。差异取决于很多细节。

如果您确实确信任何超过 N 的 URL 都是无效的，那么您不妨拒绝它。但如果这是真的，并且输入验证的其余部分是正确的，那么无论如何它都会在以后被拒绝。因此，所有这些检查所做的一切都可能减轻代码中其他错误造成的损害。花时间思考如何避免这些错误通常比思考 N 可能是什么更好。

如果您确实检查了长度，那么最好不要在代码中的其他地方依赖此长度限制。这样做可以将不同的检查更紧密地结合在一起，并且如果您更改规范并需要接受更长的 URL，则在下一版本中更改限制会变得更加困难。例如，如果长度限制成为在没有应有的谨慎和注意的情况下将 URL 放入堆栈的借口，那么您可能会让某人跌倒。

你怎么这么确定全部 URL 长度超过 N 无效？如果您可以确定，那么将其限制为健全性检查应该不会有什么坏处 - 但不要让这欺骗您，让您认为您已经阻止了一类漏洞利用。

我认为唯一可能导致问题的是，虽然今天您的 URL 永远不会超过 N，但您不能保证这种情况不会永远如此。一年后，当你回去进行编辑以允许 url 长度为 N+y 时，你可能会忘记修改 url 拒绝代码。

在使用 URL 参数之前最好先对其进行验证。

Safari、Internet Explorer 和 Firefox 所接受的最大长度都不同。

我投票支持这三个中最短的一个。

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

从链接中拉出 -

"微软 Internet Explorer（浏览器） - 2,083 个字符

火狐（浏览器） - 超过 65,536 个字符后，Windows Firefox 1.5.x 中的地址栏不再显示 URL。不过，更长的 URL 也可以。100,000 个字符后我停止了测试。

Safari（浏览器） - 至少可以使用 80,000 个字符。”

我认为这可能会给您带来一些安全性，并且如果人们确实向您发送疯狂的长 URL，则可能会为您节省一些带宽，但很大程度上您也应该在实际应用程序中验证您的数据。多个级别的安全性通常更好，但不要错误地认为，因为一开始就有（薄弱的）保护措施，所以其他方面就不会有问题。

我会说不。这只是虚假的安全感。只需好好编程并检查您的请求是否有不良内容即可。应该够了。

而且，它也不是面向未来的。

是的。如果它太长并且您确定，请尽快拒绝它。如果可以，请在它到达您的应用程序之前拒绝它（例如 IISLockdown 将执行此操作）。

不过请记住考虑字符编码。

我认为你应该检查内容，而不是检查长度。您永远不知道将来将如何使用您的 URL 架构，但您始终可以清理您的输入。把一个非常复杂的事情说得非常简单：不要相信用户提供的数据。不要将其直接放入数据库查询中，不要对其进行 eval() ，不要认为任何事情都是理所当然的。

如果您知道有效的网址不能结束氮 bytes 那么这听起来像是一种无需太多努力即可快速拒绝跨站点脚本尝试的好方法。

最好验证一下是什么 在请求中 比验证 URL 长度。

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

如果它最终确实成为一个经过验证的安全漏洞，那么您就可以实施它。

好吧，我们假设这样的 N 存在。正如 onebyone 所指出的，长度超过 N 个字符的格式错误的 URL 无论如何都会被其他输入验证拒绝。然而，在我看来，这开启了一个全新的思考领域：

使用此常量，您可以验证其他验证。如果其他验证无法将某个 URL 检测为无效，但是该 URL 长度超过 N 个字符，则该 URL 会触发错误并应予以记录（也许整个应用程序应关闭，因为它们可能会创建一个错误）足够短的无效 URL）。

哦，天哪，很多答案，很多好点，虽然很分散，所以让我尝试整合所有这些。 太长了；博士 在我看来，这对于应用程序层代码来说太低级了。

是的，URL 可以是任何长度，但实际上浏览器有限制。当然，这只能保护您免受那些愿意将自己限制在这些向量中的人基于浏览器的攻击，因此您确实需要某种方法来处理主动攻击尝试。

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

好吧，那么根据字符串长度拒绝怎么样？这样做的主要缺点是可能产生错误的安全感。也就是说，代码的某些区域可能会变得“草率”，并且很容易受到您试图避免的漏洞的攻击。显然，您必须小心确保这个“全局”限制实际上是足够的，但考虑到您的 URI 格式，您也许可以让这些“部分”报告它们的最大长度，并集中长度检查（对于两者）整个字符串及其组成部分）；至少这样，如果一个部分需要允许更长的字符串，则更容易处理更改。

这当然有一些优点，首先，能够非常快地比较字符串的长度并立即拒绝请求......但不要忘记成为一个“行为良好”的网站，您应该发回正确的响应，解释服务器拒绝此请求的原因。但在实践中，您真的认为您必须处理这么多类型的“错误”URL吗？它们肯定在许多其他方面都是错误的。

出于某种原因，您不想透露您使用的是什么语言。Java 或 Python 等高级语言有一些非常好的库来处理“网络内容”。Java 将允许您指定 URI 的模式，包括对该模式使用正则表达式，因此如果您想要在 URL 中包含名称，您可以使用类似的内容 @Path("/person/(.{0..100}") 将参数限制为 100 个字符。如果 Ruby 或 Python 之类的语言没有对应的语言，我会感到惊讶，他们喜欢将自己宣传为漂亮的“webby”语言。

最后，无论长度如何，都有许多您需要验证的东西，而不仅仅是长度。必须担心 URI 的长度导致缓冲区溢出是一件非常低级的事情，并且需要非常通用，即需要处理任何请求，甚至可能具有 1GB URI 的请求；请注意，我说的是“处理”而不是“接受它并将其传递到应用程序层”，它可能会在低级别拒绝它，也可能会触发系统事件。

许可以下： CC-BY-SA 和归因

不隶属于 StackOverflow