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
add an enableQueryConfig option
#4872
Comments
|
We'll use naming |
…7697) Reading configuration parameters from URL search params is by default no longer enabled. To re-enable it, set queryConfigEnabled configuration parameter to true. Functionally, this is a breaking change, but given we're just providing a security vulnerability patch we're considering this a PATCH version bump only. Refs #4872 Refs GHSA-qrmm-w75w-3wpx
|
@char0n do you know why it still an open issue for Snyk? https://security.snyk.io/vuln/SNYK-JS-SWAGGERUIDIST-2314884 |
|
@andrew-itscript it's probably reporting it for older versions of swagger-ui. The snyk link you provided is not associated with any specific version so it probably reports for older versions. |
|
@andrew-itscript It looks like a discrepancy with Snyk's data. Their database shows the correct version for I opened a ticket with Snyk to correct. UPDATE Jan 28: Snyk has added the version to their |
Content & configuration
Swagger-UI configuration options:
Is your feature request related to a problem?
We’ve observed that the ?url= parameter in SwaggerUI allows an attacker to override an otherwise hard-coded schema file. This opens the door to issues such as #3847 and #4789 which would otherwise be prevented by hard-coding the schema file URL.
The behavior appears to be a regression in the 3.x releases. It can easily be reproduced by passing in a URL to the SwaggerUIBundle constructor and then using the ?url parameter to override it, while observing the behavior in the Net panel of your browser’s developer tools. Note that CORS rules can prevent a test from succeeding, but do not prevent a real attack.
Additionally, the URL parameter is dangerous in general because it allows an attacker to provide a similar schema file that instead sends authorization requests to a server under an attacker’s control, which makes it much easier to trick a user into leaking their login credentials. So the URL parameter should not be allowed in any setting where authentication or other sensitive information is used. I’d recommend disabling it by default and cautioning users against enabling it.
Describe the solution you'd like
for 3.x: Add an enableQueryParam or similar option.
If omitted,default to falseif a URL is passed into the constructor, otherwise default true.for 4.x: Change the default
when omittedto false.Describe alternatives you've considered
Our workaround was to detect the URL parameter before initializing SwaggerUI and failing early if it was set.
Additional context
This is taken from a security report given to the Swagger team by Ken Winters, based on investigation done by Gaurav Shet and Ben Zulanch - all over at NetApp.
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.
The text was updated successfully, but these errors were encountered: