A Primer on APIs – Opportunities, Risk, and Remediation
APIs offer premade services, utilities, and integration points that allow applications to deliver rich features without requiring the application itself to write each component. This presents a significantly reduced barrier of complexity and time to value for application offerings both commercially, and in the enterprise. That’s said, those same integration points that extend app capability can also expand the potential vector of attack that malicious actors can exploit.
In a traditional web-based application (see diagram 1 below), communication between the app itself (on a browser, mobile platform, etc.) occurs between the user agent and the web or application server using standard browser-patterned traffic. The web/app server then makes its own calls to whatever microservices it leverages to provide its app functionality. To a potential attacker, the details of data structures, services, and calls are abstracted behind the web app as the granular calls are made beyond the view of what the attacker can expect to see from outside the network.
Diagram 1: Communication with a traditional web-based application
However, with APIs (see diagram 2 below), the application now makes several point-to-point calls directly to discrete microservices. As such, the potential channels that an attacker can monitor to learn about an environment are increased. Each API describes what it requires from the application and what it will return in kind as a response. Thus, unprotected APIs can reveal not only the data in transport, but offer a map of the backend microservices and data available behind the app server itself.
Diagram 2: Communication with APIs
Fortunately, most of the same defenses in use to protect web apps and traffic from attackers can also be applied to narrow the attack vector against APIs.
Sanitize and restrict the input allowed when invoking the API. An API’s required inputs give attackers insight into the data structures that may contain that data, and by extension, what kind of injection may result in successful exfiltration of protected data. Leave no opportunity for an injection attack; filter input and escape output. Review further opportunities to lock down by looking at the OWASP REST Security Cheat Sheet.
There is no excuse to have unencrypted data in transit in 2017. APIs are not magically exempt from this. Keep every communication channel behind encryption.
Authentication and authorization
Correlate each API call to an identity- be that the identity of a user, a clientID associated with a machine, or unique application identifier key.
If APIs have increased the potential attack surface area, look to an API gateway to narrow it again.
Diagram 3: The effect of implementing an API gateway
An API gateway acts as a reverse proxy for calls to a microservice catalog. From the app perspective, all calls go to a single location and the gateway itself calls the service, or provides a computed response by aggregating the response of several microservices. The details of the backend services are outside the view of a potential attacker; calls to microservices could only be observed by the gateway. Furthermore, when paired with an OAuth flow, the API gateway provides an additional enforcement point to determine what methods, if any, a given clientID with a valid bearer token is entitled to invoke. This marries the authentication of the OAuth flow with entitlement management on the clients themselves. As such, the gateway becomes the tool for API governance as well.
The API ecosystem offers rich capabilities and new threat vectors. As usual, it is up to us, the identity professionals, to ensure a superior customer experience and business outcomes while ensuring the protection of all our data channels.
By Jon Lehtinen, SSO Integrations Leader, GEView More Posts