xMatters & the Open Web Application Security Project (OWASP) Top 10

Question

How does xMatters ensure their web applications minimize the OWASP Top 10 Web Application Security Risks?

Environment

• All versions of xMatters

Answer

At xMatters, we’re committed to developing high quality software. Our development teams use an Agile software development model and follow a Secure Software Development Life Cycle (SSDLC). This involves integrating security testing, code analysis, peer review and other controls into our existing development process.

Teams use Application Security Testing (AST) during development by scanning all libraries with WhiteSource for vulnerabilities and SonarQube for continuous inspection of code quality. In production, our applications undergo monthly tests using Veracode scans (4 Static (SAST) and 2 Dynamic (DAST)) along with annual Manual Penetration Tests (MPT). All results are analysed and actioned as per our Vulnerability Management Policy.

The development teams are mindful of the OWASP Top 10 web application security risks and work to minimise and mitigate these risks during the development phase, and to correct them if ever discovered in production. This article covers each risk within the OWASP Top 10 and explains how we minimize these risks in our applications.

The current version of the OWASP Top 10 (2017) includes the following:

1.  Injection

A code injection occurs when an attacker sends a special, maliciously-crafted input to a web application. The attacker’s intent is to make the application do something it was not designed to do, usually so they can gain access or compromise systems and cause damage.

One of the most common injection flaws found in applications is SQL injection, which can be caused when an application uses untrusted data when constructing a vulnerable SQL call.

In addition to the regular source code review mentioned previously, we use safe APIs that only use parameterized interfaces and Object–Relational Mapping (ORM) tools. No user input is directly fed to any part of our infrastructure (APIs, databases, or processing queues) without multiple passes of validation on both the frontend and backend. Many of our subsystems have additional validations on top of the APIs to further mitigate any injection scenarios.

2.  Broken Authentication

Improperly implemented authentication or session management can be exploited to compromise passwords, keywords, and sessions. A clear example would be a web application allowing weak or well-known passwords (i.e. “password1”).

To reduce this risk, we’ve implemented a number of controls:

• Our monthly static code analysis is highly useful in finding any improper code configurations.
• Since multi-factor authentication (MFA) greatly reduces the risk of a compromised account, xMatters supports clients who want to integrate their SAML authentication services.
• xMatters follows all recommended best practices to mitigate broken authentication and session management vulnerabilities.
• Instances and products do not have default credentials. In addition, we provide configuration tools and options to reduce authentication risks, such as customizable password complexity rules and forced password resets for users. We also log failed authentication attempts to mitigate brute-force attacks.
• To help mitigate session management risks, each login creates a high-entropy session identifier. Client data is encrypted within the lifecycle of the session and sessions are destroyed and invalidated after logout.

3.  Sensitive Data Exposure

Sensitive data exposure refers to confidential data that is exposed during transmission or storage. Service providers storing and processing confidential client information are at risk of this type of exposure if they do not adequately protect their data.

xMatters stores and processes client data on Google Cloud Platform (GCP). We collect only the bare minimum data to allow for business logic and encrypt all data passing through our systems via TLS1.2 or greater. No caching is present in any APIs to mitigate stale-cache attacks that would expose sensitive data. xMatters uses GCP for all storage of client data, encrypted at rest using Google’s default AES256 encryption.

4.  XML External Entities (XXE)

Attackers can take advantage of web applications that use vulnerable component processing XML by uploading XML or including hostile commands or content within an XML document. XXE occurs in a lot of unexpected places, including deeply nested dependencies, and numerous public issues have been discovered, such as attacking embedded devices.

xMatters has no features that allow XML uploads, but instead uses less complex data formats such as JSON or CSV. In addition, SAST scans help detect XXE in source code, which Veracode conducts monthly on four xMatters applications.

5.  Broken Access Control

Broken access control is when an attacker compromises and gains access to user accounts. This usually occurs when an application has insufficient change management or access controls.

xMatters enforces access control by employing a “deny-by-default” practice, except for public resources. In product, sophisticated access control mechanisms allow many levels of granular permissions so users can operate only on specific parts of the product, such as being able to supervise other users, limited independent CRUD operations, and the ability to send messages. Most assigned user roles have feature-specific permissions that govern accessibility to these resources, and OAuth tokens are invalidated when timed out or upon logout. The API is subject to rate limits and all our systems undergo regular security screening to alert for any issues.

6.  Security Misconfiguration

Security misconfigurations can happen when a configuration or programming error is introduced into the system and a weakness results. Default admin or user accounts with a preset password allow for easy exploitation.

xMatters audits and tests all of the infrastructure and software we use, and our systems undergo regular security scans including penetration testing, code scans, and security audits. In addition, we use best practices and are protected by our cloud providers.

Our development, test, and production environments all use reproducible and repeatable automated deployments and are configured identically with unique, rotating credentials.

7.  Cross-Site Scripting (XSS)

XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. Untrusted data injected into an application could allow for an attacker to bypass access controls, gain elevated access-privileges to sensitive page content, or steal a user session to gain access to the system.

xMatters prevents or mitigates cross-site request forgery (CSRF) vulnerabilities through various means.

• Any requests to our APIs go through OAuth2 authentication or a session-based backend. For session-based requests, the request is signed with a nonce in combination with the user’s session identifier, mitigating any potential CSRF attacks. For OAuth2, the bearer tokens are invalidated periodically and use the state parameter to mitigate hijacking. In addition, our APIs follow the same-origin policy and disallow CORS.
• The frameworks we use in the frontend all have mitigation for XSS by design, and we review periodically for mitigation efforts. In practice, any time a user input is shown, the input is escaped and sanitized. Every location in the platform where this is possible is protected by allow-listing specific tags and attributes. Script tags are disallowed in any rich inputs.

8.  Insecure Deserialization

Insecure deserialization is a vulnerability where deserialization flaws allow an attacker to remotely execute code in the system. An application can be vulnerable because it deserializes hostile objects that were supplied by an attacker, such as when an attacker modifies application logic or achieves arbitrary remote code execution, or when a data tampering attack changes content in an existing data structure.

In addition to our Veracode scans, xMatters’ products mitigate “Insecure Deserialization” by employing multiple techniques. Our infrastructure enforces strict type constraints on deserialized objects and employs integrity checks against tampering. Deserialization exceptions and failures are logged and cause errors in the product.

9.  Using Components with Known Vulnerabilities

Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts. This can occur when applications rely on unsupported or out-of-date software, or if developers fail to adequately test the compatibility of updated, upgraded, or patched libraries. Lack of sufficient application security testing will delay notification of these vulnerabilities, and increase the chances of an attacker exploiting them.

xMatters developers follow strict SSDLC principles in every stage of application development. All code is peer reviewed and checked before it is merged back into the branch. xMatters also understands the importance of quality third-party testing and relies on WhiteSource, Sonarqube, and Veracode AST to help identify vulnerabilities in our applications.

10.  Insufficient Logging & Monitoring

Frequent logging and monitoring is essential to ensure that a website is secure. Failure to do so can leave a site vulnerable to more severe compromising activities. Logging crucial to spotting logins, failed logins, warnings, errors, or appropriate alerting thresholds. These logs must be kept secure as well, as misconfiguration may alert end users or an attacker.

xMatters logs all database access through access control and continuous monitoring practices and ships the logs to a centralized Security Information and Event Management (SIEM) system. The xMatters service provides a detailed application audit report for reviewing changes to nearly any aspect of the system (including changes to user contact information) with the ability to narrow the results by date range and object type within the system. The report includes full details about who made the changes, how the changes were made, and when. In addition, xMatters event logging includes the content of each message sent from the system, along with targeted recipients and devices, who responded, their response, date and timestamp of each action, etc. These reports are viewable in the web user interface, and can be downloaded as a CSV file.

Conclusion

The OWASP Top Ten provides a powerful awareness document for web application security and represents a broad consensus about the most critical web application security flaws.
xMatters continuously assesses our infrastructure and applications for vulnerabilities and remediates those that could impact the security of customer data. We are committed to implementing and maintaining compliance with the OWASP Top 10 standard awareness document.

For more information on xMatters’ application development and vulnerability management, please contact security@xmatters.com for more information.