docktermj
commented
4 years ago @ZackHill05 Just so we understand the issue correctly...
I see the use of port 8251 in the description. That port is used in demonstrations for the "Senzing Entity Search Web App" (https://github.com/Senzing/knowledge-base/blob/master/lists/ports-used-in-demonstrations.md#8251).
Is the issue actually with the "Entity Search Web App" (https://github.com/Senzing/entity-search-web-app)?
If so, please open a new issue in https://github.com/Senzing/entity-search-web-app/issues/new/choose so we can assign and track the issue correctly.
If it truly is with the Senzing API server, just post a note confirming and we'll take it from there.
...and thank you for finding this issue. We appreciate you taking the time to help us improve the software.
ZackHill05
Our security scan says that the API is vulnerable to cross-site scripting. It says when it provides:
http://servername>: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://servername>: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: servername>: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.