The Open Web Application Security Project (OWASP) is a non-profit organization whose goal is to raise awareness and broaden developer understanding of the most common security flaws found in modern applications. Beginning in 2003, OWASP began to produce a top 10 list of these flaws that focuses primarily on those most easily-rectified.

By referring to the list and free resources available at OWASP, developers can make the changes necessary to secure their applications better. Just recently, OWASP updated their list. As technology evolves, and the popularity of development platforms ebb and flow, old risks die off and new vulnerabilities appear.

This most recent list merged two previous threats into one, bumped two off the list, and introduced three previously unseen. In this post, we’re going to look at the new list, provide examples of each, and discover which steps, if any, the OutSystems platform takes to mitigate these risks automatically.

1 - Injection

Status: Unchanged

Many have heard this term, yet some in the developer community remain woefully ignorant of injection threats (I know quite a few of them). An injection is any attack designed to manipulate interpreted database and ORM queries.

Injections prey on developers who fail to sanitize their inputs before introducing them into a query. For example, let’s look at the following interpolated SQL statement:

`’SELECT * from USERS where user_id=‘ + request.getParameter(‘user_id’)`

The author of this snippet assumes the request comes in with a valid user identifier, like 12345. However, an attacker may exploit this assumption by modifying the URL parameters like so:

`’1 or 1=1’`

By passing this query parameter directly into the SQL statement, the code returns every user in the database and exposes their personal information. Whoops. OWASP therefore suggests developers sanitize all inputs before statement execution or avoid interpretation entirely by using safe APIs.

So how does OutSystems fight injection? By default, it escapes all content before presenting it to the user. If developers wish to disable our default mechanisms, they may use our JavaScript, HTML, and SQL encoding/sanitization functions that escape and delete malicious content.

Beyond that, the OutSystems IDE presents design-time warnings to developers when they construct patterns that expose their applications to injection threats. Overall, the risk of injection is low when building applications and generating interface elements using standard OutSystems modeling techniques. Custom JavaScript and backend scripts may remain vulnerable to injection, however.

Learn more about Injection from OWASP.

2 - Broken Authentication

Status: Unchanged

Broken sounds a bit strong to me, but any application that permits credential stuffing, brute force entry, or weak passwords is at risk of breach. In addition, OWASP warns that single-factor authentication is insufficient, unhashed passwords are liable to data theft, and immortal session IDs leave public access devices susceptible to security breaches.

OWASP suggests developers enforce multi-factor authentication, rotating session IDs with expiration dates, strong passwords, strong hashes, limited login attempts, and more.

The risk of broken injection is low with OutSystems when authentication uses standard OutSystems protocols. Also, OutSystems does not include personally-identifying information (PII) or session tracking data within cookies or URLs. Moreover, sessions receive unique identifiers at login and feature an expiration time. Lastly, OutSystems encrypts all passwords using strong encryption techniques. when performing authentication with standard OutSystems user protocols. It should be noted that risks may increase for developers who implement custom authentication or store credentials independently.

Learn more about Broken Authentication from OWASP.

3 - Sensitive Data Exposure

Status: Moved (previously: #6)

Unfortunately, applications must present and transmit data between clients, servers, caching mechanisms, load balancers, databases, and other intermediary data owners. Unnecessary caching, unverified server authority, weak encryption, default keys, and plain-text representations of PII all place users at risk.

OWASP recommends that developers cache as little data as necessary, encrypt data at rest and in transit, ensure secure communication protocols between every component, and refactor legacy tools to meet the latest in security standards.

By providing access to strong encryption techniques out-of-the-box, the OutSystems platform enables developers to secure their data at rest and in transit. And, OutSystems supports secure communications between endpoints, clients, and third-party integrations. Therefore, sensitive data exposure is not very likely when developers make use of available encryption techniques and rely on the OutSystems cloud to request and receive data from external sources. Risk factors may increase for those who incorporate handwritten AJAX, backend requests, and data storage protocols.

Learn more about Sensitive Data Exposure from OWASP.

4 - XML External Entities (XXE)

Status: New

A brand new entry as of 2017, attackers have begun to exploit legacy XML processors to access private data, enter secure networks, and perform denial-of-service attacks. OWASP believes the majority of these vulnerabilities exist in older technology where XML processors dereference and evaluate external URIs.

Solutions include switching to simpler data formats (JSON), upgrading all processors and libraries, updating SOAP to 1.2 or higher, disabling external XML entity processing, and other actions.

Of course, far be it for anyone to call OutSystems older technology; those who do should have their mouths washed out with SOAP. For developers who wish to consume SOAP services, the OutSystems platform skips XML parsing altogether by inspecting the request URL, fetching the WSDL, and building direct connectors to the service. This allows developers to model requests visually.

And if you wish to expose SOAP services, the platform generates both WSDL and the necessary URL based on the visual methods (Actions) you wish to expose. XML parsing is avoided in both scenarios. However, developers who wish to read XML documents from user input or external, unverified services might want to seek additional protection from the methods recommended by OWASP.

Learn more about XML External Entities from OWASP.

5 - Broken Access Control

Status: Merged from Insecure Direct Object References and Missing Function Level Access Control

When an attacker uses one or more vectors to elevate their privilege and perform unauthorized actions, then your application suffers from broken access control (BAC). BAC is difficult to mitigate as functional tests struggle to ensure proper user restrictions. Developers cannot trust abstraction to prevent sophisticated attackers from discovering and tampering with privilege-enabling variables.

Attackers may modify cookies, hidden fields, JSON web tokens, user-identifying primary keys, and more when trying to gain entry to prohibited endpoints. OWASP suggests that developers deny access to private endpoints by default, validate privileges on trusted servers, rate limit API access to protect applications from automated attack tools, and other steps.

With OutSystems, as long as developers properly reference and assign privilege flags, you can tell security flaw number 5 to BACk-off. The platform comes with built-in, customizable permission flags assigned to every user. Developers can take advantage of this functionality to limit access to pages or screens, interface elements, server actions, and data. All management dashboards and APIs enforce user validation that naturally restricts access to those with appropriate permissions.

Learn about Broken Access Control from OWASP.

6 - Security Misconfiguration

Status: Moved (previously: #5)

This category of vulnerabilities results from developers who deploy unnecessary features or components, retain default username/password combinations, leave security features disabled, print error stack traces to end users, or fail to perform other common security practices. Attack vectors include acquiring administrative access through default credentials, discovering sensitive information or known vulnerabilities through overly-detailed error logs, and accessing stored data through improperly configured cloud services.

OWASP suggests that teams define a standardized method for deploying secure environments (production, staging, development, etc.) with unique credentials. Among other things, OWASP also recommends that teams review security configurations as part of their managerial process.

To prevent security misconfiguration, our materials provide secure installation instructions to all administrators, and we regularly evaluate, update, and secure technologies incorporated into the platform. However, developers who use insecure third-party integrations or those who run an outdated version of the OutSystems platform, are more at risk and should look into extra precautions.

Learn more about Security Misconfiguration from OWASP.

7 - Cross-Site Scripting (XSS)

Status: Moved (previously: #3)

Although not as prevalent as it was in 2013, XSS remains a top-10 threat to web applications that fail to account for it. XSS comes in three forms, but they all rely on the same principle: execute or display unescaped HTML/JavaScript data provided by the attacker.

In cases where your SPA modifies the DOM to include user-generated input or renders a page that features stored, unescaped user data, an attacker may inject a script designed to execute in the user’s browser. These scripts can steal session information, present falsified interface elements to capture PII, or gain access to privileged accounts.

Modern web frameworks (Ruby on Rails, ReactJS, others) have built-in XSS protections that mitigate some of these threats. OutSystems recommends developers use built-in platform functions to sanitize (escape, encode/decode) interface and user-submitted content before display and storage.

The OutSystems IDE also provides design-time warnings for potential XSS security risks. Finally, the platform also permits administrators to define content security policies (CSP in headers) which limits the locations from which the user’s browser may load resources.

Should you fall prey to fits of insanity and develop applications that fail to enable CSP and those that perform DOM manipulation with custom client-side JavaScript, the risk of those applications becoming vulnerable to XSS increases. But since such behavior is counterproductive to the OutSystems model-based approach to design, I cannot imagine a scenario where you would want to do that with our platform.

Learn more about Cross-Site Scripting from OWASP.

8 - Insecure Deserialization

Status: New

Applications that persist state through object serialization are vulnerable to attack for several reasons. Attackers may modify the serialized object in-flight to gain privileged access or execute injected code.

OWASP recommends developers accept serialized objects only from trusted sources and limit serialization to primitive types, when possible. However, they understand that serialization is a common practice and when unavoidable, suggest developers implement security checks, enforce type constraints, deserialize in low privilege environments, and perform other mitigating actions.

OutSystems serializes and deserializes data models as they pass from one screen to another, which appears to open the platform to vulnerability. However, the built-in JSON deserialization mechanisms compare incoming JSON data with predefined application models (Entity, Static Entity, Structure, Record, or List). The platform mandates primitive data types for all models and performs strict type verification during deserialization.

The only real risk of building an application that is vulnerable to this security flaw with OutSystems is if developers perform custom serialization/deserialization routines.

Learn more about Insecure Deserialization from OWASP.

9 - Using Components with Known Vulnerabilities

Status: Unchanged

Modern applications are comprised of dozens, if not hundreds, of dependencies that often execute with the same access privileges as the original source code. Developers expose their applications to attackers when they employ poorly-designed libraries, fail to track version numbers of the libraries they incorporate, or refuse to upgrade insecure libraries in a timely manner.

To better secure applications against vulnerable components, OWASP suggests developers remove unused dependencies, catalog and monitor both server and client-side libraries, obtain libraries exclusively from trusted sources, and patch and monitor unmaintained libraries.

OutSystems engineers update, patch, and maintain dependencies regularly. This is why it’s important to upgrade. OutSystems administrators who choose to run outdated versions of the platform or incorporate unsupported third-party integration are at greater risk of vulnerability.

Learn more about Using Components with Known Vulnerabilities from OWASP.

10 - Insufficient Logging and Monitoring

Status: New

Lastly, we come to logging. By insufficient, OWASP means an application’s failure to surface possible breach attempts. In 2016, the Ponemon Institute determined that breaches in security went undetected for an average of 191 days. That span of time grants attackers an embarrassingly large window of opportunity to compromise internal systems and steal PII.

Your application is vulnerable if you fail to log high-value events, print unclear log messages, neglect to monitor for suspicious activity, trap logging data within servers/instances, or perform other risky logging behaviors as detailed by OWASP.

OWASP recommends that developers log and store valuable interactions for a sufficient length of time (login, authentication failures, failed input validations). They must print logs that are easy to understand, take precautions to prevent tampering with logs, establish monitoring protocols, and more.

The risk of vulnerability here for OutSystems applications is very low. OutSystems applications are heavily monitored with limited impact to performance; default logging levels as described are mandatory.

By default, all OutSystems applications log errors, audits, and performance asynchronously to a logging database. Administrators can access these logs from their dashboard or use a RESTful API to generate their own reports. Logs include the following events: errors in all application layers, batch processing executions, web service invocations (inbound/outbound), page accesses, API invocations, database accesses, and more. The platform also logs and automatically protects against DoS attacks through a multi-stage blocking mechanism.

Learn more about Insufficient Logging & Monitoring from OWASP.

How OutSystems Handles the OWASP Top 10

As you have seen, OutSystems generates code based on modeled developer designs. This means we are capable of instituting standardized protections across a wide variety of attack vectors. So, why not give yourself a running start with mitigating the risks found among OWASP’s top 10 web vulnerabilities by developing an application that features built-in Enterprise-Grade security?