*** 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 5  we have: “Custom login, is not a “real” login…“ :

One customer with a custom SAPUI5 application (with internet access, not just inside the customers network), required users to insert their Username and Password on a login screen… so far nothing new correct? If we think about standard auth process flow…

Standard login flow

But going deeper on the application, discovered that the login screen (and also the process flow) was all custom, and the backend connection user was hardcoded (yes, again…):

Hardcoded again

So the login user name, was basically used on backend filters (KUNNR field):

Kunnr based login

“Login Screen”:

Custom Login

There was a service there, that “validated” the User and Password on the backend, to go to the next screen. But with this custom login process, you can easily manipulate the application to bypass the service return and go to the main dashboard screen (or any other screen)… Also after studying the code, the metadata, etc, by knowing a valid KUNNR number (there was a service that returned that), we could create orders, see prices, etc… all on behalf of this KUNNR id (with the same backend hardcoded credentials).

Also filter some customer data like material list, etc:

Material List

As he wave harcoded credentials again, the Odata service list could be explored for other sensitive data, and also Webgui login, etc.

What happened after that? With a full and detailed vulnerability report, the customer is being able to understand this breach and go back to “safety”.

Ok, so what can be learned from this episode?

1. Again, never leave hardcoded credentials on your code.
2. Always use the standard login process, custom ones (specially in SAPUI5/Odata), can be easily manipulated and explored.
3. On your custom applications, that can be accessed over the internet, all types of researchers (some good, some bad) will be analyzing your application, so please be extra careful with the information that could be found on your $metadata. Also, sensitive type of information cannot be exposed on this open Odata services on the internet, because your Odata services will be tested for possible leaks (like the one found on this episode).
4. Again, always revise user access (backend) and audit the types of information that “traffics” on your environment’s OData services (all the other types of services as well, if possible).
5. Prior to releasing custom SAPUI5 solutions (specially if could be accessed from the internet), conduct all types of testings and validations on all possible scenarios (not just business scenarios, also security scenarios).
6. If your custom SAPUI5 solution is very big/complex, internet faced, and will “contain” all types of sensitive data, you should also consider to work with security researches (for security tests, like myself) or with Bug Bounty programs to stop breaches before the bad guys can find them.

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

Thanks.

#SafeSAPUI5