CrossSiteScripting.Reflected : Insecure use of document write function (High Severity Issue)

[anugu-vijaykanth]

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

1. Open Appscan go application

2. Checkout the code of Stratos : release 4.4.0 (https://github.com/cloudfoundry/stratos.git) in your local machine.

3. Choose the type of scan i.e. Complete Security Scan

4. Click on Browse button and browse to the src folder(except test-e2e folder) of the stratos project that you checkout in step 2.

5. 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.

6. Click on Create a new scan button ---> Initiate scan : This will initiate the scan process.

7. 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:

https://github.com/cloudfoundry/stratos/blob/master/src\frontend\packages\core\src\shared\components\ssh-viewer\ssh-viewer.component.ts#L122

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 document write function

Possible Implementation

[richard-cox]

Examples is from a trusted source