使用 JQuery Ajax 和 ASP.NET Generic Handlers 时必须采取的 XSS 和 CSRF 预防以外的安全措施

Question

我是一名纯 ASP.NET 开发人员，使用工具箱控件创建网站。但是当我研究并发现使用纯 JS/JQuery 和通用处理程序创建的应用程序更具吸引力、用户吸引力和性能更快时，我研究了它们。现在我正在创建一个纯粹基于 JS 业务逻辑的网站并使用 ASP.NET 处理程序访问数据库。我使用 ASPX 页面作为开始，这样捆绑和路由等功能将由这些页面完成，我的开发速度会更快。

当我在思考可以使用 JavaScript 进行的攻击时，我发现 XSS 和 CSRF 是两种可以通过纯 JavaScript 进行的攻击。我通过清理传输到服务器的文本来防止 XSS 攻击。并且通过使用 CSRF 令牌并将其保存到 cookie 并将该 cookie 值与通用处理程序中的 Ajax 请求中的令牌进行比较来防止 CSRF 攻击。而且这两个都运行良好。

但后来我开始考虑我可能在应用程序中留下的任何其他漏洞。然后一个场景出现在我的脑海中。以下是场景：

由于 JS 文件都是公开可见的，假设有一个函数saveData(data) 将要保存在数据库中的数据和一个 CSRF 令牌发送到 Generic Handler。现在假设攻击者通过使用 chrome、opera、IE 等浏览器的 Inspect Element Feature 调用此函数，并且 注入如下链接：

<a href="#" onclick="saveData('IHackedYou')">Hack</a>

现在，当他点击这个注入的“Hack”链接时，saveData() 函数会将“IHackedYou”和 CSRF 令牌（因为它存储在 JS 文件中的全局变量中）发送给 Handler。处理程序将授权此请求，因为 CSRF 令牌与 cookie 的令牌相同，并且会将不需要的数据存储在数据库中，如果攻击者手动单击链接一千次（或更多）或使用某些自动化系统，情况会变得更糟。这将杀死我的数据库服务器。

所以我想问一下这是什么类型的攻击，应该如何预防？

Answer 1

不要依赖客户端验证

在客户端完成的所有事情都必须在服务器端进行检查。这不是什么新鲜事，即使在没有 javascript 的情况下也适用。假设以下纯 html 表单：

<form>
  <select name="fruit">
    <option value="banana">Banana</option>
    <option value="apple">Apple</option>
  </select>
</form>

如果您不期望“香蕉”或“苹果”以外的任何其他内容，则必须在服务器端检查它，因为恶意用户很容易注入另一个值。

你的例子也是同样的逻辑。您的函数saveData 将以某种方式（ajax 调用、websocket 或任何方式）与服务器通信。所以如果 'IHackedYou' 不是一个有效的输入，服务器必须检查它并抛出一个错误。

不要相信客户端计算值

假设您正在编写一个包含大量 JavaScript 逻辑的商店网站。您可能会有一个购物车对象，例如：

{
  "products": [
    {"name": "banana", "price": 2.0, "quantity": 1},
    {"name": "apple", "price": 3.0, "quantity": 2}
  ],
  "totalPrice": 8.0
}

一旦用户提交了他的命令，就很想直接使用客户端计算的totalPrice，但从不这样做。 totalPrice 只能在客户端使用，以改善用户体验。

有时它真的很烦人，因为您必须重新实现相同的逻辑客户端和服务器端，这也是 JavaScript 服务器端解决方案如今变得流行的原因之一。