SwaggerUI supports displaying remote OpenAPI definitions through the ?url parameter. This enables robust demonstration capabilities on sites like petstore.swagger.io, editor.swagger.io, and similar sites, where users often want to see what their OpenAPI definitions would look like rendered.
However, this functionality may pose a risk for users who host their own SwaggerUI instances. In particular, including remote OpenAPI definitions opens a vector for phishing attacks by abusing the trusted names/domains of self-hosted instances.
An example scenario abusing this functionality could take the following form:
https://example.com/api-docs hosts a version of SwaggerUI with ?url= query parameter enabled.- Users will trust the domain
https://example.com and the contents of the OpenAPI definition.
- A malicious actor may craft a similar OpenAPI definition and service that responds to the defined APIs at
https://evildomain.
- Users mistakenly click a phishing URL like
https://example.com/api-docs?url=https://evildomain/fakeapi.yaml and enters sensitive data via the "Try-it-out" feature.
We do want to stress that this attack vector is limited to scenarios that actively trick users into divulging sensitive information. The ease of this is highly contextual and, therefore, the threat model may be different for individual users and organizations. It is not possible to perform non-interactive attacks (e.g., cross-site scripting or code injection) through this mechanism.
Resolution
We've made the decision to disable query parameters (#4872) by default starting with SwaggerUI version 4.1.3. Please update to this version when it becomes available (ETA: 2021 December). Users will still be able to be re-enable the options at their discretion. We'll continue to enable query parameters on the Swagger demo sites.
Workaround
If you host a version of SwaggerUI and wish to mitigate this issue immediately, you are encouraged to add the following custom plugin code:
SwaggerUI({
// ...other configuration options,
plugins: [function UrlParamDisablePlugin() {
return {
statePlugins: {
spec: {
wrapActions: {
// Remove the ?url parameter from loading an external OpenAPI definition.
updateUrl: (oriAction) => (payload) => {
const url = new URL(window.location.href)
if (url.searchParams.has('url')) {
url.searchParams.delete('url')
window.location.replace(url.toString())
}
return oriAction(payload)
}
}
}
}
}
}],
})Future UX work
Through the exploration of this issue, it became apparent that users may not be aware to which web server the Try-it-out function will send requests. While this information is currently presented at the top of the page, understanding may improve by displaying it closer to the "Execute" button where requests are actually made. We'll be exploring these UX improvements over the coming months and welcome community input. Please create a Feature Request under the GitHub Issue tab to start a conversation with us and the community.
Reflected XSS attack
Warning in versions < 3.38.0, it is possible to combine the URL options (as mentioned above) with a vulnerability in DOMPurify (https://www.cvedetails.com/cve/CVE-2020-26870/) to create a reflected XSS vector. If your version of Swagger UI is older than 3.38.0, we suggest you upgrade or implement the workaround as mentioned above.
References
dinvlad Analyst
pshelton-skype Analyst
Dingjie-Daniel-Yang Analyst
SwaggerUI supports displaying remote OpenAPI definitions through the
?urlparameter. This enables robust demonstration capabilities on sites likepetstore.swagger.io,editor.swagger.io, and similar sites, where users often want to see what their OpenAPI definitions would look like rendered.However, this functionality may pose a risk for users who host their own SwaggerUI instances. In particular, including remote OpenAPI definitions opens a vector for phishing attacks by abusing the trusted names/domains of self-hosted instances.
An example scenario abusing this functionality could take the following form:
https://example.com/api-docshosts a version of SwaggerUI with?url=query parameter enabled.https://example.comand the contents of the OpenAPI definition.https://evildomain.https://example.com/api-docs?url=https://evildomain/fakeapi.yamland enters sensitive data via the "Try-it-out" feature.We do want to stress that this attack vector is limited to scenarios that actively trick users into divulging sensitive information. The ease of this is highly contextual and, therefore, the threat model may be different for individual users and organizations. It is not possible to perform non-interactive attacks (e.g., cross-site scripting or code injection) through this mechanism.
Resolution
We've made the decision to disable query parameters (#4872) by default starting with SwaggerUI version
4.1.3. Please update to this version when it becomes available (ETA: 2021 December). Users will still be able to be re-enable the options at their discretion. We'll continue to enable query parameters on the Swagger demo sites.Workaround
If you host a version of SwaggerUI and wish to mitigate this issue immediately, you are encouraged to add the following custom plugin code:
Future UX work
Through the exploration of this issue, it became apparent that users may not be aware to which web server the Try-it-out function will send requests. While this information is currently presented at the top of the page, understanding may improve by displaying it closer to the "Execute" button where requests are actually made. We'll be exploring these UX improvements over the coming months and welcome community input. Please create a Feature Request under the GitHub Issue tab to start a conversation with us and the community.
Reflected XSS attack
Warning in versions < 3.38.0, it is possible to combine the URL options (as mentioned above) with a vulnerability in DOMPurify (https://www.cvedetails.com/cve/CVE-2020-26870/) to create a reflected XSS vector. If your version of Swagger UI is older than 3.38.0, we suggest you upgrade or implement the workaround as mentioned above.
References