*** 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).
*** Default Header ***
Also keeping all the important topics on the matter here: safesapui5.web.app
Ok… So now for the Episode 9 🍿 we have: “Miscellaneous…“ ⚠️⚠️⚠️:
This time i’m not gonna talk about a specific customer with a big security issue available, but about 3 customers with “smaller” types of issues, but that could also be exploited by the bad guys.
1 – Customer was using UserRequestManagement to request user password resets:
By as we saw on my first security post, this service can also be used to create users…
Notified them to “block” the user creation “part” of the service, not allowing remote user creation…
2 – Customer had some Odata services returning timeout on query without parameter:
As we can see below, timeout services:
Can be used to perform Dos or DDos attacks on their services, as they consume a lot of memory because there were probably SELECT * statements on the backend… Notified them to fix this issue and keep their services “clean”.
3 – Google Analytics available ID:
One customer uses Google Analytics to track their user data on the overall application:
But the ID comes from o OData backend entity, in order to try to “hide” this ID (not leaving as hardcode on the frontend itself), trying to prevent hijack attacks or other types of analytics attacks (specially for the type of data that he saves there). You can find more about Google Analytics type of attacks here and here.
Basically they were all notified about this breaches and can now focus a little more on secure solutions.
PS: Please check episode 08, if you haven’t already.