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 3  we have: “Be extra careful with documents, and how to secure them…“ :

One customer with a custom SAPUI5 application (over the internet, not just inside the customers network), required (among other things) users to upload some documents (for a specific scenario). For this application, the mistake was not on how or where to store them, but not considering the security aspect on when to make them available to be selected/viewed/downloaded on the application itself. Basically, the Odata service used on the application could be exploited (from anywhere) to retrieve all of the documents that the users uploaded on the SAP environment, and also to download them!

As you may know, SAP Gateway works with media links (read more about it here), same way as attachments are available to be downloaded or uploaded on standard FIORI applications for example.

How it all went down:

App / Metadata analysis

Found the service returning the documents, by the metadata (field names and Entity name) i could tell that it was regarding documents:

Data returned

By counting, there were 93K documents exposed:

Breach Size

As you could imagine, there were all types of documents on that list (seeing by the description name of them), but i’m not gonna go in much more details here to not disclose the line of business of the customer. To demonstrate to the customer (for the vulnerability report), i went a little deeper to show some of the damage that could be caused by this breach (Proof of Concept / POC).

So i’ve showed how easily it was to download a file:

Local download

That i knew (by the description) that it was someones current (and valid) passport copy:

Real passport copy

So by combining these 2 services, all of this documents could be extracted and “stolen” from the customers environment. Also could (from time to time) check for new documents (even automatically) and also download them, as almost someone could be tracking all of the documents without breaking into your system.

*** This PDF file was deleted after the report ***

Imagine what could be done with this documents copies? Like passports, IDs, etc… Many many bad scenarios could happen (identity theft, new bank accounts, etc.).

What happened after that? With a full and detailed vulnerability report, the customer can now work on the fix, without any more documents leaked and being on the news, like the ones listed here.

Ok, so what can be learned from this episode?

1. 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).
2. 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).
3. 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).
4. 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.
5. Make sure to only allow that specific user (after a login, correctly inside your environment) to see his specific documents, not someone else.

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

Thanks.

#SafeSAPUI5