OS SEC: Series 3 - Injection

This topic will be a set of 10 articles, where I will talk about the 10 biggest security risks listed in OWASP and how OutSystems prevents these hacker attacks from being applied, without you having to do advanced configurations or even any additional configuration.

I know, I know... Many believe they know how to protect themselves from this vulnerability, in fact many believe that the injection vulnerability is just that of injecting an SQL query code into a search field.

But the truth is that injection vulnerabilities can occur at various points in an application and in different ways.

For example, I believe that most people who read the title injection vulnerability immediately remember this security message from OutSystems:

The famous SQL Injection, which is a high-risk vulnerability, because by exploiting it, it is possible to obtain all the data from the tables that the attacker had access to in the database.

PS: But this warning in the studio does not necessarily mean that your application is vulnerable, because in the OS documentation itself we can understand that some use cases will show this message but we can ignore it if the query is well protected.

Ok Lucas, but what about the other ways you mentioned that there are to exploit the code injection vulnerability?

A recent example is the article I published a few days ago called "OutSystems Security: Carla used this component to hack you" in this article we can see that Carla injected code and it was not SQL.

In addition to this example (Carla) we have a famous one, which is code injection via search parameter:

In the example above, we can see that the search key (in the URL) is reflected in the page code; so what would happen if an attacker changed "outsystems" to:

<h1>OutSystems</h1> ou <script>alert(document.cookie)</script>        

In applications with traditional codes (those made by scraping code), this code injected via URL parameter would be reproduced (rendered) by the page and we would have a possible HTML and XSS Injection, which in turn would show an alert with the user's cookies (in its simplest form).

In OutSystems

"By default, OutSystems escapes content before showing it on the UI. Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) resolves reflected and stored XSS vulnerabilities".

ref: https://success.outsystems.com/support/security/develop_secure_outsystems_apps/how_outsystems_helps_you_address_owasp_top_10/

Yes, by default OutSystems escapes the input parameters, so you don't need to worry about this type of vulnerability.

For this reason we do not find this vulnerability in OutSystems applications, you simply take the parameter data and display it within an "expression" without fear of being happy :)

Okay, this is an example using "Expression" that protects the developer without even knowing about this vulnerability, but what about when it is an input that will later be stored in the database, such as a form or something similar?

As mentioned at the beginning of the article, there are several ways to inject code into an application and one of them (which I like the most) is the ones that are stored, that is, codes that are injected via forms generally, such as comments, profile descriptions and others and these codes are stored in the database.

OutSystems provides a set of sanitization functions that developers can use in advanced scenarios to prevent code injection in HTML, JavaScript and SQL snippets. Using these functions, developers can remove potentially malicious content from user input before it is stored in the database or rendered in the UI

For example, using "BuildSafe_InClauseIntegerList", "BuildSafe_InClauseTextList" or "VerifyJavascriptLiteral".

To further increase the security of your OutSystems application against code injection and execution of external content, we will come up with:

Content Security Policies

Usually, when a hacker exploits a code injection vulnerability, he imports external codes to be executed on your domain, such as displaying an image, changing the CSS, changing the JavaScript, and others.

When the CSP is properly configured, even if it is possible to inject JavaScript tags to call external code, it will not work, because the CSP will block the requests, only allowing the execution of iframes, src, and others from trusted sources.

Want to talk to me? Visit Soares Corp., I am one of the mentors at OutSystems and would love to talk to you about security, help with your questions, and exchange experiences, because together we build safer applications and a better prepared community.

Hug,

Lucas Soares

Here are some other articles where I talk about security in OutSystems:

OutSystems Security: The vulnerable text editor that empowers hackers, do you use it?

Top 5 dicas de seguran?a em OutSystems

OutSystems Security: (IDOR) How to hack your application's Update?

Other sources I used to create this topic:

https://soarescorp.com/

https://owasp.org/www-project-top-ten/

https://success.outsystems.com/support/security/develop_secure_outsystems_apps/how_outsystems_helps_you_address_owasp_top_10/

https://www.outsystems.com/forums/