防止 Javascript 中的 AJAX 泛洪
我的网站有一个 Javascript 方法，可以发出 AJAX 请求将商品添加到购物车，而无需重新加载页面并发出简单的通知。
AddToCart()
然而，使用任何 Javascript 控制台，我发现您可以用一个简单的语句淹没此请求：
while (true) {AddToCart()}
并最终锁定服务器直到浏览器崩溃。更稳定的浏览环境甚至可能无限期锁定服务器。那么防止这种尝试的最佳方法是什么？
My site has a Javascript method that makes an AJAX request to add an item to cart without reloading the page and making a simple notification.
AddToCart()
However, using any Javascript console, I found you can flood this request with a simple statement:
while (true) {AddToCart()}
And eventually lock the server until the browser crashes. A more stable browsing environment could probably even lock the server indefinitely. So what would be the best way to protect against such an attempt?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
也许您应该在私有命名空间中定义该函数？
这样你就无法通过控制台引用它。
这当然并非万无一失，因为任何人都可以复制代码或向 URI 发出 HTTP 请求。
您无法停止 HTTP 请求，但您可以通过实现 CSRF 令牌来停止页面处理数据，这样除非 CSRF 令牌匹配，否则页面不会进行繁重的处理，CSRF 令牌是从基于变量创建 CSRF 的页面生成的像时间戳之类的，所以它不能（容易？）复制。
Perhaps you should just define the function in a private namespace?
That way you can't reference it through the console.
This of course is not bulletproof as anyone could just replicate the code or make HTTP requests to the URI.
You can't stop the HTTP requests but you can stop the page processing data possibly by implementing CSRF tokens so that it won't do the heavy processing unless the CSRF token matches, which is generated from your page which creates the CSRF based on variables like timestamp and such, so it can't be (easily?) reproduced.
他们可以使用具有高并发值的
ab（Apache 基准）造成更大的损害，或者他们可以只是坐在那里按 F5。您需要一个较低级别的解决方案 - 速率限制（可能通过 IP）或一次性哈希，或任意数量的其他解决方案。They could do much more damage using
ab(Apache benchmark) with a high concurrency value, or they could just sit there hitting F5. You need a lower-level solution - rate limiting, by IP perhaps, or a one-use hash, or any number of other solutions.服务器有很多方法可以保护自己免受恶意客户端的侵害。在这种特殊情况下，“速率限制”可能是合适的，即服务器从客户端选择其认为对人类操作合理的每分钟最大操作数，并且当一个客户端的操作速率超过它保护自己的速率时。它选择如何保护自己取决于。它可能会立即使每个新请求失败一段时间，以防止使用许多服务器资源，它可能会注销客户端，它可能会静默失败或返回错误。
服务器应该知道，针对此类事情的真正保护必须在服务器上完成，因为 ajax 调用可以由任何人完成，而不仅仅是您自己的客户端代码。
在客户端，您可以通过多种方式防止恶意 JavaScript 注入。在代码的下方，您还可以实施速率限制（就像在进行实际的 ajax 调用之前）并拒绝每分钟执行超过 X 个 ajax 调用。这并不能完全保护您的服务器，但可以保护您免受以这种方式使用您自己的 AddToCart() 函数的影响。
或者，您可以这样做，这样就没有不需要可以通过这种方式调用的参数的顶级全局命名空间函数。您可以通过从全局命名空间中删除相关功能（使其成为需要正确的“this”指针的对象之一上的方法）来实现此目的，或者您可以使该函数需要一些并不总是相关的内部状态已知。
就我个人而言，我并不认为客户需要受到保护，免受其所有者可能施加的虐待，因为除了造成混乱之外，所做的事情没有任何合法目的。如果用户想做坏事导致自己的客户端崩溃，那也没关系。如果他们愿意，他们可以使用任务管理器来打倒客户。您确实希望保护它免于向您的服务器喷洒不良内容，并保护它免受合法正常用户操作可能发生的任何不良影响，但如果用户想要关闭自己的客户端，我不会因此而失眠那。
There are lots of ways that servers protect themselves from rogue clients. In this particular case, "rate limiting" is probably appropriate where the server selects a maximum number of operations per minute from the client that it thinks it reasonable for a human to operate and when the rate of operations from one client exceeds that it protects itself. How it chooses to protect itself depends. It might immediately fail each new request for awhile to keep from using many server resources, it might log the client out, it might fail silently or return an error.
Servers should know that real protection against this type of thing has to be done at the server because ajax calls can be done by anyone, not just your own client code.
On the client, you could protect from rogue javascript being injected a number of ways. Down lower in your code, you could also implement rate limiting (like right before you make the actual ajax call) and refuse to carry out more than X ajax calls per minute. This doesn't fully protect your server, but protects you from your own AddToCart() function being used in this way.
Or, you could make it so there is no top level global namespace function that requires no parameters that can be called this way. You could do this either by removing the relevant functionality from the global namespace (make it a method on one of your objects that requires a proper "this" pointer) or you could make the function require some relevant internal state that wouldn't always be known.
Personally, I don't really fell like a client needs to be protected from abuse that its owner might inflict on it when there's no legitimate purpose for what's being done other than to cause mayhem. If the user wants to do bad things that crash their own client, that's fine. They can bring down the client with task manager if they want. You do want to protect it from spraying your server with bad stuff and protect it from anything bad that might happen with legitimate normal user operations, but if the user wants to take down their own client, I'm not going to lose any sleep over that.
请求就是请求，无论是否使用 AJAX。相同的规则适用于常规 DOS 攻击。即使没有 AJAX，也没有什么可以阻止人们直接调用您的 URL。
A request is a request, AJAX or not. The same rules apply for a regular DOS attack. There's nothing to stop people from calling your URL directly, even without AJAX.
有人足够聪明地找出您的代码，打开浏览器的控制台，然后输入
while (true) {AddToCart()}甚至不需要浏览器（或您的代码） - 他们只需执行 < code>wget 无限循环，或者如果目标确实是 DoS，请使用 脚本< /a> 为此目的。在服务器端，您正在处理如何减轻拒绝服务攻击。有很多策略；我首先想到的是使用 Nginx 反向代理。
Someone clever enough to figure out your code, open their browser's console, and type
while (true) {AddToCart()}doesn't even need a browser (or your code) – they could just executewgetin an infinite loop, or if the goal is really a DoS, use a script for that purpose.On the server side, you're dealing with how to mitigate a denial of service attack. There are many strategies; using the Nginx reverse proxy is the first that popped into my mind.
您可以做的一件事是让
AddToCart函数仅在请求尚未执行时执行请求。另一个认为你可以做的就是混淆代码（有工具可以做到这一点，搜索 javascript 混淆），所以它不明显什么方法做什么。
这两种方法会有所帮助，但不能完全解决问题。服务器确实需要检测是否收到来自某个客户端的垃圾邮件请求，并通过速率限制器来限制它们。
One thing you could do is make the
AddToCartfunction only do the request if one is not already in progress.Another think you can do is obfuscate the code (there are tools to do this, do a search for javascript obfuscation) so its not obvious what method does what.
Those two methods will help, but won't solve the problem entirely. The server really needs to detect if its getting spammed with requests from one client and limit them, via a rate limiter.