阻止 ASP.NET 中的整数溢出
我们在工作中使用 Acunetix 对我们的应用程序进行安全扫描。最近，我们遇到了以下整数漏洞错误：
据我所知，报告似乎说明了这一点我们不会阻止整数溢出查询字符串中的攻击。虽然我们确实使用最终解析为整数的查询字符串，但在使用它们之前，它们首先被加密，然后使用 Convert.ToInt32() 解密并转换为 int。我知道我们应该使用 TryParse() 来代替，但即使黑客输入高于 max 的整数值，在尝试解密之前甚至尝试转换为整数之前，他们也会失败，即在我看来，整数溢出会发生在哪里。那除非解密失败时发生错误？
我对此感到非常困惑，谷歌搜索并没有多大帮助，因为大多数搜索都与非托管语言（如 c++）有关，而不是与 c# 和 asp.net 相关。任何帮助将不胜感激。
We use Acunetix at work to do security scans on our applications. Recently we came across the following Integer Vulnerabilities error below:
From what I can tell, it looks like the report is telling us that we are not stopping integer overflow attacks within querystrings. While we do use querystrings that eventually resolve to integers, they are first encrypted and then decrypted and converted to int using Convert.ToInt32() before we use them. I know that we should use TryParse() instead, but even if a hacker were to enter an integer value higher than max, they would fail when trying to decrypt before even trying to convert to integer, which is where the integer overflow would occur in my opinion. That is unless the error happens when the decryption fails?
I'm pretty confused about this and google searches haven't been much help as most pertain to unmanaged languages like c++ rather than c# and asp.net. Any help would be much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不认为这是一个整数溢出漏洞，我怀疑它指的是整数，因为这是在查询字符串中被操纵的类型（尽管我知道你说它们是加密的）。如果您正在将不受信任的用户输入直接转换为整数，而不是首先验证类型（正如您所说，首先尝试解析它），您可能会抛出一个内部错误（缺少任何 try/catch）并且这就是他们可能会注意到的。
自动扫描仪对 HTTP 500 错误有点疯狂。他们不知道幕后实际发生了什么以及错误有多严重，因此您可以认为这是误报。另一方面，您的安全人员会争辩说，如果机器人发现您经常因操纵查询字符串而抛出这些错误，那么很容易返回 HTTP 500 的网站更有可能受到进一步探测。
简单回答：“所有输入都必须根据可接受值范围的白名单进行验证。”（来自 此处）。
I don't think this is an integer overflow vulnerability, I suspect it refers to integers as this is the type that has been manipulated in the querystring (although I know you said they were encrypted). If you're doing a direct conversion of untrusted user input to an integer and not first validating the type (as you say, TryParse it first), you're probably going to throw an internal error (short of any try/catches) and this is what they're likely picking up on.
Automated scanners go a bit nuts over HTTP 500 errors. They don't know what's actually happening under the covers and how severe the error is so you could argue that it's a false-positive. On the other hand, your security folks will argue that websites readily returning HTTP 500 are more likely to be probed further if a bot picks up that you're regularly throwing these errors out as a result of manipulated querystrings.
Easy answer: "All input must be validated against a whitelist of acceptable value ranges." (from here).