Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
joevennix opened this issue Jan 13, 2016 · 7 comments
Milestone

Comments

@joevennix
Copy link
Contributor

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.

@joevennix joevennix changed the title Content-types in schema are not escaped and allow XSS "Produces" and "consumes" Content-types in schema are not escaped and allow XSS Jan 13, 2016
joevennix added a commit to joevennix/swagger-ui that referenced this issue Jan 13, 2016
@spadger
Copy link

spadger commented Jan 13, 2016

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
Copy link
Contributor Author

@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
Copy link

spadger commented Jan 13, 2016

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
Copy link
Contributor Author

@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:

image

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
Copy link

spadger commented Jan 13, 2016

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 added a commit that referenced this issue Jan 13, 2016
Fix issue #1866, XSS in content types from schema.
@fehguy
Copy link
Contributor

fehguy commented Jan 13, 2016

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

@fehguy fehguy closed this as completed Jan 13, 2016
@joevennix
Copy link
Contributor Author

@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.

Jonahss pushed a commit to eaze/swagger-ui that referenced this issue Aug 12, 2016
vincent-zurczak pushed a commit to roboconf/swagger-ui that referenced this issue Aug 19, 2016
vincent-zurczak pushed a commit to roboconf/swagger-ui that referenced this issue Aug 19, 2016
@fehguy fehguy added this to the v2.2.1 milestone Aug 23, 2016
JuanSW18 pushed a commit to Digital-Paw/digital-paw-swagger-ui that referenced this issue Aug 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants