This week, we have a report revealing that the manufacturing industry experiences more API-related incidents than other industries. To follow, we have two guides for developers: the first describes the REST protocol and common API vulnerabilities, and the second prescribes best practices for secure API design. Finally, we have a fun read on cracking API tokens with Azure compute resources.
Article: Manufacturing industry seeing more API incidents than other industries
A recent report surveying 600 UK and USA CISOs and cybersecurity professionals reveals that the manufacturing industry experiences more API security incidents than other industries. The headline figures make for some eye-opening reading โ on average, enterprise organizations have over 15 000 APIs, and on average, the respondents indicated that three-quarters of them had experienced an API-related incident.
The report surveyed six industry sectors: financial services, retail and eCommerce, healthcare, government and public sector, manufacturing, and energy and utilities. Of these, manufacturing had the highest occurrence of API incidents (79%), was the least likely to deploy an API security platform (less than 30%), and conducted the least frequent API security testing.
Intuitively, it stands to reason that manufacturing would be a laggard: they operate in a very heterogeneous environment, with many disparate and legacy systems, and due to economic pressures to run 24/,7 there may not be an opportunity to test or upgrade systems.
The report highlights a common concern in the industry: incomplete API inventory. Over three-quarters of respondents in the manufacturing industry revealed that they do not have an accurate idea of their current API inventory. This fact alone exposes them to significant and unquantifiable risks.
Guide: REST API security vulnerabilities deep dive
Next up is the first of two guides on developing secure APIs we have this week. In this one, Santosh Shinde (@shindesan2012) describes the REST protocol in some depth and then takes a deep dive into the OWASP API Security Top 10 vulnerabilities.
The guide is written from a developer’s perspective, rather than an attacker’s. I liked how the author presented each vulnerability and explained the root cause and how to handle them in code. For example, the description of BOLA is shown below:
Thanks to Santosh for contributing this guide which will, I’m sure, be useful to developers getting their first exposure to the world of API security.
Guide: Best practices for secure API design
Picking up where the first one left off, in our second guide by Pedro Aravena (@OPedroAravena) gives a fantastic ten-step guide to building secure APIs, starting with design and ending with, of course, API security.
I loved this guide โ it’s clearly written by someone with a wealth of experience on the topic. This guide will be most valuable to API architects or system designers, but there is something for everyone in here, from API versioning, to clean architecture and pagination.
Thanks to Pedro for this great guide.
Article: Using Azure to crack API tokens
Finally this week, we have an entertaining read from Dan Epp (@DanaEpp) on the feasibility of cracking API tokens with Azure compute resources.
Epp attempts to crack the JWT signing key captured during a session with the vulnerable API application crAPI,ย and uses the popular hashcat tool to brute force the JWT on a standard desktop. Given the strength of the algorithms used and a key of any reasonable length, its likely that a successful attack could take decades โ obviously, this is totally impractical.
However, Epp happens to be a Microsoft Security MVP, so has the good fortune to have access to Azure resources. He describes how to use an Azure VM with a suitable GPU, such as the NCv3-series virtual machine which gives the optimal cost/performance ratio for cloud cracking. To demonstrate, Epp cracked the signing key for crAPI in under a minute at an estimated cost of $1 โ however, this was only a 5-character key.
Obviously, in the real world, it is unlikely (although not impossible) to find such short signing keys. Epp gives the following estimates for longer keys:
- 6 chars: ~14 min
- 7 chars: ~1 day
- 8 chars: ~100 days
- 9 chars: ~23 years
As ever, the standard recommendation applies: use the largest possible key and the strongest algorithm.
Event: Defending APIs with Jim Manico
Join Jim Manico, CEO of Manicode, and Colin Domoney from 42Crunch, as they deliver a 2-part webinar series to help developers better defend APIs.
Episode 1: Request Forgery on the web – SSRF, CSRF & Clickjacking
In this first episode, Jim and Colin will discuss request forgery and how to prevent it. This technical talk is intended for the software developer who needs to build secure web applications and APIs. It will cover three main topics: CSRF, SSRF, and clickjacking.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
