All Articles

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 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” [1]. 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

Attack

XSS is dangerous because it allows an attacker to execute arbitrary JavaScript code in the context of the attacked user’s session. The code can yield access to cookie files, session tokens, and other critical data stored by the browser and used to work with the website. The attacker can get access to the user’s session and obtain business-critical information, or even get absolute control over the system. XSS can also be used to illegally change the data displayed on a website (phishing).

XSS usually appears if:

• Server does not handle special characters typed by the user - '"& <>;
• Server allows you to send dangerous values as a parameter, which allows to execute JavaScript code from other sources.

XSS is traditionally divided into several categories, described below.

Stored XSS

For this type of attack, malicious code has to be stored on a remote server. For example 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.

Extremely powerful and business-critical attack with using this vulnerability was presented by us in SAP SRM long time ago, during one of SAP Security Assessments, and was described in SAP Security Note 1284360 [2]. In this organization, SRM system was used for bidding, and every supplier was able to post their bidding documentation with information about service and its price. The system was vulnerable to Stored XSS, so it was possible to inject malicious JavaScript code into file name field. When Company’s employee from purchasing department opens a folder with a list of file names to see newly uploaded documents, injected code automatically executes and the attacker gets access to Company’s employee account. By using this account, he manages to get access to Competitors bidding documentation and to find documentation about competitor’s service and price. This gives him a possibility to win Bidding by adjusting his price.

Reflected XSS

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: http://example.com/search.php?q=<script>DoSomething();</script>

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.

As an example of critical attack, you can embed into JavaScript code, not just a stealing user session located in Cookie, but it is also possible to execute an ActiveX component installed on victim’s workstation. Thus, it will be possible to get full access to his workstation by one of the ActiveX vulnerabilities. And as a result you get access to the corporate internal network and are one step closer to SAP Server itself with all corporate data.

DOM XSS

In this type of XSS, the attacker changes the DOM (Document Object Model) environment of the victim’s browser page so that some of the scripts on this page execute malicious JavaScript code. Let’s look deeper into this vulnerability looking at SAP Security Note 1788080 [3] for example.

The vulnerability exists because user input in the JSP script ‘error_msg.jsp’ is not filtered, so an attacker can inject malicious JavaScript code into a page.

Figure 2 - Example of page vulnerable to cross-site scripting

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: http://example.com/dir/start/error_msg.jsp?id=1111"> <script>alert(123)</script>

General defense

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 JavaScript code from untrusted sources before inserting it into JavaScript Data Values;
• 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:

• use the flag ‘HTTPOnly’ for cookies - this security measure will prohibit getting user session values form cookie files by JavaScript;
• implement Content Security Policy - this security measure will restrict using JavaScript within the domain;
• 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.