With this article we are starting new series of posts giving a review of one of the most frequent vulnerability which affects a lot of SAP modules: cross-site scripting, or XSS. XSS is by far one of the most popular vulnerability indeed in all products and a most popular vulnerability in SAP products with a total number of 628 vulnerabilities that is almost 22% of all vulnerabilities ever found in SAP during 12 years. You can find this in our latest research “Analysis of 3000 vulnerabilities in SAP” . Only ERPScan researchers have reported about 52 XSS vulnerabilities in SAP products (by mid-2014).
Figure 1 – Ten of the most common vulnerabilities in SAP
XSS usually appears if:
- Server does not handle special characters typed by the user – ‘”& <>;
XSS is traditionally divided into several categories, described below.
For this type of attack, malicious code has to be stored on a remote server. For example, an attacker injects this code by reforming the name of an object which he is creating on the server. For instance, it can be a file name in SRM system. When after attack a legitimate user requests some information such as a list of files his browser will execute malicious code uploaded by attacker.
The listing shows that the attacker can use the variable ‘id’ to inject code (string 15) because ‘id’ value will be displayed on the user’s screen without any filtering (string 28).
So the exploit for this vulnerability is the following query:
In this case malicious code is not stored on a server but executed by the victim user at the moment he opens malicious link such as:
In this case, to exploit vulnerability we need to somehow send a link to exploit to the victim. This type of XSS is less powerful because it needs user interaction, but much more popular than Stored XSS.
Figure 2 – Example of page vulnerable to cross-site scripting
Let’s look deeper into this vulnerability looking at SAP Security Note 1788080 .
To avoid such vulnerabilities, you must always remember to screen/filter any user input. In our example of DOM XSS, the variable ‘id’ has to be re-laid to the method ‘URLEncoder.encode()’ firstly because its value is used as an HTTP request parameter.
Figure 3 – Necessary action to close the vulnerability
To sum up, there are some tips on preventing XSS vulnerabilities during development:
- never insert data from untrusted sources (including any user input) into an HTML page;
- screen HTML from untrusted sources before inserting it into HTML Element Content;
- screen HTML tag attributes from untrusted sources before inserting them into HTML Element Content;
- screen JSON from untrusted sources before inserting it into HTML Element Content or using it in JSON.parse;
- screen CSS from untrusted sources before inserting it into HTML Style Property Values;
- screen URLs from untrusted sources before inserting them into HTML URL Parameter Values;
- protect your systems from DOM XSS.
There are also some notable mechanisms in browsers which allow decreasing the risks of discovered XSS attacks:
- HTTPS Cookies protection – Secure cookie while using HTTPS.
Stay in touch with us, as next week we’ll come back with the new article describing how to secure different SAP Applications from XSS.