WebStrike SAST tool from DefenseCode

Identifying Client-Side JavaScript Security Vulnerabilities in SAPUI5 Applications Using SAST

Thursday, March 25, 2021

1. JavaScript Client-Side Frameworks

These days you can find various popular JavaScript frameworks for creating interactive, eye catching and responsive frontends and user interfaces for your applications. Some of the most popular JavaScript frontend frameworks include Angular, React, Vue.js. Security controls implemented in these frameworks can vary significantly from framework to framework. As frameworks mature, with some JavaScript frameworks security controls are already implemented and it is somewhat harder for a frontend developer to introduce a security vulnerability in the code, while other frameworks it’s very easy to endanger your application security with clumsy coding style. In this article we will review security aspects of one of the popular JavaScript frontend frameworks for building user interfaces for SAP applications, more notably, SAPUI5 framework. This article will focus on the security aspects of SAP’s SAPUI5 framework and identification of security vulnerabilities on the source code level using a SAST (Static Application Security Testing) approach.

2. SAPUI5 framework

SAPUI5 framework is JavaScript frontend framework, as described on SAP’s Blog:

“Based on the theory above, SAP introduced an HTML5-based development toolkit, SAPUI5, which encourages one consistent user experience.  By utilizing the theory above, apps built using SAPUI5 are responsive across browsers and devices – they run on smartphones, tablets, and desktops. The UI controls automatically adapt themselves to the capabilities of each device. To do this, SAPUI5 provides robust development concepts to create apps with consumer-grade, browser-based business applications. In a nutshell, UI5 is a client UI technology based on JavaScript, CSS and HTML5. Servers come into play for deploying your applications, storing the SAPUI5 libraries, and connecting to a database. Depending on the environment in which you are using SAPUI5, the libraries and your applications are stored for instance on SAP HANA Cloud Platform or another application server. The favored means to access business data for your application is by using the oData model.”

3. Security vulnerabilities in SAPUI5 framework

If not properly used, SAPUI5 framework is susceptible to various types of security vulnerabilities that usually affect client side JavaScript frameworks. Security vulnerabilities like DOM Based Cross Site Scripting, Code Injection or Open Redirect can be easily introduced in the source code by an unaware frontend application developer. Security vulnerabilities in SAPUI5 framework usually occur when unvalidated and unfiltered user input is passed to a potentially dangerous sink functions without any form of sanity check, sanitization or filtering. User input can usually directly come from URI (URL parameters), HTML form input fields or HTTP headers. In some cases, user input can also indirectly come from the backend of the application in a form of stored database data or file content, but for the purpose of this article, we will focus on a direct user input as described previously. Even though we are focusing on code vulnerabilities in SAPUI5 in this article, a lot of these vulnerabilities can be present in a slightly different form across almost any other JavaScript client-side framework. Most of the SAPUI5 framework security vulnerabilities occur when frontend developer is directly modifying HTML DOM (Document Object Model) structure and appends some user input to it, evaluates JavaScript code in realtime that contains some user input or tries to redirect user to some URL which can be arbitrary changed by an attacker. For the purpose of this article and demonstration, we will create a simple intentionally vulnerable SAPUI5 application that reflects an insecure coding style and which is susceptible to various security vulnerabilities.

4. Vulnerable SAPUI5 frontend application

For the purpose of this article, we will present a simple SAPUI5 application that contains some of the most common security vulnerabilities usually present in client-side JavaScript frameworks. Intentionally vulnerable application is presented in the following code snippets. It is very easy to test SAPUI5 applications in online IDE on the URL https://sapui5.hana.ondemand.com/.

App.view.xml contains elements that will be visible on the web page. In this case we have input textbox and submit button.

App.controller.js is a main application controller which will contain the program code and the application logic.

index.js JavaScript file which will initialize the view.

index.html file where the content will be displayed.

When we run our vulnerable SAPUI5 application, the web visitor will be presented with the following web page. As we can see, the vulnerable application is asking a user to input his username in the input box and click on submit button ‘Say Hello’ to process it.

When we enter DefenseCode as a user input we will get a response shown below.

5. Security vulnerabilities present in our vulnerable SAPUI5 application

Our vulnerable SAPUI5 application consists of two common security vulnerabilities, DOM Based Cross Site Scripting and Code Injection vulnerabilities. Let’s take a brief look into these security vulnerabilities.

  1. DOM Based Cross Site Scripting security vulnerability as described on OWASP web page: “DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.” Basically, an attacker is able to modify DOM structure, so he is able to modify the look of web page or even execute arbitrary code within its context.
  2. Code Injection security vulnerability as described on OWASP web page: “Code Injection is the general term for attack types which consist of injecting code that is then interpreted/executed by the application. This type of attack exploits poor handling of untrusted data. These types of attacks are usually made possible due to a lack of proper input/output data validation“.

To identify security vulnerabilities in our SAPUI5 vulnerable application we will demonstrate the usage of DefenseCode ThunderScan® SAST solution in order to identify security vulnerabilities and their details. First, we need to login into the DefenseCode ThunderScan® SAST main interface.


Once we are logged in with valid credentials, we will initiate a new scan on our vulnerable SAPUI5 application. To select a source code target, we have multiple options, we can upload the source code in a ZIP archive, alternatively select GIT, SVN, TFVC or S3 repository where the source code is located, or select the local directory on the hard drive (which is disabled in ThunderScan configuration by default but can be changed). For this demonstration we will upload the source code as a ZIP archive.

After the source code is selected, we can define a scan name and select the language in which the application is written. DefenseCode ThunderScan® supports 27 different programming languages for Static Application Security testing/source code security analysis. For this particular project we can select JavaScript / Node.js language, but we can also tick the box “Auto-language Recognition” in which case ThunderScan® will automatically detect programming languages used in the source code and run specific security analyzers for them. In this case, we will select “Auto-language Recognition”, as presented on the screenshot below.


At this point we can further configure DefenseCode ThunderScan® SAST scanning options if required, however , we go ahead and initiate a scan now. When we initiate a scan we can see the scanning summary. As presented on the view below, we can see that source code was scanned in less than one second with 3 JavaScript related files being processed and two vulnerabilities discovered – Code Injection of High Risk and DOM Based Cross Site Scripting of a Medium Risk.


6. DOM Based Cross Site Scripting Vulnerability

Let’s first examine the details of the previously discovered DOM Based Cross Site Scripting vulnerability. On the picture below we can see the details of DOM Based Cross Site Scripting under the CWE entry 79. We can see a vulnerable document.write() sink method that reflects user input directly in the web page DOM structure from the user input textbox retrieved from getValue() method from our vulnerable SAPUI5 application.

If we scroll down the right part of the window we can see the details about vulnerable project file and details about the specific vulnerability along with the vulnerability description, security compliance standards violation and mitigation recommendations.

We can further inspect the vulnerability in the ThunderScan® user interface down to the vulnerable source code line in the file app.controller.js. As we can see, highlighted line 8 contains vulnerable document.write() method sink where user input from the textbox is reflected directly on the web page.

We can further examine the user input and functions data flow to identify related variables and functions involved in the manifestation of the DOM Based Cross Site Scripting vulnerability, as presented on the picture below. As we can see on the screenshot, user input flow is starting from textbox getValue() method, gets copied into the variable user and later passed as an argument to the vulnerable document.write() sink method.

We can now try to exploit our SAPUI5 application vulnerable to the now verified DOM Based Cross Site Scripting by injecting some test HTML code into it.

When clicking on ‘Say Hello’ button, we will be presented with the following result screen. As it can be seen on the screenshot below, we have successfully injected arbitrary HTML code to the web page DOM structure. This can be further abused to injecting arbitrary JavaScript code, steal web page cookie (if not HTTPOnly) or to modify web page layout.

To prevent DOM Based Cross Site Scripting vulnerability in the previously presented vulnerable application, user input should be escaped with (for example) jQuery.sap.escapeHTML() method. In that case, secure version of embedding the user input in the DOM would be: document.write (“User name is: ” + jQuery.sap.escapeHTML(user));

Another very common way to introduce a DOM Based Cross Site Scripting vulnerability in the source code is through SAPUI5 rendering controls. Screenshot presented below is demonstrating another vulnerability discovered by DefenseCode ThunderScan SAST when a developer is using user input for dynamically constructing an <A HREF> link using sap.ui.core.RenderManager write() method. To prevent DOM Based Cross Site Scripting in the code below, developer should sanitize the user input with writeEscaped() or writeAttributeEscaped() SAPUI5 methods.

There are of course numerous ways to introduce DOM Based Cross Site Scripting vulnerabilities in SAPUI5 framework code. Two methods that should be used carefully on HTML elements are sap.ui.getCore.byId.setContent() and sap.ui.getCore.byId.setDOMContent().

7. Code Injection Vulnerability

One of the most dangerous and often a hackers favorite include Code Injection vulnerabilities. Code Injection vulnerability occurs when program code is evaluated (usually) in real-time and consisting of some user input embedded into the evaluated code, without a proper sanitization of user input. Our SAPUI5 vulnerable application has one Code Injection vulnerability by CWE 94 as identified by DefenseCode ThunderScan® SAST and presented below.

Let’s examine the user input data flow of the Code Injection vulnerability down to the vulnerable sink, eval() function. As we can see on the ThunderScan® screenshot below, user input is taken from the input textbox by getValue() method, copied into user variable and later concentrated to the variable userhello where it is used as the part of a JavaScript program code that will be evaluated in realtime in eval() function on line 10 of app.controller.js SAPUI5 vulnerable application. We can examine each step of the data flow by clicking on tainted input variables as they progress through the code.

User input gets copied into user variable on program line 7 as presented on the data flow snippet below.

Later on, the very security failure of the developer of this application is appending the user input into the userhello variable where the user input is just stacked as the parameter of document.write() method that will be evaluated dynamically, as presented in the screenshot below on the line 9.

In the end, document.write() dynamically evaluated user-controlled code stored in userhello variable, on the line 10 of file app.controller.js as presented on the screenshot below.

This Code Injection vulnerability is easily exploited. All that an attacker needs to do is to escape from double quotes in a dynamically created document.write() method on line 9 of app.controller.js userhello variable and he can inject any arbitrary JavaScript code that he wants into the running JavaScript application in the context of a user’s browser. Let’s try to escape from a dynamically created document.write() method evaluated on line 10 and inject some arbitrary JavaScript code as presented on the screenshot below.

As we can see, when our input is concatenated to the userhello variable, it will actually become like this:

var userhello = 'document.write("<br><br>Hello user " + alert("DefenseCode Code Injection") + "");

So, we have successfully escaped from double quoted string and now we are able to perform an arbitrary Code Injection and execute for example JavaScript function  alert() as presented on the screenshot below. Of course, this is just for demonstration, in real world, malicious attacker could steal user session cookie (if not set as HTTPOnly), perform actions on a web page under the user privileges, modify the web page layout or steal some sensitive data from the web page DOM structure.

It is very important not to include parts of the user input from URL, Input boxes, HTTP Headers or any other source that an attacker can tamper with into the portion of the code that will be dynamically evaluated on the web page.

8. Conclusion

SAPUI5 framework can be susceptible to common JavaScript security vulnerabilities just as the most other client-side JavaScript frameworks if it’s not properly used. For a detailed analysis of security vulnerabilities, it is recommended to verify your source code security using SAST (Static Application Security Testing) with tools such as DefenseCode ThunderScan® SAST, which can pinpoint even the most complicated code and data flows and the exact code line which contains a security vulnerability. Even more, it is advised to introduce SAST into your CI/CD (Continuous Integration/Continuous Deployment) pipeline for constant security monitoring and code security improvement over every code build.

This post was originally posted at https://www.defensecode.com/identifying-client-side-javascript-security-vulnerabilities-in-sapui5-applications-using-sast/

Lexington Soft also offers the SAST tools DefenseCode WebStrike to help you find and fix security vulnerabilities in your applications. Contact us today for more information or request a free trial of WebStrike!