Content
Account takeover attacks are challenging to defend against, because threat actors can use a wide variety of methods to wage them. Therefore, as we’ve been discussing in this four-part series of articles, robust protection against account takeover fraud requires a variety of measures.
The first article discussed the types of ATO attacks, and briefly described the ways in which ATO attempts can be detected. In Part 2, we explored multi-factor authentication, showing why it’s so important in the current threat environment. Then in Part 3, we discussed how to defeat phishing attacks, which are still a very popular vector for ATO.
Now in this fourth and final article, we’ll examine a vital but often under-appreciated tool for ATO defenses: rate limiting. We’ll discuss:
- What rate limiting is
- Why it’s important for protecting against ATO
- And which rate limiting features to look for in a web security solution. (Many solutions offer rate limiting, but few offer fully-featured rate limiting capabilities.)
What is rate limiting?
A robust WAAP (Web Application and API Protection) solution will monitor the rate at which clients submit requests to the protected backend environment. When a particular traffic source sends too many requests within a defined time period, that traffic source can be blocked from further access for a specified length of time.
Note that this definition refers to traffic sources, and not merely to IP addresses. Although many web security solutions only provide IP-based rate limiting, this is inadequate for full protection against ATO fraud. This approach will not detect threat actors who rotate IPs, which is a common practice today; attackers often try to orchestrate their ATO campaigns in various ways to avoid detection. More on this below.
Why is it important for protecting against ATO?
We have previously discussed why rate limiting is a vital part of modern web security. There are a variety of web threats that can be difficult to mitigate without it, usually because the individual requests appear to be benign and thus do not activate other threat-detection methods. For example, a DDoS assault can consist of apparently legitimate requests sent in overwhelming numbers, while an inventory denial attack can masquerade as a crowd of potential customers who are interacting with an ecommerce or travel site.
Several vectors of ATO attacks fall into this category. For example, a popular web application will commonly experience failed login attempts from legitimate customers. Therefore, unless rate limiting is in place, a brute-force credential stuffing attack could easily go unnoticed. (And even if multi-factor authentication were in place and prevented any of the login attempts from succeeding, a high-volume credential stuffing attack could still act as a form of DDoS and impact the performance of the targeted servers.) Conversely, the login API could be protected by a rate limit of 10 requests per minute, with an autoban period of one hour. Without the rate limit, bad actors could submit thousands of requests per hour; with it, only ten.
Therefore, rate limiting is an important part of ATO defenses. It can block some threats that could otherwise go undetected, and can even mitigate the impact of unsuccessful attacks.
Rate limiting features to look for in a web security solution
Many web security solutions offer rate limiting features. We’ve covered some of them before, for example in our article on rate limiting capabilities of the major cloud providers.
However, most solutions being offered today don’t include all the features necessary for robust protection against ATO. When comparing solutions, here are the most important features to consider.
Flexible response options. When a rate limiting policy is violated, the security solution should offer a range of possible responses. Along with blocking the violator, other useful options are to verify that the user is human, pass the request while tagging the response in the logs, pass while flagging the request for real-time monitoring, pass while adding a header for the upstream server to process, return custom codes to the client, and others.
Granular policy enforcement. Once a rate limiting policy is configured, admins should be able to specify where it is enforced. An admin should be able to enforce it globally, limit its enforcement to an individual path or URL, or any scale in-between. Also, admins should be able to specify situations where the policy will be bypassed, for example when a traffic source is whitelisted, or the requests have certain defined characteristics (specific headers, cookies, arguments, etc.).
Easy to manage. Admins should be able to easily configure rate limiting policies, activate/deactivate them, and when desired set them into report-only mode (where violations are logged and reported, but responses are not triggered).
Consistent traffic source identification. Most security solutions rate-limit according to IP address, but as noted earlier, this can be bypassed merely by rotating IPs (which hackers commonly do). A robust solution will be able to track and rate-limit unique clients even as they change IPs.
Flexible options for defining “clients”. In typical usage, rate limiting will be applied to individual clients, i.e. individual requestors. However, in some situations, admins will want to rate-limit according to other criteria. A full-featured security solution should support rate-limiting according to geolocation, session IDs (the composition of which the admin should be able to define), user IDs, headers, cookies, arguments, and more.
Event-based rate limiting. It isn’t enough for a solution to restrict excessive requests from clients. Often, an admin will want to restrict the rates of allowable events instead. For example, a client that logs into a web application and then changes ASNs several times within an hour is extremely anomalous and should trigger some sort of response, even if the number of requests is reasonable. Admins should be to define rate-limitable events according to a variety of criteria: any combination of headers, cookies, arguments, and so on.
Autobanning. Many security solutions offer simple rate limits that can be summarized as follows: “when a client submits too many requests, block them for a defined period of time.” This is useful in some situations, but is insufficient overall.
For example, let’s say access to a login form is rate-limited to four requests per minute. An attacker tries to brute-force the login, and sends one request per second. The first four requests will be allowed, while the next 56 requests will be blocked. However, after the minute has passed, the rate limit resets, and the attacker will be allowed another four attempts before being temporarily blocked again. This cycle can continue for as long as the attacker wishes. In effect, the rate limit is not preventing the attack; it is merely slowing it from 60 attempts per minute down to four attempts per minute.
A good security solution will offer autobanning: a second layer of defense, based on the triggering of rate limit policies. Admins should be able to configure the solution so that when a client violates a rate limit several times, that client will automatically be banned, and all its requests refused, for a defined length of time.
Conclusion
In the current threat environment, rate limiting is a crucial capability for effective protection. It can detect many threats that can evade other security technologies.
Rate limiting is especially important for defeating ATO attempts, since ATO attacks often consist of a series of individual requests that otherwise seem benign. However, while many security solutions claim to offer rate limiting, many of them are not fully-featured, and cannot provide the flexibility and full protection that is necessary today.
Link11 offers a cloud native, fully managed WAAP platform that includes advanced rate limiting, with all the features described above, and more. It is a complete web security solution, providing not only rate limiting but also next-gen WAF, DDoS protection, bot management, API security, and more.
Share this post
