我正在开发一个应用程序，并且网址格式为www.example.com/some_url/some_parameter/some_keyword。我在设计上知道这些URL有一个最大长度（并且仍然有效）。我应该为每个请求验证URL长度，以防止缓冲区溢出/注入攻击吗？我相信这是显而易见的，但我不是安全专家，所以也许我错过了一些东西。
答案 0 :(得分：5)
如果你不期待那个输入，请拒绝它。
您应该始终验证您的输入，并且当然会丢弃超出预期范围的任何内容。如果你已经知道你的网址真的不会超过一定的长度，那么在它到达应用程序之前拒绝它似乎是明智的。
答案 1 :(得分：5)
深度防御是一个很好的原则。但虚假的安全措施是一个不好的原则。差异取决于很多细节。
如果您确信N上的任何网址都无效，那么您也可以拒绝它。但如果这是真的，并且如果您的输入验证的其余部分是正确的，那么它将在以后被拒绝。因此，所有这些检查确实可能减轻代码中其他一些错误所造成的损害。花费你的时间思考如何避免这些错误通常比考虑N可能是什么更好。
如果确实检查了长度，那么最好不要依赖代码中其他地方的长度限制。这样做可以将不同的检查更紧密地结合在一起，如果您更改规范并需要接受更长的URL，则更难以在下一版本中更改限制。例如，如果长度限制成为在没有适当注意的情况下将URL放在堆栈上的借口，那么您可能会设置某人摔倒。
答案 2 :(得分：1)
您如何确定
答案 3 :(得分：1)
我能看到的唯一可能导致问题的是，虽然今天您的网址永远不会超过N，但您无法保证永远不会出现这种情况。在一年内，当您返回进行编辑以允许网址长度为N + y时，您可能会忘记修改网址拒绝代码。
在使用之前，最好先验证网址参数。
答案 4 :(得分：1)
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。但是，较长的网址可以使用。我在100,000个字符后停止测试。
Safari（浏览器） - 至少可以使用80,000个字符。“
答案 5 :(得分：0)
我认为这可能会给你一些安全性，如果人们给你发送疯狂的长URL，可能会为你节省一些带宽，但在很大程度上你应该只是在实际应用中验证你的数据。多级安全性通常更好，但不要错误地认为，因为你在开始时有一个（弱）保护措施，你不会遇到其他问题。
答案 6 :(得分：0)
我会说不。这只是虚假的安全。只需编程好并检查您的不良内容请求。这应该足够了。
此外，这不是未来的证明。
答案 7 :(得分：0)
是。如果它太长而且您确定会尽快拒绝它。如果可以，请在它到达您的应用程序之前拒绝它（例如IISLockdown将执行此操作）。
请记住考虑字符编码。
答案 8 :(得分：0)
比检查长度更好，我认为你应该检查内容。您永远不会知道将来如何使用您的URL架构，但您始终可以清理您的输入。简单地说一个非常复杂的事情：不要相信用户提供的数据。不要直接把它放到数据库查询中，不要eval（）它，不要把任何事情视为理所当然。
答案 9 :(得分：0)
如果您知道有效的网址不能超过 N 字节，那么这听起来是一种快速拒绝跨站点脚本尝试而不需要太多努力的好方法。
答案 10 :(得分：0)
最好验证请求中的内容，而不是验证网址长度。
您的需求将来可能会发生变化，此时您必须删除或更改URL长度验证，否则可能会引入错误。
如果它最终成为经过验证的安全漏洞，那么您可以实施它。
答案 11 :(得分：0)
好的，我们假设这样的N存在。正如onebyone指出的那样，长度超过N个字符的格式错误的URL无论如何都会被其他输入验证拒绝。然而，在我看来，这开辟了一个全新的思路：
使用此常量，您可以验证其他验证。但是，如果其他验证无法将某个URL检测为无效，则该URL长于N个字符，则此URL会触发错误并应进行记录（也许整个应用程序应该关闭，因为它们可能会创建一个无效的网址足够短。）
答案 12 :(得分：0)
哦，我的，很多答案，很多好点，但是如此分散，所以让我试图巩固所有这些。 tl; dr imo，这对于应用程序层代码来说太低了。
是的，URL可以是任何长度，但实际上浏览器有限制。当然，这只会保护您免受基于浏览器的攻击，因为那些愿意将自己限制为这些向量的人，所以您确实需要一些方法来处理主动攻击尝试。
好的，它可以防止缓冲区溢出。好吧，只有当你在低水平工作而不考虑这些问题时。如今，大多数语言都支持字符串，并且不允许它们溢出。如果您正在处理一些非常低级别的系统，实际上将数据作为字节读取并将其放入“＆＃39;字符串”中。类型，然后肯定，你应该有一些方法来检测和处理这个，但它并不难分配内存，并一次传输已知的数量，只是跟踪你留出多少内存。坦率地说，如果你正在处理那个低级别，你真的应该使用别的东西。
好吧，那么基于字符串长度拒绝呢？主要的回归是虚假的安全感。也就是说，代码的某些区域可能会变得“邋”“。并且容易受到你试图避免的漏洞的攻击。你必须要小心确保这个全球性的＆＃39;限制实际上是足够的，但考虑到你的URI格式，你可能有这些＆＃39;部分＆＃39;报告它们的最大长度是什么，并对长度检查进行集中检查（对于整个字符串及其组成部分）;至少这种方式，如果一个部分需要允许更长的字符串，则更容易处理更改。
这当然有一些优点，因为它可以很快地比较字符串的长度并立即拒绝请求......但不要忘记做得好的＆＃39;网站，你应该发回一个正确的答案，解释为什么服务器拒绝这个。但在实践中，你是否真的认为你将不得不处理这些类型的错误＆＃39;网址，肯定会在很多其他方面出错。
出于某种原因，你觉得你不想说你正在使用什么语言。像Java或Python这样的高级语言有一些非常好的库用于处理Web内容＃39; Java将允许您指定URI的模式，包括使用该模式的正则表达式，因此如果您想在URL中使用名称，则可以使用@Path("/person/(.{0..100}")之类的内容将参数限制为100个字符。如果像Ruby或Python这样的人没有相同的东西，我会感到惊讶，他们喜欢将自己宣传为漂亮的“webby＆＃39;语言。
最后，无论长度如何，都需要验证许多事物，而不仅仅是长度。不必担心导致缓冲区溢出的URI的长度是一个非常低级的事情，并且需要非常通用，即需要处理任何请求，即使是具有1GB URI的请求也是如此;请注意我说＆＃39;处理＆＃39;不接受将其传递给应用程序层，它可以在低级别拒绝它，也可能触发系统事件。