"Produces" and "consumes" Content-types in schema are not escaped and allow XSS

[joevennix]

To reproduce, use the example JSON, but change one of the "consumes" keys like so:

"consumes" =>["application/json","application/xml","\"><script>alert(1)</script>"]

Or:

"produces" =>["application/xml","application/json","\"><script>alert(1)</script>"]

You will see the alert dialog execute.

[spadger]

Hi Joe,

The reason I submitted the original PR is because we are using a profile media-type parameter in our Accept header; in our case it is

application/hal+json; charset=utf-8; version=1.0; profile="http://donate-api.justgiving.com/profiles"

Before my PR, swagger would create requests with truncated accept headers, at the site of the first quote mark.

With respect to the XSS, I am not sure if it should be a concern. I may be wrong, but the only input to these fields comes from the server its self, with no scope for a hostile actor to alter it for subsequent requests. If they wanted to custom-craft a request, there are plenty of tools available for that.

Thanks,

Jon

[joevennix]

@spadger thanks for the quick response. These XSS vulnerabilities are easily exploitable because swagger-ui's index.html takes a ?url GET parameter, which the attacker can set to a malicious schema on their own server, provided it responds with the proper CORS headers. So an attacker just has to get you to navigate to yourserver.com/swagger-ui/index.html?url=http://attacker.com/schema.json to trigger this XSS.

The main reason I am concerned with XSS in this library is because the project advocates hosting swagger-ui directly on your API server; so if you have an authenticated web app hosted on the same domain, swagger-ui becomes part of its attack surface.

I'll try out your provided Content-type header and try to figure out what goes wrong, but I suspect your original fix was done in the wrong place.

[spadger]

Good point; that XSS would be horrendous! I guess it would be possible encode the value in the options and decode when performing the request? I may be able to take a look later,

[joevennix]

@spadger I can't seem to reproduce the original issue; I changed the code to use {{ instead of {{{ and rebuilt, then used a schema with the following attribute:

"consumes" =>["application/hal+json; charset=utf-8; version=1.0; profile=\"http://donate-api.justgiving.com/profiles\""]

The value shows up correctly in the <select> box:

And the Content-type of the request itself seems to be encoded properly:

POST /v2/pet HTTP/1.1
Host: localhost:4567
Connection: keep-alive
Content-Length: 3
Accept: application/hal+json; charset=utf-8; version=1.0; profile="http://donate-api.justgiving.com/profiles"
Origin: http://localhost:9999
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36
Content-Type: application/hal+json; charset=UTF-8; version=1.0; profile="http://donate-api.justgiving.com/profiles"
Referer: http://localhost:9999/index.html?url=http://localhost:4567/swagger.json
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8

Am I missing a step?

[spadger]

Hey Joe,

I think I have been a bit dim here - my fix actually changed the {{{ }}} to {{ }} - I added escaping to the solution (but when rendering the value of an option)! As such, with my change - {{}}, the dropdown is rendered as this:

application/hal+json; profile="http://donate-api.justgiving.com/profiles"; version=1.0

Your PR adds escaping to the rendering of the displayable content of the option, and I can confirm it works with my profile.

Jon

[fehguy]

I've merged the PR #1867. Thanks guys!

[joevennix]

@spadger ahhh thanks for clearing that up. My eyes glazed right over your actual change - which indeed closed one out of the two XSS vulnerabilities in that template.