API Gateways Not Securing Caches
So the other day I was having a conversation with a team and pointed out that gateways do not secure their caches with RBAC; they use RBAC for requests but their caches may return larger datasets thus making your API vulnerable (see OWASP API3:2019 : Excessive Data Exposure).
They asked ‘How come no one is talking about this?’ and I said ‘who is going to talk about this? Vendors?” They aren’t going to willingly talk about their security vulnerabilities (much less fix them). The only people who talk about security issues are researchers. And you often have to scour the submitted issues on different security lists (if they were even submitted).
So I thought I would take some time today to talk about how this occurs and why this is a vulnerability.
Understanding Role Based Access Control (RBAC) and API’s
When you send a token with your API call, it contains information on:
- who you are & what roles/privileges you have
- OR it enables the system to create a PRINCIPLE with said information
This enables the system to determine what endpoints you have access to. More importantly, it can limit what data you sent and get returned via the API (see OWASP API3:2019 : Excessive Data Exposure).
So an ADMIN role calling an endpoint can get a larger dataset vs a USER role calling the same endpoint which would get a limited/smaller dataset returned (for example).
Caching and RBAC
Now if a role-based dataset is returned on a RESPONSE and cached, one would expect that ROLE is checked on a REQUEST prior to returning a cached dataset to make sure we are returning the proper cached dataset for said role. However this is NOT the case:
The list goes on.
That means NOT A SINGLE GATEWAY product is returning a proper cached response (unless you have zero security).
Why does this occur?
Heavy reliance on tools like OpenAPI which do not support security (especially RBAC) make it an after thought:
In the words of the lead dev for OpenAPI :
“It’s a static design doc, there is no shared state and no need for ROLES.”
Regardless of this being pointed out since 2015 (to the creator of OpenAPI, Tony Tam), they have chosen to ignore the need for assigning ROLES to endpoints while the rest of the API community acknowledges the importance of RBAC in API’s:
While these tools support and use RBAC, they still have loopholes in how they use them. And when security/api researchers point out these issues to the CEOs, CTO’s and heads of development of these companies, they respond like such:
They deliberately choose to ignore their own vulnerabilities rather than address them.
Other times, the engineers are just completely ignorant of the HTTP work flow in distributed architectures. One Google engineer told me that it all depends on the tool and pushed Apigee (regardless of them suffering from the same issues):
Most security researchers acknowledge that this is a sad fact of life that most companies take a hostile approach when having these vulnerabilities pointed out but it does not benefit them to create a confrontational relationship with those bringing security vulnerabilities in their products to light.
Solution : Cache Locally at your API application
The best solution is to use a local cache at your API service to resolve this issue.
Localized caching is fine as the session is maintained by the application/web server so regardless of how many instances you have, the user session will still get the cache from the same service. Additionally, a localized API cache will be more responsive
Until API gateways decide to fix all their issues, more and more functionality will have to be moved back into the API application to continue to fix all these issues.
