#SafeSAPUI5 – EP02
*** 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?
- 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 ☺️.
- 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: https://safesapui5.web.app
Ok… So now for the Episode 2 🍿 we have: “User and Password list leaked? Like the ones you see on the news…” ⚠️⚠️⚠️:
One customer with a custom SAPUI5 application (with internet access, not just inside the customers network) had done 2 big mistakes:
- Had hardcoded user/password on the code (just like on episode 01), but this user did not have much access (but still, as we saw before, many damage can be caused by that).
- On this page, by metadata analysis, i saw that one EntitySet (from a open OData service, already logged on the backend) returned lists of user inputed data on this application (like a log, to track user changes). But one of this logs, was the ones that the users tried to enter on the login screen (user/password) and his data (like phone number, etc.). So in another words, for this environment, there were a open list of user/passwords (valid users and data).
How it all went down:
Metadata searching and studying:
Found the open service, testing and querying data:
As you can see, list of users/passwords, phone numbers, etc. Just until here, it was a major breach, but to demonstrate to the customer (in order to write the vulnerability report), i went deeper to show some of the damage that could be caused by this breach (Proof of Concept – POC).
So used one of the passwords on the list to login:
Went to his mapped standard FIORI applications, to see many types of sensitive data, like the ones below:
Address, Bank details, Document IDs, etc… etc… The list of sensitive information that could be leaked is bigger, but i’m not gonna go in much more details here, to not disclose the line of business of the customer. Basically you could do anything as this users on the FIORI environment, but to ethically perform this line of work is only necessary to go to a certain point to demonstrate the issue.
What happened after that? With a full and detailed vulnerability report, the customer is being able to work on the fix for this breach and go back to safety, without any user data leaked and being on the news, like the ones listed here.
Again, happy ending for this customer.
Ok, so what can be learned from this episode?
- Again, do not leave hardcoded user/passwords on your code.
- 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).
- 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).
- 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).
- 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.
- Dont write custom authentication forms (as suggested 😎)
PS: Please check episode 01, if you haven’t already.
To be clear, is this because developers wrote a custom authentication form or password reset form? Or is this standard SAP?
It's not a standard SAP application and/or OData service, it was a custom auth/reset form basically.
The idea of #SafeSAPUI5 is mainly focused on custom solutions, to make sure we all build safer ones.
Cool, in that case rule (6) should be "Dont write custom authentication forms".
Just added the suggestion 😀🤝
Since it is SAFESAPUI5, i assume it is deployed on SAP( so it is not openui5), will there be still custom auth here? It requires really special effort to prepare custom auth method. I would delete entire BSP app here if i see a auth method like this. SAP already provides proper auth for ODATA where you can get token and re-use it. If you are using REST API still you can follow same approach. If both auth method not enough, OData allows to use OAuth if you need more complicated auth even SAML can be used. Who prepared above approach is awesome 😀 i am speechless.
Hello Bilen Cekic, how are you? Yes it was a SAPUI5 application...
The custom auth was not really the issue here, because the leaked user/password list was for the actual environment users (real users). You'll see on later episodes some big problems caused by some custom auth applications, ok? They are not secure at all, as you sad.
This is golden. One question though: how do we go about protecting our $Metadata results? Is there anything in the service builder that protects a given entity so as not to expose, say, personal data to the caller?
Hello Lauro Ribeiro,
Thanks for the feedback.
It depends on your requirement, but maybe if your UI5 application uses personal data transfer, you should consider:
1 - Move your application to the Cloud;
2 - Consider using backend JSON REST service approach, that will not contain a metadata so they will not be able to "study" your service layer, just for the calls made on the frontend, ok?