Entity Web Search App vulnerable to cross-site scripting

[ZackHill05]

Our security scan says that the API is vulnerable to cross-site scripting. It says when it provides:

http://:8251/api/entities?'"@-->

to a browser that has the cross-site scripting filter disabled, an alert does come up on the browser. Here are the details:

Proof of Exploit Generated XSS exploit might not work due to browser XSS filtering. Please follow the guidelines below in order to disable XSS filtering for different browsers. Also note that; • XSS filtering is a feature that's enabled by default in some of the modern browsers. It should only be disabled temporarily to test exploits and should be reverted back if the browser is actively used other than testing purposes. • Even though browsers have certain checks to prevent Cross-site scripting attacks in practice there are a variety of ways to bypass this mechanism therefore a web application should not rely on this kind of client-side browser checks. Chrome • Open command prompt. • Go to folder where chrome.exe is located. • Run the command chrome.exe --args --disable-xss-auditor Internet Explorer • Click Tools->Internet Options and then navigate to the Security Tab. • Click Custom level and scroll towards the bottom where you will find that Enable XSS filter is currently Enabled. • Set it to disabled. Click OK. • Click Yes to accept the warning followed by Apply. Firefox • Go to about:config in the URL address bar. • In the search field, type urlbar.filter and find browser.urlbar.filter.javascript. • Set its value to false by double clicking the row. Safari • To disable the XSS Auditor, open Terminal and executing the command: defaults write com.apple.Safari "com.apple.Safari.ContentPageGroupIdentifier.WebKit2XSSAuditorEnabled" -bool FALSE • Relaunch the browser and visit the PoC URL • Please don't forget to enable XSS auditor again: defaults write com.apple.Safari "com.apple.Safari.ContentPageGroupIdentifier.WebKit2XSSAuditorEnabled" -bool TRUE

Notes For successful exploitation, payload may need to be sent without URL encoding. Modern browsers will encode the HTML tags in the request before it is being sent to the webserver, however it is still possible in Internet Explorer. Proof URL http://:8251/api/entities?'"@--> Request GET /api/entities?'"@--> HTTP/1.1 Host: :8251 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8 Accept-Encoding: gzip, deflate Accept-Language: en-us,en;q=0.5 Cache-Control: no-cache User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36 X-Scanner: Netsparker

Response HTTP/1.1 504 Gateway Timeout X-Powered-By: Express Connection: keep-alive Transfer-Encoding: chunked Date: Tue, 10 Dec 2019 18:51:58 GMT

Error occured while trying to proxy to: :8251/entities?'"@-->

and it says the Remedy is: The issue occurs because the browser interprets the input as active HTML, JavaScript or VBScript. To avoid this, output should be encoded according to the output location and context. For example, if the output goes in to a JavaScript block within the HTML document, then output needs to be encoded accordingly. Encoding can get very complex, therefore it's strongly recommended to use an encoding library such as OWASP ESAPI (https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API) and Microsoft Anti-cross-site scripting (http://www.microsoft.com/en-us/download/details.aspx?id=28589). Additionally, you should implement a strong Content Security Policy (CSP) as a defense-in-depth measure if an XSS vulnerability is mistakenly introduced. Due to the complexity of XSS-Prevention and the lack of secure standard behavior in programming languages and frameworks, XSS vulnerabilities are still common in web applications. CSP will act as a safeguard that can prevent an attacker from successfully exploiting Cross-site Scripting vulnerabilities in your website and is advised in any kind of application. Please make sure to scan your application again with Content Security Policy checks enabled after implementing CSP, in order to avoid common mistakes that can impact the effectiveness of your policy. There are a few pitfalls that can render your CSP policy useless and we highly recommend reading the resources linked in the reference section before you start to implement one.

[arawinters]

the /api endpoint is the reverse proxy front that forwards to the api server. Normal browser XSS checks will bounce any requests being made to /api from a machine other than the one it's running on. Beyond that it is possible to pre-flight by telling the rev proxy to bounce anything that doesn't pass a specific origin header. We'd have to expose the functionality to the docker container(it's baked in to the sdk) and twist some knobs though.

Correct me if I'm wrong, but doesn't your SSO/Proxy mechanism require log in to even hit the docker webapp instance?

[ZackHill05]

You're right, our SSO mechanism does require log in to hit the docker. I'm not sure why our security organization doesn't see one security mechanism as the protection for another, but they don't :-). Maybe I can try to schedule a meeting with you and our security SME so you two can discuss remediation.

[arawinters]

It's one of those things where it would have to be a preponderance of occurrences to pose any significant threat.. like an attacker would basically already be inside the network. Same thing with the other ticket filed, those are vuln's inside of a container, which to exploit, a person would (I think, not 100% sure) already have at the very least access to the shell on the host machine(which is a much bigger issue at that point) and maybe even need root/su.

Still though, I'm going to mark this as accepted, and lock down the reverse proxy so that it only accepts XHR requests from it's own origin.

[arawinters]

I need a double check on your end @barrycaceres . specifically this scanner is using the url: http://:8251/api/entities?'"@--></style></scRipt><scRipt>alert(0x0028F5)</scRipt>

so what it's doing is attempting to pass an injected script block in to the query string parameters using some funky commas and unescaped tags. I have not as of yet been able to get any of the api server endpoints to actually spit out any injected content in to the api server json response, but can you just double check that we are not printing out the values of parameters to the json or error response?

[arawinters]

So I've implemented CSP and CORS. CORS is disallowed by default, and CSP is enabled by default. here are the results of some preliminary testing I've done.

1. Inject foreign script(s) and style(s) in to the webapp SPA (bootstrap in example)
2. Attempt to access and/or pass malformed requests to the webapp reverse proxy from both a rogue reverse proxy and a XDR request.