Are you a Technical Leader? When was the last time you checked the external components or code that the team implemented in the project?
Hello, I'm Lucas Soares, Ethical Hacker by Cisco and OutSystems developer +9 years.In this article we turn your attention to the precautions we must take when implementing an integration/external component.
Because of an external component, a hacker had access to the user's sensitive information and redirected everyone to a fake page.
This vulnerability is called XSS Storage and was discovered during a pentesting analysis, where I wrote a report showing details about the vulnerability and presented it to the product owners.
(Hacking is illegal, you can go to jail!)
OK, does your application use forms, inputs, that sort of thing?
Maybe this article is for you! Imagine you have an application with forms, text editors and other forms.
This is super common in all projects, but everywhere you allow the user to enter data is a potential security risk.
OK, OK, I'm not saying to remove everything, but I will show you (not teach) how a hacker got the information and also how you can avoid this in your OutSystems projects.
So let's start!
After carefully looking at the application, I realized that this is how the user sees the biography text editor:
And now, how a hacker sees any input field in a system:
A bit confusing, but to the point, the project's technical leaders did not analyze the components that were being incorporated into the project.
And one of these components was vulnerable to XSS attack... Remember the question I asked at the beginning of the article "When was the last time you checked the comps...bla bla bla"?
If you've never done this in your project, it may be vulnerable.
Ok, Lucas, but how did you exploit this, how did the hacker get user information and even redirect them?
The Top 10 most common security flaws in the world according to OWASP include "Cross-Site-Scripting (XSS)" in third place, now you have an idea of how something so "simple" has such a negative impact on your application.
A hacker never looks at an application to use it normally, he always looks for ways to circumvent the security of that application; and a user input field is perfect for testing script injection.
Luckily, OutSystems by default protect us from this type of attack, take the test and try inserting something like "alert()" in the url or in a variable that shows the result on the screen; you will not be able to inject the code or execute it.
So how did the hacker do it?
This loophole does not exist in OutSystems, but it exists in the external component that was incorporated into the project, in this case a text editor.
And where is the danger? This editor was being used to format the product descriptions, we soon understood that it was possible to save the content typed there to later be displayed on the screen.
When I realized that it was possible to inject certain codes via an editor functionality, the next step would be to save the content to see if it would execute, and BOOM, it did!
So to issue a report, I prepared a payload where, when executed, it performed a Get on a URL passing the cookies and variables, at the same time that it created an HTML overlaying the original screen, thus forcing the user to click and be redirected to a malicious URL.
This vulnerability earned me a CVE (Common Vulnerabilities and Exposures) registration for the discovery.
In order not to take up any more of your time, in resume, we must pay attention to the external components that we implement in our applications, we must look at the versions, if there are no CVEs for the version we are using.
OutSystems creates an insane defense ecosystem, and sometimes due to the carelessness of the professional responsible, we end up creating a huge gap for hackers.
In addition to reporting this to the application owner, I also reported it to the product owner, informing the team's CTO and maintaining contact with the development team.
Okay, Lucas, how can you protect the application from this?
In the OutSystems documentation, we can see that the platform already deals with this type of attack to protect the integrity of the application, but as we are talking about external components in the project, there are some ways to avoid this, every field in which the user can enter data:
About how OutSystems already protects us from this type of attack (except external components): https://success.outsystems.com/documentation/best_practices/security/injection_and_cross_site_script_xss/
Other sources I used to create this topic:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-41592
https://hacker.soarescorp.com/cve/2023-41592/
https://success.outsystems.com/documentation/best_practices/security/reactive_web_security_best_practices/