Social Network For Security Executives: Network, Learn & Collaborate
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” . 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:
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 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.
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.
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>
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:
There are also some notable mechanisms in browsers which allow decreasing the risks of discovered XSS attacks:
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.