Description
A XSS attack is possible by supplying a bogus themeRoot to a HTTP application, for example any BSP application, that will then reference the external themeRoot, without been able to verify that the pointed at theme is actually safe.
Problem Description: There are some situations that a framework or application on the ABAP server received information from the outside that it would then potentially use in the next steps of its interaction with the browser. The problem is that this externally received information could actually point to website that is not trusted. For example: we have the following start-up URL:
/myApplication?use-css-file=http://company.portal.com/ourTheme.css
Typically, the application “myApplication” now takes that string specified for “use-css” and render it out in inside the HTML page send to the browser to load this specified style sheet. Thus, in the HTML, we see a sequence similar to:
<html>
<header>
<css src=” http://company.portal.com/ourTheme.css”>
This will cause the browser to load this alternative CSS file from the company portal.
However, CSS files can also contain and execute JavaScript files. Let us assume someone leaves such a start-up URL somewhere in the Internet, or in an email, with the following format:
/myApplication?use-css-file=http://unknown.com/full.JavaScript.css
If this application “myApplication” now takes that string specified for “use-css” and render it out in the HTML to the browser, then the user that clicked on that link will load a CSS file that could potentially execute unknown JavaScript code.
How does the application “myApplication” know that the value specified for “use-css” is actually in a valid range (points to a trusted server or a server in a trusted domain)? For this, this whitelist infrastructure allows the application to verify that the value of “use-css” to be in a trusted range.
How does this whitelist works? By itself, the whitelist is just a passive infrastructure; it does not do any security relevant work. It is just a store where applications or frameworks can check that the received data fits to a set of configured data to be in a valid range. However, the responsibility lies with each application or framework to check each type of parameter that can be set from external and then used to control the rendering to the browser. The application uses the API call to verify that the received data is valid.
A similar example would be an exit URL to which the application will navigate after it has completed successfully its work:
/myApplication?exit-target=http://competitor.com/we.are.better.html
If such an URL is constructed and left in the Internet, it will cause the application to navigate to unknown targets when it has completed.
In all of these scenarios, it is the responsibility of the functionality provider, to validate all received input before it is used. For central framework provided functionality, the framework itself must validate these specific URL parameters to be in a valid range against the whitelist. For BSP as a framework, these parameters which can be set externally (sap-exiturl, sap-themeRoot, style_sheet), are validated before been used.
Note: if a BSP application itself also has additional parameters with similar behaviour, it is the responsibility of the application to validate these parameters.
Available fix and Supported packages
- SAP_BASIS | 620 | 640
- SAP_BASIS | 700 | 700
- SAP_BASIS | 710 | 710
- SAP_BASIS 700 | SAPKB70003 |
- SAP_BASIS 620 | SAPKB62054 |
- SAP_BASIS 640 | SAPKB64015 |
- SAP_BASIS 700 | SAPKB70006 |
- SAP_BASIS 620 | SAPKB62057 |
- SAP_BASIS 640 | SAPKB64016 |
- SAP_BASIS 620 | SAPKB62058 |
- SAP_BASIS 700 | SAPKB70007 |
Affected component
- BC-MID-ICF
Internet Communication Framework
CVSS
Score: 0
PoC
Detailed vulnerability information added to RedRays Security Platform. Contact [email protected] for details.
URL
https://launchpad.support.sap.com/#/notes/853878
