#SafeSAPUI5 – EP10

Hello,

*** Default Header ***

With the intention to show why SAPUI5 developers (as most of them came from the ABAP world) need to upskill with “safe programming” knowledge and skills, i’ve decided to create the #SafeSAPUI5.

What is #SafeSAPUI5?

1. A series of episodes with examples (of course with responsible disclosure, not showing names, servers, etc.) of security breaches that were exposed on SAPUI5 apps. The idea here is not to point fingers, but to educate as a “learned mistake” that someone made, to all. I think this is the first series that the creator “hopes” that it has fewer possible episodes ☺️.
2. Encourage developers to also use the hashtag #SafeSAPUI5 around the web on interesting articles, courses (why not?), ebooks or even self made materials, that will help SAPUI5 developers to upskill their knowledge, specially for the security part, also bringing examples that some may had not thought about it.

I try to keep everything as short as possible here, but this researches, analyses, testing, contacting the customers, reporting and getting the bugs fixed takes a long time (not really described here).

SAP has an official bug bounty program, please read more on this link. If you would like to report an SAP vulnerability found, please use the official link here.

*** Default Header ***

Also keeping all the important topics on the matter here: safesapui5.web.app

Ok… So now for the Episode 10 🍿 we have: “Work hard, test hard…“ ⚠️⚠️⚠️:

🎬

In previous episodes i’ve mentioned the Dos/DDos attack, but never went “deeper” on it. I’m not going to perform a real attack on someone just to prove a point or to create an episode, but we can use some tools to “simulate” something similar and demonstrate the impact.

Ok, so now i’ve a HUB FIORI IDES environment to be used on this simulation, just to remember what a HUB FIORI implementation looks like:

So to get a little more technical, i’ve an OData services that exposes a backend RFC (that selects sample data).

So basically a Dos (Denial of Service) attack is someone trying to stop regular users of being able to use your application/server (by taking the server down, use all of it’s memory, etc). And DDos (Distributed Denial of Service) would be the same thing but from multiple sources…

In order to “simulate” multiple connection attempts (like many many users trying to use your application all at once) on my OData service/server, i’m going to use JMeter:

https://jmeter.apache.org/

This approach is also used for performance testings of your SAP server and/or services (Odata, SOAP, etc).

You can see more detailed tutorials on JMeter in SAP here and here.

Basically i’m implementation a sample test plan (as it’s basically a tool intended for performance testings):

JMeter Header

Now simulating 3000 multiple users (threads) requesting the OData service at the same time :

JMeter Users (threads)

Detailing my OData service:

OData endpoint

After the configuration……*** running *** the test plan:

Slow_Stuck server

My server, despite showing available work processes, get’s “stuck” and i’m not able to even navigate between screens for a few seconds… Image if i’ve inserted 3 million users or something…

And the detailed return on JMeter:

Log return

Notice the 3.000 connections, and in some calls the service is not even available anymore (HTTP 503)… So this sample run would result in regular users not being able to user this service at the time…(and the Fiori Apps that uses the service as well)…

There are some documentations about mitigating Dos attacks on SAP and focus on server resources for scenarios like mine, but my goal here is just a proof of concept (that this open OData services can lead to an attack that messes up my server).

A DDos (distributed) would look like this:

Again, if it was an actual attack some other tools would’ve been used, also some IP hiding methodologies (like proxies), etc…  Here i just wanted to prove a point here with the goal to “influence” you to test your own servers and open OData services to see if you’re “secure“. Basically here we’ve only talked about OData services, but most of the time SAPUI5 applications (specially internet facing ones) are the “door” to discover theses services and exploit them (as we saw in previous episodes).

Ok so what can we learn from this episode?

1. That JMeter can be used to performance test your environment, and to simulate all types of scenarios (even for a Dos attack POC). Example: If you’re developing a mobile application that 2000 users will be executing your Odata service at the same time, you can use JMeter to test how the performance and wait time would be.
2.  Always be careful with your “open” OData services left on your SAPUI5 applications exposed on the internet, that can be targeted for attacks like this and make your environment unavailable for real users.
3. Always consider extra security layers, to try to prevent this type of attacks, not just captchas in the SAPUI5 application, if the OData service can be called directly (by looking at the application source code/networks tab, like we saw in previous episodes).

Together with JMeter for performance testings, you can use Gateways performance statistics data, read more about it here.

PS: Please check episode 09, if you haven’t already.

Thanks.

#SafeSAPUI5