This week, we have important news of a vulnerability in the OAuth social sign-in feature of many popular platforms, potentially impacting billions of users. We have two articles from The NewStack, the first a guide on securing your API gateway and the second how to design scalable SaaS API security. We also have news of a significant partnership between Microsoft and 42Crunch designed to deliver end-to-end API security for enterprises. We finish with two guides, the first on preventing API breaches and the second from Dana Epp on using Burp Collaborator to prove API exploitability.
Vulnerability: Flaws in OAuth social sign-in put billions at risk
The most important item this week (and in the last few months) is the vulnerability discovered by Salt Labs in implementing the OAuth protocol in several popular websites. The vulnerability could have allowed attackers to harvest tokens using a malicious site using OAuth2 social logins and then use these harvested tokens to gain full access to accounts on vulnerable websites. The research describes vulnerabilities on the Grammarly, Vidio, and Bukalapak websites which have now been remediated on all three websites.
The original disclosure on the Salt Labs website is worth reading to fully appreciate how a subtle omission on the vulnerable website’s OAuth handler code could create such a serious vulnerability. During the OAuth token exchange, the client application must validate the token’s identity received from the authorizing server (such as Google or Facebook) to ensure that the application ID matches its own. In other words, does the token belong to the application, or is it a stolen or harvested token from another application?
The image above shows OAuth’s standard “implicit grant type” flow. In step 5, the user presents the token received previously to the client application, which then asks the authorization server for the token’s identity (steps 6 and 7). Before issuing the request at step 6, the client application is expected to verify that the token contains a client_id value identical to its own ID value. If not, the token is fake or has been tampered with and should be rejected. Unfortunately, this research discovered three websites where this check was omitted, allowing fake, harvested tokens to be used. These fake tokens would then assign the attacker all the rights and privileges on the vulnerable site that the victim user had — potentially a total account takeover.
The guidance from Facebook is very explicit in this regard:
“When token is received, it needs to be verified. You should make an API call to an inspection endpoint that will indicate who the token was generated for and by which app. As this API call requires using an app access token, never make this call from a client. Instead make this call from a server where you can securely store your app secret.”
I will be totally transparent here and admit that while I was aware of the importance of this step, I am almost certain I have written code that omits this important verification step. I predict that many other websites are vulnerable to this same issue and that this will not be the last time we feature it in this newsletter.
Article: Five best practices for security API gateways
In the first of two guides from The NewStack, we look at five best practices for API gateways. The API gateway has become the stalwart in the front line of defense of APIs, and yet many API teams fail to take advantage of the many security features offered by their gateways.
The article recommends that the principle of zero trust should be foremost when configuring API gateways. To implement zero trust in your API gateway, you must validate and authenticate every user, request, origin, and action before granting access.
The five top recommendations featured in the article are:
- Authentication: Use token-based authentication with short-lived tokens. Use tokens in preference to keys, keep the token lifetime short to avoid the impact of loss or theft, ensure that tokens are transmitted securely over TLS, and ensure that you fully validate signed tokens to ensure their authenticity.
- Authorization: Strictly enforce role-based access control (RBAC) for all API endpoints. Use the principle of least-privilege, and manage the claims in your tokens carefully to ensure that you do not have wide open access.
- Rate Limiting: Implement dynamic, layered rate limiting based on user behavior and context. This really is one of the easier ones to get right, as gateways tend to have rich features around rate limiting, allowing it to be based on IP address, session or user IDs.
- CORS: Explicitly define and restrict allowed origins. Use well-formulated CORS policies to ensure that your APIs are not wide open to any attacker and, rather, can only be accessed from the intended origin (usually your web application).
- Logging: Implement real-time monitoring and alerting for anomalies. Verbose and accurate logs are essential to ensure that any API anomalies are identified and can be addressed.
To this list, I suggest that, where available on their API gateway, security teams enable the packet inspection capabilities of their API gateways and use this in conjunction with the OpenAPI definition to enforce request and response data validation. Remember that API 03:2023 – Broken Object Property Level Authorisation is all about data validation.
Article: How to design scalable SaaS API security
The second guide from The NewStack features the views of Curity on how to design scalable SaaS API security. The article describes the importance of a robust and scale OAuth2 authorization framework (very timely based on our first article). It stresses the importance of choosing the correct flow for the application in question (and implementing that flow correctly to avoid security loopholes).
The guide then looks at the important choice of an authorization server. It suggests that simply defaulting to the cloud provider’s built-in implementation may not always be optimal and that the choice requires sufficient care and attention. Designers should pay attention to the ease of deployment and redundancy or restore times in the case of a failure since the authorization server is mission-critical.
Regarding the use of OAuth2, the guide stresses the importance of not only choosing the correct flow but also ensuring that tokens are designed optimally to minimize the scope of the claims being made (the principle of least privilege) and to ensure the minimum validity is used (a point made in the second article too).
Thanks to Curity for another informative guide on an important topic.
Tools: 42Crunch and Microsoft Partner to Deliver End-to-End API Security
Yesterday, 42Crunch and Microsoft announced an integration of services to help enterprises adopt a full-lifecycle approach to API security. The partnership provides continuous API protection from design to runtime to help Microsoft’s enterprise customers protect their APIs from attacks and data breaches.
With Microsoft Defender for APIs, now in GA, an offering as part of Microsoft Defender for Cloud – a cloud-native application protection platform, organizations can improve their security posture and quickly detect active real-time threats. This integration empowers developers to test their APIs for security during development and empowers security admins to gain full lifecycle visibility into the security posture of their APIs within Defender for Cloud.
Further details of how the integration works are available here.
Guide: How to prevent API breaches
The next guide comes courtesy of The Hacker News and is a compendium of best practices that can be used to prevent API breaches. Although many of these will be familiar to readers of this newsletter, this guide does highlight some of the critical design and test fundamentals for anyone involved in securing APIs.
Right at the top of the list is the twin pairing of authentication and authorization, which are certainly top issues for API security — most breaches we see will include a failure of one or both of these. They describe the following key topics:
- API keys and tokens: be sure to safeguard keys and tokens, use tokens with short lifetimes, and transmit them securely.
- OAuth and OpenID Connect: use industry-proven and robust protocols to establish authentication and authorization, and be sure to implement them securely (again, see the first article).
- Role-based access control: Only provision the minimum necessary privilege to users.
Second on the list is data encryption, which is vital to ensure that APIs do not leak data or information unnecessarily. The key topics here include:
- SSL/TLS certificates: Ensure that server certificates are valid (watch for expiring certificates) and that clients fully validate the certificate chain.
- Transport Layer Security: Use TLS everywhere to ensure data privacy, and between microservices use mutual TLS where possible.
- Encryption of data at rest: When storing data on the filesystem use encryption to protect it, and when storing in a database use the built-in database features to protect the data.
Also critically important is the topic of API design and implementation to ensure that APIs are secure by design. The key topics here are:
- Versioning: Manage deprecated APIs and ensure that API changes do not break existing clients.
- Input validation and data sanitization: Use core principles from AppSec to ensure that all input data is validated and sanitized to prevent possible injection attacks.
- API endpoint security: Ensure that API endpoints include proper checks for authentication and authorization.
Testing is critical in ensuring that flaws in APIs do not make it to production. A well rounded approach to testing yields the best results and should include the following:
- Automated Testing: Use automatic API testing tools in the CI/CD pipeline to ensure APIs are compliant with their specification and do not contain basic errors such as missing authentication or authorization.
- Unit Testing: Developers should test individual elements of API functionality as they implement it within their environments.
- Integration Testing: Test the full API to confirm it works with dependent components.
- Functional Testing: Test the functionality of the API to confirm it behaves as expected.
- Continuous Automated Red Teaming (CART): Use red teams and/or managed bug bounty programs to keep on top of API security risk.
Guide: Proving API exploitability with Burp Collaborator
Finally this week, we have another guide, this time featuring the PortSwigger Burp Collaborator tool to prove the exploitability of APIs, particularly for attacks which are blind and do not reveal indication of compromise to the main output.
Burp Collaborator is a rather useful companion tool for uses of paid versions of Burp Suite. The diagram below shows the basic usage: a tester using Burp Suite submits a payload to the target and if it is vulnerable, will extract the payload and access links which will trigger access to a URL on Burp Collaborator which will store the payload for analysis in Burp Suite.
As usual Dana provides a great guide on how to use it in your testing, but if you are looking for an excellent real-world example then this write-up from AssetNote is a great read. Thanks to both for the great guides.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
