Skip to main content

Web Static Application Security Testing

OutSystems

Web Static Application Security Testing

OutSystems enables customers to develop applications in record time using a visual language in Service Studio. Each time a developer performs a publish operation, the visual code is translated into a specific format and uploaded to the OutSystems Platform Server where the Code generator converts it to source code (.NET/C#). The code is then deployed in application servers where it is executed.

In order to be able to perform Static Code Analysis for Security purposes, customers need to obtain the source code and submit it for analysis.

This document describes the static code analysis process for security purposes, starting at the export of the source code generated by the Code generator, to analyzing the results.

When dealing with the static code analysis process, there are some architecture considerations to be taken into account, namely when using OutSystems Cloud or On-Premises deployments and web or mobile applications. The description and process of implementing SAST for Web applications can be found below.

Extracting Web Applications source code

Instructions

When any code is published using the OutSystem platform, it is first translated into pure .NET/C# , next it is compiled and then deployed to IIS. As such, there is a folder on the platform server where the .NET source  is stored. Customers often take advantage of this and run their  tools against this. The source code can be found at <PlatformInstallationFolder\Platform Server\share\<ModuleName>\full and includes an actual Visual Studio .NET project, C#, .aspx, CSS, and JavaScript resources.

As a best practice for frequently running static code analysis, consider licensing an additional production environment, and use it to run your static code analysis.

The share folder with the source code is not available to customers using the OutSystems Cloud. Thus, customers need to have a self-managed environment and use Lifetime (running on the OutSystems Cloud) to stage code to the customer-managed environment where static code analysis will run. The requirements are explained below.

Cloud

It is not possible to extract the code generated by OutSystems directly from the OutSystems Cloud. In order to obtain the generated code, Customers must have at least one On-Premise environment meaning that a Hybrid Deployment is necessary.

Hybrid Deployment

Hybrid deployments enable Customers to have some environments On-Premises (or other cloud providers) and other environments hosted on OutSystems Cloud.

In order to successfully create a Hybrid deployment, instructions can be found here.

From this point, obtaining the applications source code for static code analysis is the same as an on-premise installation.

On-Premise

Customers that have an OutSystems On-Premise installation can obtain the code to perform Static Code analysis following the instructions below.

Reviewing results

When reviewing static code analysis results, it is important to keep in mind that each static code analysis tool will report on findings without a proper context. These findings must be reviewed to detect false positives and experts in OutSystems development shall be consulted to help on understanding those findings in the proper context.

Following are some examples of such findings and why they should be considered false positives.

Code Injection: Improper neutralization of directives in dynamically evaluated code (Eval Injection)

Details: eval() is a JavaScript function that receives HTML code, evaluates it and runs every JavaScript code inside <script> tags, hence the potential vulnerability.

OutSystems makes heavy use of JavaScript and <script> inline tags. The usages are trusted and ok to be executed. Therefore, OutSystems has added the unsafe-inline and unsafe-eval policies to our default Content Security Policies directives.

These potential threats in the form of inline scripts would only be possible to execute if the application is not protected against XSS attacks. OutSystems is by default well protected against this and customers need to specifically allow inline expressions in order to open up for this attack. These openings are accompanied with security warnings at design time, in the Service Studio (OutSystems IDE).

In order to increase the security level, there is a mechanism described in Apply Content Security Policy article.

Remaining Risk: If the user input is not properly validated and it is written into a web page unsanitized, the application may be exposed to XSS attacks. This risk can be completely neutralized by protecting all user input (that will be written on a web page) with OutSystems built-in actions to sanitize JavaScript and HTML: EncodeJavaScript and EncodeHTML, respectively.

More information can be found here.

Credentials Management: Use of hard-coded passwords

Details: Static code analysis tools typically raise a flag when the password word is anywhere in the code.

The files where this flag is normally raised are SQL Server, Oracle and DB2 database connectors. None of these files have hard-coded passwords, but they do have variables named password. All values for the password variables are obtained dynamically.

This can be verified using decompiler tools and inspect the flagged DLL files to confirm that there are no hard-coded passwords there.

Cross-site Scripting (XSS): Improper neutralization of script-related HTML tags in a web page

Details: Most of the flags will be raised on file osjs.js. This happens because OutSystems uses the jQuery query selector $, which is known for being vulnerable to XSS in some earlier versions of jQuery, including the one that the platform uses.

OutSystems makes its own implementation of $, protecting it against XSS, so this is likely a false positive.

More information about this can be found in this article.

Cryptographic Issues: Use of a broken or risky cryptographic algorithm

Details: This issue is typically flagged when default random generators or hashing functions are used, assuming that those functions are being used for cryptographic or security related operations. This may not be the case and using a random() or hash() is perfectly fine if the results of those functions are not used to encrypt or authenticate content.

Since OutSystems does not use weak functions for cryptographic ends, this should be considered a false positive. This finding is commonly flagged when analyzing the file OutSystems.RuntimeCommon.dll, which contains some random and hash functions but they are not used for cryptographic or security-related operations.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Details: OutSystems does not explicitly perform SQL Injection validation on all SQL queries that are executed by applications. However, the platform has a SQL sanitization built-in action available that allows developers to validate all user inputs that are going to be used in SQL statements.

Therefore, it is the developer’s responsibility to guarantee that all user inputs are sanitizing before being used in a SQL statement. Moreover, OutSystems displays a warning at design and compile time when a pattern that may introduce a SQL Injection vulnerability is detected.

 

Technical Support from OutSystems

Technical Support and OutSystems Security Teams are ready to discuss the findings of the static code analysis with customers, as follows:

We expect customers to involve one of their trained OutSystems engineers to do a preliminary analysis of the report, and report to OutSystems Technical Support only the issues that are likely to be caused by the platform.

The list of issues reported to OutSystems Technical Support should exclude issues that can be fixed by developers, by changing its OutSystems applications.

Technical Support's reply may include:

  • A reasoned identification of false positives;
  • A reasoned adjustment of severity based on the specifics of the technical environment;
  • An escalation of eventual product defects to R&D;
  • The classification of an issue as "to be solved in the application”.

Furthermore, the following tables can help understand the responsibilities and expectations by deployment model:

Hybrid

Responsibilities Expectations
Customer
  • Deploy and manage the on-premise environment;

  • Extract the applications source code for static code analysis;

  • Execute the static code analysis;

  • The customer has knowledge of how to configure and manage OutSystems and underlying technologies;

  • The customer has knowledge of the tool(s) used to perform Static Code Analysis;

  • The Customer is responsible for extracting the code, submitting it for static code analysis, collecting the results, reviewing the results, performing the necessary correction and re-checking.

OutSystems
  • Maintain and manage OutSystems Cloud;

  • Help Customers set up the Hybrid infrastructure;

  • Provide support to Customers on issues related with OutSystems.

  • Has expert knowledge on OutSystems Cloud;

  • Has expert knowledge on OutSystems;

  • Is able to help Customers with OutSystems related issues (support terms);

  • Is able to reply to Customer questions.


On-Premise

Responsibilities Expectations
Customer
  • Deploy and manage OutSystems on-premises;

  • Extract the applications source code for static code analysis;

  • Execute the static code analysis;

  • The customer has knowledge of how to configure and manage OutSystems and  underlying technologies;

  • The customer has knowledge of the tool(s) used to perform Static Code Analysis;

  • Customer is responsible for extracting the code, submitting it for static code analysis, collecting the results, reviewing the results, performing the necessary correction and re-checking.

OutSystems
  • Provide support to Customers on issues related with OutSystems.
  • Has expert knowledge on OutSystems;

  • Is able to help Customers with OutSystems related issues (support terms);

  • Is able to reply to Customer questions.

  • Was this article helpful?