Security vulnerability

[frankguns]

Today we received a mail from Azure (see contents below) about a security vulnerability in Swashbuckle.Core. We have a published application in Azure containing this package and they advise to remove it. Are you aware of this vulnerability?

Mail from Azure:

Our Microsoft Azure Security team is following reports of multiple high risk vulnerabilities present in current and older versions of swagger-ui. These are third-party vulnerabilities and not related to the Azure platform. However, some Mobile Apps deployments may have swagger-ui installed in a manner that makes those deployments vulnerable to phishing attacks.

How the vulnerability is exploited
The swagger-ui component allows loading of arbitrary swagger definition files by passing the URL of the swagger definition as a querystring parameter. Malicious swagger definitions can be constructed that execute arbitrary code within the browser. An attacker can then send a URL containing a reference to the malicious swagger definition that is then executed by simply opening the URL in a browser (for example, clicking on the link in an email).

How the vulnerability is mitigated
The Mobile Apps server SDKs now validate the URL of the swagger definition that is passed as a querystring parameter. Additionally, a Content Security Policy (CSP) header is sent which prevents the browser from communicating with servers that may host malicious swagger definitions.

How to determine if your deployment is at risk
First determine whether your Mobile Apps deployment is based on Node.js (this includes all Easy Tables users) or .NET.

• For Node.js, you can determine if your deployment is vulnerable by looking at the code in your app.js file (if you are using Easy Tables, you can do this by using the Edit Script option in the Azure portal; this will open App Service Editor and allow you to browse the files). If you see the line "swagger: true" then swagger-ui is enabled and your deployment is potentially vulnerable.
• For .NET, your deployment is potentially vulnerable if the application you publish includes the Azure Mobile .NET Server Swagger package (the vulnerabilities aren‘t in this package itself but one of its dependencies).

Steps to perform mitigation actions
For Node.js, updated packages are available. We recommend that Node.js users complete one of the following actions:

• Edit your application code (for example, app.js) to disable the configuration setting that enables our swagger UI functionality (use swagger: false).
• Or update to swagger-ui 2.1.5, and then update to the latest version of the Azure Mobile Apps Node.js SDK. Here are a couple of ways to do this:
◦ Sign in to the kudu debug console by opening https://.scm.azurewebsites.net/DebugConsole (update to your mobile app name), change directory to D:\home\site\wwwroot, and then run npm update -save azure-mobile-apps swagger-ui. When this completes, go to the Azure portal, open your mobile app, and then select the Restart option.
◦ Update package version numbers in package.json (azure-mobile-apps should be version 2.2.3; swagger-ui should be 2.1.5) and deploy using git.

We strongly recommend the following steps for .NET customers:

1. Uninstall the Azure Mobile .NET Server Swagger package as a mitigation.
2. Confirm that your application code no longer includes a reference to the Swashbuckle.Core package.
3. Republish your application.

For more information on the open source component swagger-ui vulnerabilities, please visit the following webpages on the Node Security Platform website:

• XSS in Consumes/Produces Parameter
• XSS in key names
• XSS via Content-type header

Please contact us if you have any questions.

[domaindrivendev]

Hey thanks for letting me know about the Azure correspondance - bad PR for Swashbuckle :(

Also a little unfortunate because, in fact, the version of index.html embedded with Swashbuckle never actually uses the "url" that's passed in the query string:

https://github.com/domaindrivendev/Swashbuckle/blob/master/Swashbuckle.Core/SwaggerUi/CustomAssets/index.html#L80

So, as far as I can tell, this isn't a vulnerability with the swagger-ui that ships with Swashbuckle

[domaindrivendev]

Also worth noting ... I have a local branch with swagger-ui upgraded to it's latest version (v2.2.0) and am still observing the XSS vulnerability. So, I don't believe the advice from Azure to upgrade swagger-ui to v2.1.5 will mitigate this issue either.

But to be clear, due to the way in which SB uses swagger-ui, the issue is not present with a Swashbuckle installation.

[bradygaster-zz]

I've worked with Richie and the rest of the Swashbuckle team and can confirm this is unfortunate correspondence. As Richie points out his code doesn't make use of the URL so Swashbuckle-generated Swagger shouldn't be prone to this attack. Subsequently, we've added code to the Visual Studio template to explicitly disable the UI, and users need to explicitly enable it to light up the dynamically-generated UI.