#SafeSAPUI5 - EP01

[jose_sequeira]

Hello,

Based on the success and feedback of my previous post, i've decided to take things a little deeper regarding "safe" SAPUI5/OData solutions:

If you've read the previous post, you can see that the goal was to alert developers/architects regarding the dangers that a "flaw" on a exposed (and also on the internal customer network) SAPUI5/Odata Apps design (profiles, role, code review, etc.) can cause to the customer environment.

But where did it all came from? I've been (for some time now) writing some ebooks on SAP tech, and one of them is regarding the usage of SAPUI5. When i say usage, is based on what can we do, what has been done (some of my examples and online samples), scenarios (Online, Offline, plugins, etc) and ideas. So for some time i've been searching online some usages of SAPUI5, and i've came across many improvement opportunities and specially exploitable flaws. That got me motivated (even before the book is finished) to create the first post on the matter, specially for the scenario reported to the SAP Security Team (mentioned on the post).

So 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.

Ok... So now for the Episode 1 🍿 we have: "Hardcode is never a good solution" ⚠️⚠️⚠️:

🎬

One customer with an SAPUI5 application, had hardcoded credentials for the OData calls on the source code (and the application was accessible over the internet / "exposed"):

Harcoded credentials

Also, hardcoded (commented) URLs "showing the way" around their OData services:

Commented URLs

Code leftovers that could lead to exploits with usernames, etc:

Code leftovers

Code header template like on the "ABAP World", also had some user/names that could be used in exploits:

Code Header

As of any service, the metadata could be studied for exploits (entities, etc.):

Scary! 😱

Ok, so what happened after i've discovered that? I've created an vulnerability report (in details) and got in contact with the customers IT department. I've showed that the user left on the code was an working user, that had access to the OData service tree and potentially sensitive customer data.

So after that, explained the recommendations and also advised to immediately switch to a SICF logged service on the backend instead (as a "fast" solution), and remove the exploitable points from the source code (and a few other things). Also exchanged some ideas about re-designing this application on a "safer way", and still meet the requirement.

Happy ending for this one (all the issues are now fixed).

Thanks.

#SafeSAPUI5