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

解决方案

我们如何确定所有大于N的URL都是无效的？如果可以确定的话，将其限制为健全性检查应该无济于事，但不要让它愚弄我们以为我们已阻止了一类攻击。

我认为这可能会给我们带来一定程度的安全性，并且如果人们确实向我们发送了疯狂的长URL，可能会为我们节省一些带宽，但是在很大程度上，我们也应该只在实际应用程序中验证数据。多个安全级别通常会更好，但是请不要误以为，因为一开始我们就拥有(弱)防护措施，其余的都不会遇到问题。

如果我们不希望输入，请拒绝输入。

我们应该始终验证输入，并且肯定会丢弃超出预期范围的任何内容。如果我们已经知道URL实际上不会超出一定长度，那么在将其到达应用程序之前将其拒绝似乎是明智的。

我会说不。这只是虚假的安全性。只需做好编程，然后检查不良要求即可。应该足够了。

而且，这不是未来的证明。

是的。如果时间太长，我们确定要尽快将其拒绝。如果可以的话，请在它到达应用程序之前将其拒绝(例如，IISLockdown将执行此操作)。

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

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

如果我们知道有效的URL不能超过N个字节，那么这听起来像是一种无需过多努力即可快速拒绝跨站点脚本尝试的好方法。

我能看到的唯一可能引起问题的是，尽管今天URL永远不会超过N，但我们不能保证永远不会出现这种情况。而且在一年中，当我们回过头来进行修改以允许网址的长度为N + y时，我们可能会忘记修改网址拒绝代码。

使用它们之前，最好先验证一下URL参数。

验证请求中的内容比验证URL长度要好。

将来需求可能会发生变化，这时我们将不得不删除或者更改URL长度验证，可能会引入一些错误。

如果确实确实证明它是安全漏洞，则可以实施它。

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

如果我们确实确信N上的任何URL都是无效的，那么我们也可以拒绝它。但是，如果这是真的，并且输入验证的其余部分正确，那么以后无论如何它都会被拒绝。因此，此检查所做的所有工作都可能减轻了代码中某些其他错误所造成的损害。通常，花时间思考如何避免这些错误，而不是思考N可能是更好的选择。

如果我们确实检查了长度，那么仍然最好不要依赖代码其他地方的长度限制。这样做会使不同的检查更加紧密地结合在一起，并且如果我们更改规范并需要接受更长的URL，则很难更改下一个版本中的限制。例如，如果长度限制成为在没有适当注意和注意的情况下将URL放置在堆栈上的借口，那么我们可能正准备让某人跌倒。

好的，我们假设存在一个N。正如一个人指出的那样，长度超过N个字符的格式错误的URL仍将被其他输入验证拒绝。但是，在我看来，这为我们带来了全新的思考：

使用此常数，我们可以验证其他验证。但是，如果其他验证无法检测到某个URL无效，则该URL的长度超过N个字符，则此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个字符。"