Cybersecurity firm Rapid7 has discovered a vulnerability involving Swagger-driven code generation tools that could expose applications built on Node.js, PHP, Ruby and Java (and potentially others) to exploitation. Last week, Charlie Osborne highlighted the issue in an article for ZDNet that faults Swagger when it reality, it is more the fault of the tools that feed off a Swagger-based API definition in the course of generating language specific SDKs (aka "client libraries") and API endpoints.
When an API is described with an API description language like Swagger, the resulting description can be used to auto-generate software development kits (SDKs) that in turn make it easier for developers to consume the related Web API on the platforms of their choice (as opposed to writing code that works directly with the Web API's endpoint). Likewise, a functional endpoint (either for testing or production) can be automatically provisioned from such a API description. Theoretically, both are at risk. While the issue could technically affect an auto-generated API endpoint, the implications in that scenario are that (1) a hacker would have tampered with a pre-existing API description (belonging to an API provider) prior to that description being used to launch the endpoint and (2) such tampering would have escaped detection by those who were designing and developing the API in advance of that launch. Things are a bit different on the SDK side since SDKs for many APIs are not exclusively offered by the API providers themselves. SDKs are often produced by third parties, especially for some of the less popular platforms.
According to Rapid7, researchers found the vulnerability involving injectable code payloads through the Swagger code generator (Swagger CodeGen) for the languages mentioned above, with some concern over other programming languages for which SDKs can also be auto-generated from a Swagger definition. Swagger CodeGen is a bit of open source tooling (copyrighted by SmartBear) that's used by many third party solution providers who offer turnkey SDK generation products and services. Wrote Rapid7 Application Security Researcher Scott Davis, the disclosure addresses "a class of vulnerabilities in a Swagger code generator in which injectable parameters in a Swagger JSON or YAML file facilitate remote code execution."
In a nutshell, what this means is that a hacker can insert malcious injectable parameters into a Swagger-based API definition such that any SDKs (or API endpoints) that are auto-generated from that description will inherit those parameters. Subsequently, any application produced with those SDKs (or that consumes those endpoints) could result in undesireable consequences for the API provider and/or the end user of the application. For example, Rapid7's notice included examples of code that, by way of its presence in a Swagger-based definition, could be remotely executed in Node.js, PHP, Ruby, and Java-based environments and even in a browser via HTML script injection. Nothing prevents a third party from describing an existing public API with Swagger-based tooling and auto-generating a bunch of SDKs off that description. In the case of third party SDKs that are outside of an API provider's control, the onus is on developers to treat those SDKs like they would any other potentially dangerous software that they download from the Internet before using them.
Rapid7's warning also alluded to the scenario where SDKs and/or endpoints are dynamically generated (on the fly). While such a scenario should be included in any attempt to cover all bases with long-term institutionalized countermeasures, looking around the API economy, that scenario is more of an edge case. Production SDKs and endpoints are not typically generated on the fly but rather once as either enter the realm of general availability for production consumption. In terms of countermeasures, not only is developer diligence a must when working with third party SDKs, any tooling that handles the parsing of an API description or code generation is a natural opportunity to validate description code and raise the barrier to malicious intentions. Additionally, API providers are widely encouraged to not only protect their endpoints and underlying systems from some of the more well-known exploits like code injection, they need to safeguard their API descriptions and related assets from tampering.
Rapid7 first identified and communicated the issue to Swagger’s Vendor & API team back in April. A proposed patch was handed to CERT on June 16, and a Metasploit module was released on public disclosure on June 23. Currently, Swagger recommends that tools like the OWASP ESAPI are used to sanitize code and mitigate the threat. However, OWASP's ESAPI tooling is not available for all languages. The original article says that a temporary fix has been offered to Swagger CodeGen, but readers are reminded that this is a short-term fix only, as the problem is not yet fully resolved. Parties that want to monitor the progress as Swagger CodeGen gets updated are encouraged to follow the journey on Github.