How many times have you seen this message in your OutSystems projects? And how many times have you right-clicked and chosen "Hide Warning"?
If you do this, I'm sorry to tell you YOUR PROJECT IS EXTREMELY VULNERABLE!
Ok, but let's take it easy, if you as a professional followed OutSystems' recommendations and best practices regarding the use of SQL Queries, then everything is fine.
(Hacking is illegal, you can go to jail!)
Otherwise, you'd better read this article, and I'll show you (not teach) how this little warning will give you a headache.
Let's start!
I talked to some colleagues, and I realized that we generally ignore this warning BECAUSE WE DON'T KNOW how to test it, and because we don't know how to test it, we create a false sense of security that it is something complex and will never happen to you.
Clearly, OutSystems by default takes several security and prevention measures INCLUDING this type of attack, which is why if you go to the input and try to inject some SQL code and press search, nothing will result in most cases.
Even aggregates are optimized and recommended for searching information in tables, as they already have complete security against this attack.
However, in large projects there is a need to develop our own queries, so now our application begins:
Imagine a screen where the user can search and list the application's users, this is common in several applications.
So this is how the average user sees search:
And now, how a hacker sees this same search:
Realize that the hacker is not using the (visual) screen, in fact, the hacker intercepted the request made to the server and is now able to manipulate the information.
Ok, Lucas, but until then, normal, he is seeing the same information that is displayed on the screen.
That's true, but if the hacker intercepted the request, what happens if he starts manipulating the data to get a different result?
Boom! Your application has been hacked!
Observe that until this moment, a small code was injected next to the search parameter, which allowed the hacker to list ALL USERS of the application; crazy, right?
Once the existence of a SQLi vulnerability has been validated, the hacker can inject other types of SQL code to obtain data from any table, including listing the name of all tables and their columns, whether they are in your application or not.
Do you realize that this attack was only possible because you (professional) decided to ignore the OutSystems warning?
Now I ask you: Do you have these warnings in your projects or those of your client? And are you treating it (implementing OutSystems best practices) or did you just decide to hide it?
In OutSystems' own documentation, in cases where you need to use input parameters in your query, it is recommended to use sqlencode or BuildSafeClauses, for example.
The important thing is that you process ANY user input data before executing or storing.
Here are some other articles where I talk about security in OutSystems:
Why did Tech Leaders unknowingly give access to the hacker?
Is it possible to create small games in OutSystems?
OutSystems Security: The hacker discovered all my API endpoints, now what?
Other sources I used to create this topic:
https://soarescorp.com
https://success.outsystems.com/documentation/11/reference/errors_and_warnings/warnings/sql_injection_warning/
https://success.outsystems.com/documentation/best_practices/security/injection_and_cross_site_script_xss/
Hi @Lucas Soares ,
I get that you are trying to educate about what the consequences are of not following security best practices.
But the example you use doesn't really make sense to demonstrate the dangers :
1) if the screen is a list of users, with a search box to filter on email or username, then the end user can ALREADY see all users by just leaving the search value empty, he doesn't need to do any of what you call "hacking" for this
2) whatever is entered in the search box, would be used as a filter value in the sql, so there is no reason in this example for the developer to set Expand Inline (default false) to true.
Dorine
Hi Dorine, I hope you are well.
It's a pleasure to be able to write for you, the article is to talk about SQLi and the consequences of ignoring the platform's visual warning.
And for this the article has all the elements that lead to an SQLi, "Warning", "Advanced SQL" and the "expanded inline" configuration.
Having clarified that, now I would like to explain why it is not prudent for me to write an article using 100% real and detailed information, but first let's get to the answers to your questions:
"1) if the screen is a list of users, with a search box to filter on email or username, then the end user can ALREADY see all users by just leaving the search value empty, he doesn't need to do any of what you call "hacking" for this"
Answer: You were right that the user can leave it blank and view the list of users, but you got the context of the article wrong.The context is not to list the users, the context is to show in the article that this field allows you to inject SQL code, regardless of whether it is a query in the users, clients or other table, so the idea is to show that this user input is vulnerable.
Answer: The expanded Inline used in the example is to activate the studio's warning, and compose all the elements necessary to build the article's narrative, and there was no need for this query to set the expanded inline to true.
In almost 99% of the projects I participate in, the SQLi warning is hidden by the developer himself, which is why the intention of writing this article to show the consequences of ignoring the good practices defined in the OutSystems documentation.
The intention was not to put a complex screen, a complex query to justify the expanded inline or even the use of Advanced SQL, as the language of the article needs to be easy to read for the junior developer, although I see senior projects with warnings of hidden SQLi.
I reread my article and found all the elements that promote a vulnerability in the application, we have:
- A table- Screen- An advanced wants- An Exapnded Inline parameter- A warning being shown in the studio
I understand that perhaps you were expecting a super article rich in details about the vulnerable application and how it was possible to exploit it, but I cannot include information rich in details, only the elements or items that together make up the purpose of the topic.
This is easy to understand since if I create an article rich in details, I would be teaching how to explore, tools used, paths and so on, thus creating an intention contrary to my objective which is "to show the importance of not ignoring the warnings that are displayed in the studio" and do not teach how to hack.
And finally, when I received the invitation to be part of the OutSystems vulnerability exploration group at HackerOne, there are several rules, such as not being able to talk, disclose or share certain things about security.
Dorine, sorry for the long answer, but I believe I have now given a little more context to your question.
Until later,