In a follow-up to our recent blogpost which explored the OWASP API Authorization risks, this week we share highlights of our webinar which featured Philippe De Ryck and Isabelle Mauny talking about the Authentication challenges encountered when protecting your APIs.
They explored just how potentially dangerous the combination of the two OWASP API Top 10 categories of Broken Authentication and Unrestricted 
Resource Consumption can be when an API endpoint is compromised and no rate limiting is implemented.
The Broken Authentication risk relates to poorly implemented API authentication which enables attackers access to or to assume other users’ identities to attack endpoints. Unrestricted Resource Consumption relates to where the API is not protected against an excessive amount of calls or payload sizes. Philippe highlighted how dangerous it can be when broken authentication is combined with a brute force attack on the forgot password functionality to enable unrestricted resource consumption. He cited the example of the smart weighing scale app vulnerability where no rate limiting restrictions were applied to the forgot password functionality which would allow attackers to effectively brute-force the six-digit code reset feature using a tool such as Burp Suite.
In essence, this was a straightforward attack which could be compounded ten-fold with an account enumeration vulnerability where the endpoint discloses whether an account exists or not. Now an attacker could probe the API using lists of email addresses to determine which addresses had been registered, conduct an account takeover and easily access potentially vast amounts of sensitive personal data. Such an enumeration vulnerability amplifies the risk and it is not a trivial matter to perform rate limiting when endpoints are unauthenticated as part of the attack e.g. when a user forgets their password, they are not authenticated.
Scale API Endpoint Protection to Counter Brute Force Attacks
Isabelle then demonstrated how with the 42Crunch API security platform companies are able to scale the enforcement of rate-limiting policies across authorization and authentication API endpoints wherever they may reside. Rate limiting is enforced within the firewall, not the API itself. This policy is implemented in the IDE (VS Code example in the diagram below) and deployed in the CI/CD pipeline (Azure DevOps example in the diagram below) to scale.
42Crunch API security testing and protection architecture example with VS Code and Azure DevOps
42Crunch enforces rate limiting on every single request hitting the API
Avoid JWT Pitfalls – Only Accept What You Expect
Next up was the combination of Broken Authentication with Security Misconfiguration. Security misconfiguration not only exposes sensitive user data but also system details that can lead to full server compromise. JSON Web Tokens or JWTs are identified as being in widespread usage to implement custom security mechanisms, but that they also lie at the heart of numerous API security failures, in particular features such as authentication and authorization.
Philippe quoted the example of the Apache Pulsar bug which permitted account takeovers due to a JWT vulnerability, namely the signature of the token was not validated if the algorithm of the presented token was set to “none”. This is known as the alg:none problem and was well documented at the time.
The IETF best current practices’ memo for JWT (Request for Comments RFC: 8725) recommends that companies should adopt an approach to using JWT and this includes favoring that the tokens are signed by a specified cryptographic algorithm.
Ensure that you also specify the cryptographic algorithm to sign the token
Isabelle then demonstrated how 42Crunch enables a proactive approach to enforcing API security policies that prevents the combination of Broken Authentication and Security Misconfiguration at design time and enforce these policies at runtime. By enabling development and security teams to adopt a positive security model approach, 42Crunch’s platform specifies exactly what is expected and acceptable by the API at runtime and ensures that any requests outside of these parameters are automatically rejected. For example, it will ensure that a specific cryptographic algorithm should be used to sign the token and in accordance with any particular libraries that are being used to create the JWT in a specific programming language.
More comprehensive details on JWT can be found in our original blogpost on “7 Ways to avoid JWT Security Pitfalls.”
Full webinar recording here: https://42crunch.com/webinar-top-things-you-need-to-know-about-api-security/
