Blog, Events & News
Attack Vectors Part Three: API Attacks
In the previous two blogs, we described how attackers modify their attack vectors where the return on the investment against the cost of the attack is worthwhile. Exploiting widely used business logic, the attacker will attempt to circumvent any mitigation on the website with an ever-evolving toolset causing attack vectors and API attacks.
APIs are used across many websites to provide data to mobile applications, point of sale systems and countless other endpoints. With the increasing deployment of microservice architecture and Customer Identity Access Management (CIAM) many eCommerce and financial services websites hive off the authentication of website users to these applications, either built in-house or bought.
This makes the API a very attractive attack vector for a perpetrator looking to validate stolen credentials or take advantage of previously validated accounts.
Why attack an API?
APIs operate differently to traditional methods of ‘on-site’ user authentication. Attacks against API endpoints also require less complexity since APIs, by their very design, are well documented and open to consumers. We’ll pick back up on their open and highly vulnerable nature shortly.
Attackers will always look for the easiest point of entry, and from their point of view the API gives them the following advantages:
- They are stateless. One authentication request looks very much like another request
- Where the API is only used for authentication then it is easy to hide authentication requests in the background noise of a busy website
In short, APIs cannot detect, prevent or respond to automated attacks and are relatively simple to breach.
At Netacea we have mitigated significant numbers of attacks on ‘main’ websites only to see the attacker move the attack vector directly to an API that will allow for validation of stolen credentials.
Mitigating API attacks
API traffic is, by its nature, forced to follow a strict pattern of behaviour. Baselining ‘normal’ traffic patterns is relatively straightforward.
The above graph shows a few days of traffic running over an API, split by geographic location. It is pretty clear from this what the ‘normal’ traffic is, and what the attack traffic is. The blue line with consistent spikes is traffic from the UK, this company’s target market. The green line is a surge from Russia, which is then followed by a more distributed attack.
API security, Open Banking & PSD2
APIs are used by organisations across a whole host of industries, most notably in financial services as a result of the UK’s Open Banking and the EU’s PSD2 legislations. To comply with each, banks must implement APIs for sharing data with third-party providers (TPPs), literally opening-up their customer data to approved TPPs, with the view to revolutionising financial services through innovation and competition.
Banks need to work with their eyes wide open here. As we’ve discussed, APIs are an attractive target for attackers due to their fundamental breathability, and what finer target than an API used to share data between banks and TPPs? Establishing a secure environment is vital to keep all interconnected parties secure.
Securing your API with Netacea
The traffic hitting your API may not be as distinct as that shown in fig. 1, or observe the same patterns, but at Netacea we have significant experience in mitigating a whole variety of threats made to different APIs and have an array of ways in which we could protect yours. There will always be anomalous behaviour that our machine learning algorithms will identify as malicious traffic and mitigate.
website being exploited by bots?
Access the full series:
Read Attack Vectors Part One: The Classic Approach
Read Attack Vectors Part Two: Evolving Threats