停止 ASP.NET 中的整数溢出答案

【问题标题】：Stopping integer overflow in ASP.NET停止 ASP.NET 中的整数溢出
【发布时间】：2011-07-29 19:50:30
【问题描述】：

我们在工作中使用 Acunetix 对我们的应用程序进行安全扫描。最近我们在下面遇到了以下整数漏洞错误：

据我所知，报告似乎告诉我们，我们没有在查询字符串中停止integer overflow attacks。虽然我们确实使用最终解析为整数的查询字符串，但在我们使用它们之前，它们首先被加密，然后使用Convert.ToInt32() 解密并转换为 int。我知道我们应该改用TryParse()，但是即使黑客要输入一个高于最大值的整数值，他们在尝试解密甚至尝试转换为整数之前也会失败，这就是整数溢出发生的地方我的想法。那是除非解密失败时发生错误？

我对此感到很困惑，而且谷歌搜索并没有太大帮助，因为大多数与非托管语言（如 c++）有关，而不是 c# 和 asp.net。任何帮助将不胜感激。

【问题讨论】：

IMO，这是自动扫描失败的地方。与此类似，ReSharper 报告了许多警告和错误，熟练的开发人员都知道这些事情无需担心。根据您的解释，您已被覆盖。
除非您的加密是 HMAC 签名的，并且您在解析广泛公开的输入之前验证摘要。加密本身不会检测/防止篡改。

标签： c# asp.net security integer-overflow .net-security

【解决方案1】：

我不认为这是一个整数溢出漏洞，我怀疑它指的是整数，因为这是在查询字符串中被操纵的类型（尽管我知道你说它们是加密的）。如果您正在将不受信任的用户输入直接转换为整数而不是首先验证类型（如您所说，首先尝试解析它），您可能会抛出一个内部错误（缺少任何尝试/捕获）和这就是他们可能会接受的。

自动扫描器对 HTTP 500 错误有点疯狂。他们不知道幕后实际发生了什么以及错误的严重程度，因此您可以辩称这是误报。另一方面，您的安全人员会争辩说，如果机器人发现您经常因为操纵查询字符串而抛出这些错误，那么容易返回 HTTP 500 的网站更有可能被进一步探测。

简单的答案：“所有输入都必须根据可接受值范围的白名单进行验证。”（来自here）。

【讨论】：