Cheat Sheet: Addressing OWASP Top 10 Vulnerabilities in MuleSoft APIs

Generally, when we talk about ensuring security in an IT context, it is about ensuring three essential goals - Confidentiality, Integrity, and Availability.

Quick Word on OWASP

The OWASP Foundation typically publishes a list of the top 10 security threats on an annual basis (2017 being an exception where RC1 was rejected and revised based on inputs from market experts). The goal is to make IT professionals aware of the most prominent threats out there - based on the technology choices prevalent in the industry and the kind of security attacks being encountered - and rank them based on various factors such as Exploitability, Prevalence, and Detectability.

According to OWASP, they are an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted.

Image title

OWASP Top 10 2017 - RC2

Note that the following mitigation set assumes MuleSoft runtime v3.8 and relies on a CloudHub-based API Manager as a means to apply security policies.

#

Security Threat

Description

Mitigation

A1

Injection

Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.

  1. Generally configured as an ESAPI-based Validator to be configured along with a whitelist of approved characters.
  2. In MuleSoft, it can be enforced as a security policy on the MuleSoft API Manager:

a) JSON Threat Protection 

b) XML Threat Protection

A2

Broken Authentication and Session Management

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or to exploit other implementation flaws to assume other users’ identities.

  1. APIs are stateless in general.
  2. Authentication is available out of the box using OAUTH2 access token management using an external provider (LDAP service).
  3. In case the use case demands it, a web session could be implemented and can be validated functionally against a qualified referrer and User Identification.
  4. Security analytics could be implemented that capture the client's security footprint.
A3

Sensitive Data Exposure

Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.

  1. Enforce SSL for data in flight.
  2. For data being persisted, Encryption (AES-256 recommended) to be enforced for sensitive data like PII or PCI.
A4

XML External Entity (XXE)

Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal SMB file shares on unpatched Windows servers, internal port scanning, remote code execution, and denial of service attacks, such as the Billion Laughs attack.

  1. In MuleSoft, it can be enforced as a security policy on the MuleSoft API Manager for XML Threat Protection.
  2. Explicit setting of XML parsing features as advised here.

A5

Broken Access Control

Virtually all web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access unauthorized functionality.

  1. API Manager-based authentication and coarse-grained authorization via LDAP (using expiring authentication tokens).
  2. If use cases needs or allows, IP whitelisting can be configured as a policy on MuleSoft API Manager.

A6

Security Misconfiguration

Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application.

  1. Environment configuration and keys to be encrypted on disk (configuration accessible only to Mule Runtime users).
  2. App Scan code review. 

A7

Cross Site Scripting (XSS)

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

  1. ESAPI based Validator to be configured along with a whitelist of approved characters. Enforced as a Security policy on MuleSoft API Manager - including JSON Threat protection, XML threat protection and CORS policy (if need be).

A8

Insecure Deserialization

Insecure deserialization flaws occur when an application receives hostile serialized objects. Insecure deserialization leads to remote code execution. Even if deserialization flaws do not result in remote code execution, serialized objects can be replayed, tampered or deleted to spoof users, conduct injection attacks, and elevate privileges.

  1. MuleSoft is largely Spring-based and Spring has hardened its susceptible classes.
  2. SSL enabling.
  3.  IP blacklisting if need be - configured as an API Manager policy.

A9

Using Components with Known Vulnerabilities

Vulnerable components, such as libraries, frameworks, and other software modules almost always run with full privilege. So, if exploited, they can cause serious data loss or server takeover. Applications using these vulnerable components may undermine their defenses and enable a range of possible attacks and impacts.

  1. Only approved enterprise libraries to be referred.
  2. Static code analysis via static code analysis tools like App scan.

A10

Insufficient Logging and Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

  1. Enable HTTP logging while masking sensitive data.
  2. MuleSoft AppInsights can help.
  3. Best to have rules defined on a monitoring system like DynaTrace or Appdynamics that sends out proactive alerts.
  4. Identify and log potential security events.
  5. Analysis of aggregated logs via implementations like Splunk. etc. to have a knitted view across the players in the landscape including WAF, Application, DB, MQ middleware, etc.

 

 

 

 

Top