解决ASP.NET网站中JavaScript的漏洞

引言

我想我可以代表很多开发者说，用黑客的眼光看待自己的应用程序并不总是容易的。当应用程序收到预期输入时，使其按预期工作很容易。编写代码并测试不正确但其他良性输入相对容易，因为这会在应用程序的正常流程中发生。但是，编写尽可能防黑客的代码迫使我们跳出流程，并且迫使我们不把任何事情想当然。不幸的是，恶意用户很容易使用JavaScript绕过一些常见的安全措施；但是，如果您知道可能发生的情况，您可以防止这些攻击。

不信任禁用的控件

我看到的一个常见错误是，如果您不希望用户更改值，则将控件禁用。我见过这在一个控件或页面的一整个部分上完成，但最终结果相同。用户将看到一个控件（可能是文本框或下拉列表），但无法更改该控件中的值。一个例子是，如果您正在构建一个电子商务网站，您的客户应该能够查看他们的订单，但他们只能编辑数量，而不是价格。但是，您希望管理员能够编辑价格，以防他们需要进行调整。为了能够更改价格和数量，您将这些值放入文本框中，但是您为管理员以外的所有人禁用了价格文本框。听起来很简单，不是吗？不幸的是，用户可以像您一样轻松地访问JavaScript。他们可以在地址栏中键入以下内容来启用文本框

javascript:void(document.getElementById('YourPriceTextBoxID').disabled = '')

现在文本框已启用，他们可以将其值设置为任何他们想要的值。如果您没有进行任何服务器端角色检查，您的客户只需按他们的价格购买任何他们想要的东西，而不是您的价格。这并不意味着您应该完全避免在JavaScript中禁用控件，但这意味着您应该在服务器上仔细检查所有值。

需要注意的是，按钮也不安全。您可以向页面添加JavaScript，仅当所有控件都填写完毕时才启用“保存”按钮，但您的用户可以像您一样轻松地启用该按钮。在这里，您还需要在服务器上仔细检查所有假设。

防止滥用ASP.NET验证器

ASP.NET框架包含验证控件，例如RequiredFieldValidator和RegularExpressionValidator，其中包含浏览器和服务器验证。由于客户端验证在大多数情况下都能很好地工作，因此很容易忘记也必须进行服务器端验证。为什么？如果浏览器关闭了JavaScript，则JavaScript验证不起作用。（这似乎应该是显而易见的，但这是开发人员经常忽略的事实。）您可能不知道的是，即使您强制用户启用JavaScript，他们仍然可以相对轻松地绕过验证器。为了了解原因，让我们看看ASP.NET在按钮的onclick事件中用于回发到服务器的JavaScript

Validation turned off: __doPostBack(/* arguments */);
Validation turned on: WebForm_DoPostBackWithOptions(/* arguments */);

换句话说，当不需要验证时调用函数__doPostBack；当需要验证时调用WebForm_DoPostBackWithOptions。如果黑客想要绕过您的JavaScript验证代码，他/她只需要手动调用__doPostBack('ButtonUniqueID', '')即可。幸运的是，此问题的解决方法很简单。ASP.NET会为您检查服务器上的所有验证器，您可以通过检查服务器上的Page.IsValid来查看所有测试是否通过。如果这是false，则表示一个或多个验证器失败，您应该采取相应的措施。

明智地使用AJAX

您还应该记住，您可以用来调试网站的所有工具，例如Firefox的Firebug和Internet Explorer的Fiddler，黑客也可以使用。这些工具可以用来惊人地轻松地找到您的验证和AJAX方法。据我所知，没有办法创建一个通过JavaScript函数可用的服务器方法，该方法仅在您需要时才可访问，并且仅仅希望恶意用户找不到您的函数不是一个好主意。您在这里能做的最好的事情是

1. 限制可从Web服务和AJAX方法访问的数据
2. 如果您使用某种身份验证，请在每次调用时检查用户的权限

结论

不幸的是，结论是不信任JavaScript执行任何重要操作。如果您允许他们，恶意用户可以使用JavaScript相当轻松地调用您创建的任何方法，查看您返回的任何数据，或绕过任何浏览器特定的安全措施。让您的网站安全最佳方法是假设页面调用的任何JavaScript都可能随时被破坏，并在返回服务器后检查每个重要值。

历史

• 2009 年 9 月 8 日：初始发布