CrossSiteScripting.Reflected : Insecure use of Window Open (High Severity Issue)
Closed this issue · 6 comments
Stratos Version
Stratos Version 4.4.0
Frontend Deployment type
- Cloud Foundry Application (cf push)
- Kubernetes, using a helm chart
- Docker, single container deploying all components
- npm run start
- Other (please specify below)
Backend (Jet Stream) Deployment type
- Cloud Foundry Application (cf push)
- Kubernetes, using a helm chart
- Docker, single container deploying all components
- Other (please specify below)
Expected behaviour
When we do an AppScan static scan, the scanning results shouldn’t yield any vulnerabilities.
Actual behaviour
We ran Appscan and these vulnerabilities were marked as High Severity issues.
Steps to reproduce the behavior
AppScan Go: version 0.1.7
Steps
-
Open Appscan go application
-
Checkout the code of Stratos : release 4.4.0 (https://github.com/cloudfoundry/stratos.git) in your local machine.
-
Choose the type of scan i.e. Complete Security Scan
-
Click on Browse button and browse to the src folder(except test-e2e folder) of the stratos project that you checkout in step 2.
-
AppScan Go! retrieves appropriate files from the selected folder and lists them for review. No need to change anything on this just click on Continue button.
-
Click on Create a new scan button ---> Initiate scan : This will initiate the scan process.
-
When upload to AppScan on Cloud is complete, click the link review the status or results of the scan in the AppScan on Cloud service(there are lots of high severity issue you will see).
Reference : https://help.hcltechsw.com/appscan/ASoC/src_irx_gen_gui.html
Log output covering before error and any error statements
Insert log hereCopy
Detailed Description
Exact Location where the issue occurs:
Cause: Cross-site scripting (XSS) vulnerabilities arise when an attacker sends malicious code to the victim's browser, mostly using JavaScript. When a web application uses input from a user, it generates it in the output without filtering it. This way an attacker can insert a malicious script to the input, the script will return in the response and will run on the victim's browser.
In particular, sanitization of hazardous characters was not performed correctly on user input.
In reflected attacks, an attacker tricks an end user into sending request containing malicious code to a vulnerable Web server, which then reflects the attack back to the end user's browser.
The server receives the malicious data directly from the HTTP request and reflects it back in the HTTP response. The most common method of sending malicious content is adding it as a parameter in a URL that is posted publicly or e-mailed directly to the victim. URLs that contain the malicious script constitute the core of many phishing schemes, whereby the convinced victim visits a URL that refers to a vulnerable site. The site then reflects the malicious content back to the victim, and then the content is executed by the victim's browser.
Fix recommendation:
Fully encode all dynamic data from an untrusted source that is inserted into the webpage, to ensure it is treated as literal text and not as a script that could be executed or markup that could be rendered.
Consider the context in which your data will be used, and contextually encode the data as close as possible to the actual output: e.g. HTML encoding for HTML content; HTML Attribute encoding for data output to attribute values; JavaScript encoding for dynamically generated JavaScript. For example, when HTML encoding non-alphanumeric characters into HTML entities, < and > would become < and >.
As an extra defensive measure, validate all external input on the server, regardless of source. Carefully check each input parameter against a rigorous positive specification (allowlist) defining data type; size; range; format; and acceptable values. Regular expressions or framework controls may be useful in some cases, though this is not a replacement for output encoding.
Output encoding and data validation must be done on all untrusted data, wherever it comes from: e.g. form fields, URL parameters, web service arguments, cookies, any data from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files and filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
For every web page that is returned by the server, explicitly set the Content-Type HTTP response header. This header value should define a specific character encoding (charset), such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page, which would allow a potential attacker to bypass XSS protections.
Additionally, set the httpOnly flag on the session cookie, to prevent any XSS exploits from stealing a user's cookie.
Prefer using a framework or standard library that prevents this vulnerability by automatically encoding all dynamic output based on context, or at least that provides constructs that make it easier to avoid.
For every web page that is returned by the server, explicitly set the Content-Security-Policy HTTP response header, In order to make it significantly more difficult for the attacker to actually exploit the XSS attack.
Context
Insecure use of window open
Possible Implementation
There's no issue with using window.open for the examples provided
@anugu-vijaykanth In response to the comment which has been deleted, the issues were closed as they were raised generically without any heed to the context in which the features in question were used or why the security risk does not exist. If you believe them to be mistakenly closed please, per issue and per each referenced location explain why there is a problem.
@richard-cox , Can you suggest us what's the recommended way of raising Critical/High Issues that comes up from static scanning tools like AppScan
@anugu-vijaykanth It's common for generic security tools to raise false positives. If you can explain why the issue raised by the tool is applicable given the locations specified by the tool it would show them as genuine. Once this is demonstrated the issues can be reopened. At the moment it's just a keyword hit without any understand of how or why the features or processes are used.
The following example shows a script that returns a parameter value in the response.
The parameter value is sent to the script using a GET request, and then returned in the response embedded in the HTML.
HTTP Request:
GET /index.aspx?name=JSmith HTTP/1.1
HTTP Response:
HTTP/1.1 200 OK
Server: SomeServer
Date: Sun, 01 Jan 2002 00:31:19 GMT
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 27
<HTML>
Hello JSmith
</HTML>
An attacker might leverage the attack like this. In this case, the JavaScript code will be executed by the browser.
HTTP Request:
GET /index.aspx?name=>"'><script>alert('XSS')</script> HTTP/1.1
HTTP Response:
HTTP/1.1 200 OK
Server: SomeServer
Date: Sun, 01 Jan 2002 00:31:19 GMT
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 83
Hello >"'><script>alert('XSS')</script>
@anugu-vijaykanth Thank you for the XSS example, however that does not prove why the locations specified have this issue. Please look at the files you have referenced and explain, how given the input to window.open, script can be injected