OutSystems Exploit: 2 things you need to check now in your application, for security.
How does it feel to know that someone with the URL of your OutSystems app can find some very useful information to hack it?
Hacking is illegal, you can go to jail!There is not much talk about hacking or cybersecurity when it comes to OutSystems, and this creates a false feeling that the developer does not need to worry so much about the security of the application when developing.
Consequently, the developer and even some technical leaders ignore the platform's warnings, allow the use of outdated components with known vulnerabilities, in addition to several other warnings such as SQLi, leaving the API documentation enabled in production and even TEST PAGES IN PRODUCTION.
In this article I intend to talk to you about TWO IMPORTANT ITEMS that are easy to find in your application using the OutSystems Exploit tool (https://github.com/5O4R3S/OutSystems-Exploit)
- Test pages in production
- Components with possible known vulnerabilities
Let’s start with the test screen you love to ignore that is in production :)
Test screens in production are more common than you might think, sometimes we create test screens/blocks due to the need to do quick tests, such as seeing the result of a query in a production environment, creating an action to delete a specific record to facilitate cleaning of the database during testing
Things like “GetUsersTest”, “TestAPI”, “TestScreen” and others, generally these screens are made directly in production where we cannot deploy or get directly to the aggregates.
The problem with this practice is that these screens generally don’t even require authentication to access, sometimes they don’t even need a filter to bring up the data, simply by accessing the screen as an anonymous or registered user, it’s possible to bring up the content.
Hacking is illegal, you can go to jail!
By running a simple command in the terminal, an attacker (or hacker) can obtain ALL screens of your application using OutSystems-Exploit, and if there is a test screen, it will be discovered.
Therefore, the security breach in your application will depend on what these test screens allow the user to do.
But Lucas, I need to do some tests in production, what should I do to avoid being so vulnerable?
I know, sometimes it is necessary to use test screens directly in production, but here are some tips to avoid having a headache:
- Do not leave the screen with an anonymous role.
- Set a specific user role in addition to “Registered”.
- After carrying out the tests, turn off the screen.
I hope it’s clear that test screens are super easy to map even for those who have never seen their application in their lives!
Now let’s talk about the components (dependencies) of your application
This part is very important for those who control and manage the OutSystems application, and for this professional, I have a question:
- When was the last time you checked the components that the development team is implementing in the project?
- Did you know that there are components that use libraries with already known vulnerabilities?
Hacking is illegal, you can go to jail!
Yes, it is possible to view all the dependencies that your application uses, running just one command line, and in addition, if any component is potentially vulnerable or exploitable, the attacker or hacker will be informed.
Look at the image above, the “ProtectedApp” application uses some dependencies for its perfect functioning, however some of these dependencies have known common vulnerabilities (CVEs); which opens up an immense possibility of exploitation for a possible attack on the application.
But Lucas, I can’t remove these components, so what should I do?
A sincere suggestion for some actions that will save you a headache:
- Make sure there are no CVE records for the library your component uses.
- If there is a vulnerability, consider changing the component as today at Forge there are several alternatives for the same solution.
- Treat all data input that exists in your application, never trust the “user”.
- Carry out practical tests, as the library may be vulnerable, but the component runs with a low permission on the OutSystems server and in turn does not pose any danger.
OutSystems-Exploit tool allows professional OutSystems developer to create more secure application.
But don’t just rely on that, as this article only serves to show skeptics that it is possible to find information about your OS application, and that we should always be concerned about the security of the application we are delivering to our customers.
Regards
Lucas Soares
Here are some other articles where I talk about security in OutSystems:
Top 5 dicas de segurança em OutSystems
OutSystems Security: Protect your forms right now!
OutSystems Security: How did the user bypass my form validations?
OutSystems Security: The Developer helped the hacker and the Tech Lead will answer for it.
Other sources I used to create this topic:
https://github.com/5O4R3S/OutSystems-Exploit
https://success.outsystems.com/documentation/best_practices/
