› › › › Top 10 OWASP Compliance

Products

Top 10 OWASP Compliance

May 9, 2024

Top Ten OWASP 2021 Compliance

One of Safewhere's key missions is to provide applications with a robust security foundation to protect their data and users. To achieve this, among the many security practices that we have adopted, is protection against the OWASP Top Ten security risks. As the OWASP website states:

The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications. Companies should adopt this document and start the process of ensuring that their web applications minimize these risks. Using the OWASP Top 10 is perhaps the most effective first step towards changing the software development culture within your organization into one that produces more secure code.

Since the OWASP Top 10 is seen as "the most effective first step towards changing the software development culture within your organization into one that produces more secure code," we believe that providing insights into how we continually protect our software against these top security risks can be a good first step in introducing our secure SDLC for making secure software.

A01 – Broken Access Control

We take a multi-layered approach to access control. By default, we deny all access except for public resources. We apply the principles of Least Privilege, Defense-in-Depth, and Fail-Safe to implement access control. Some examples are:

  • REST API and Admin interface: all endpoints require authentication and authorization. Login users must have sufficient roles set explicitly in their access tokens to use our REST API and the Admin interface. According to the Fail-Safe principle, access tokens that do not have the required roles are denied access by default. For the Admin interface, we authorize access both at the client-side (to improve user experience) and at the server-side (to ensure security).
  • CORS settings are enabled by default to reduce the risk of access from untrusted origins.
  • A Safewhere Identify instance only needs permission to access its own specific database schema.
  • We implemented mitigations against common access control vulnerabilities, such as elevation of privilege, access token tampering, and insecure direct object references.
  • We recommend using two-factor authentication for highly protected resources.
  • Identify Runtime is where all user authentication happens. Important user session data is encrypted and signed before being sent to the user's browser.
  • IdentifyMe, a user self-service application shipped with Safewhere Identify, stands out not only for its flexibility but also for its exceptional security. Using the advanced capabilities of Safewhere Identify, we require users to verify their identity and prove ownership of their accounts before performing any actions. Multiple authentication methods can be configured for users, giving them the flexibility to choose what works best for them.

Finally, we have implemented logging for all unauthorized access attempts by default. This way, we can proactively detect and respond to any potential security breaches.

A02 – Cryptographic Failures

At the application level, Safewhere Identify employs the Microsoft Data Protection API with strong encryption algorithms. Encryption keys are also encrypted at rest and rotated frequently. Safewhere Identify prioritizes standardization and compliance. In terms of cryptography, only algorithms and keys with lengths that satisfy all requirements of supported standards are used. The security requirements about cryptography found in the OWASP Application Security Verification Standard at https://owasp.org/www-project-application-security-verification-standard/ are strictly followed. Some examples of those requirements include:

  • Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module's approved cryptographically secure random number generator when these random values are intended to be not guessable by an attacker: We use RNGCryptoServiceProvider to generate random bytes and strings.
  • Verify that encrypted communications such as TLS is used for all inbound and outbound connections, including for management ports, monitoring, authentication, API, or web service calls, database, cloud, serverless, mainframe, external, and partner connections. The server must not fall back to insecure or unencrypted protocols: All Safewhere Identify deployments enforce HTTPS by default. Our guidelines recommend TLS 1.2 or newer.
  • Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives: Safewhere Identify supports Azure Key Vault Managed HSM, which is a secure way to protect signing certificates.
    At the database level, primary data is stored in either Azure SQL or SQL Server databases and database-level encryption, commonly known as Transparent Data Encryption (TDE), is implemented to ensure security.

A03 – Injection

Safewhere applies many techniques to prevent injection threats that helps protect your system and data:

  • Verify and sanitize all input data using methods such as parameterized queries, prepared statements, and whitelisting. This ensures that user-supplied data is validated against the data schema and any malicious code is removed.
  • Securely configure our database and limit access to only authorized users, avoiding the use of default accounts and passwords.
  • Implement user authentication and limit user permissions to the minimum necessary for them to perform their job functions. This helps to restrict access to sensitive data and functions.
  • Monitor logs for suspicious activity, and alert administrators when an attack is detected.
  • Manage user sessions, including techniques such as session timeouts, secure session IDs, and logging out users after a period of inactivity, to prevent attackers from hijacking sessions or impersonating users.
  • Regularly perform code reviews to identify and fix vulnerabilities before they can be exploited, checking for SQL injection vulnerabilities, cross-site scripting (XSS) vulnerabilities, and other common security issues.
  • Use generic error messages that do not disclose information about the system or data to avoid displaying detailed error messages to users, as they may contain sensitive information that can be used by attackers.

A04 – Insecure Design

At Safewhere, we make sure that security is included as a key feature throughout the entire development process. From the initial planning stages all the way to testing and documentation, we strictly follow our secure SDLC process to ensure the security of our product designs:

  • Before commencing development of any product, we define a list of security requirements using the OWASP Application Security Verification Standard.
  • Practice code and design reviews based on the security requirements as well as the OWASP’s secure-by-design principles.
  • All feature and technical designs have dedicated sections about security considerations. In addition, all designs are reviewed by our AppSec team.
  • Hold threat modeling sessions using the agile approach. The output of the threat modeling activities is a list of threats that we maintain in our threat management system within our project management system. Each threat has a description, risk analysis, mitigations, and user stories to implement mitigations that have not been implemented yet.
  • New functionalities of existing feature can follow established designs and patterns which reduce the risk of causing new vulnerabilities.
  • Have unit and integration tests to automatically verify that mitigations for threats work as expected.

A05 – Security Misconfiguration

Safewhere Identify has a flexible deployment model that allows you to install multiple instances of Safewhere Identify on the same server, each with its own database schema that is entirely isolated from each other. Deployments are done using Safewhere Identify's Configurator tool, which ensures that at the application level:

  • The database is set up with the correct login and permissions.
  • HTTPS is enforced. Our post-installation guideline instructs system administrators to disable all SSL and TLS protocols and leave only TLS 1.2 and newer enabled.
  • HTTP security headers such as HSTS, CSP are configured by default. Per OWASP: "Your application can use to increase the security of your application. Once set, these HTTP response headers can restrict modern browsers from running into easily preventable vulnerabilities." It is important to state that turning on all HTTP security headers is not always the solution. OWASP also states that "HTTP headers are well-known and also despised. Seeking the balance between usability and security, developers implement functionality through the headers that can make your more versatile or secure application."
  • We use https://www.ssllabs.com/ssltest/ and https://securityheaders.com/ to scan Safewhere Identify sites. The goal is to achieve an A score.

A06 – Vulnerable and Outdated Components

Safewhere integrates a continuous monitoring system to detect vulnerabilities in its 3rd party components:

  • First of all, all third-party components that are needed will be subject to closer scrutiny.
  • The component's website is monitored to stay up-to-date about possible security issues.
  • For Nuget packets, OWASP Dependency-check is used to check for known vulnerabilities.
  • For npm components, Npm audit + Retire.JS are used to scan for known vulnerabilities daily.
  • Proactive control: All checks are done as an automated step in the nocturnal build.
  • We use the OWASP's DefectDojo application for managing vulnerabilities found by the scanning tools. DefectDojo allows us to keep track of vulnerabilities and their statuses.
  • For components that have known vulnerabilities, the third-party components are reviewed to see if they are available in a newer version and the upgrade will be completed unless it causes breaking changes. In this case, the component will be subject to an additional risk/cost analysis to determine when it is the optimal time to perform the upgrade.
    Additionally, we use Nikto to scan our webservers every 6 months for outdated server software, dangerous files/CGIs, and other potential issues.

A07 – Identification and Authentication Failures

As an IAM product, authentication and authorization are at the heart of Safewhere Identify. We have implemented and continue to add more mitigations to ensure the security of authentication and authorization. Some examples of mitigations against common threats include:

  • Identify supports various standards and profiles such as SAML 2.0, OIOSAML2, OIOSAML3, WS-Federation, WSTrust, OIOWSTrust, OIO IDWS, OAuth 2.0, and OIDC. Multiple login methods are available, including username and password, NemID, MitID, NemLog-in2, NemLog-in3, LDAP, WebAuthn, and other SAML 2.0, WS-Federation, and OAuth 2.0/OIDC providers. Every standard or profile has sections about security concerns and mitigations that Safewhere Identify implements.
  • Safewhere Identify provides a wide range of MFA methods, such as OTP via email and SMS, T-OTP, WebAuthn, cookie-based, and proprietary solutions like OS2faktor.
  • Safewhere Identify does not ship with default credentials. Administrators must enter a strong password to create a new Safewhere Identify instance.
  • Password policies are configurable to meet the requirements of any organization and standard.
  • A built-in account lockout feature limits failed login attempts.
  • Logs of login failure attempts can be used to detect credential stuffing, brute force, or other attacks.
  • Safewhere Identify allows combining login methods and customizing processing rules, such as using any first-factor login method as a second-factor method, triggering a second factor only for admins logging in from an external IP, or requiring WebAuthn as the second factor for highly protected resources. Additionally, Safewhere Identify enables custom scripts for allowing or blocking user login and performing step-up authentication to national eID accounts for highly protected resources accessed via personal accounts.

A08 – Software and Data Integrity Failures

Software and data integrity failures occur when code and infrastructure fail to protect against integrity violations. At Safewhere, we apply several mitigations to our development process, such as:

  • Requiring code changes to be reviewed using pull requests (PRs).
  • Reviewing all changes to continuous integration/continuous deployment (CI/CD).
  • Using tools like Npm audit, Retire.js, and OWASP Dependency-check to proactively find potential vulnerabilities, as mentioned in section A6.
  • Carefully examining any code we use from external sources.
  • Implementing a review process for code and configuration changes to minimize the chance of introducing malicious code or configuration into our software pipeline.
  • Enforce the URL schema, port, and destination with a positive allow list. Do not mitigate SSRF via the use of a deny list or regular expression. Attackers have payload lists, tools, and skills to bypass deny lists.
  • Using digital signatures or similar mechanisms to verify that software or data is from the expected source and hasn't been altered.
  • Signing Safewhere Identify's installation and assemblies to ensure their integrity.

A09 – Security Logging and Monitoring Failures

Logging is the area Safewhere really puts its heart and soul into. Safewhere Identify's logging feature is a powerful tool that helps system administrators monitor and track important events and activities, such as user logins, configuration changes, and errors. These logs can be searched, filtered, and exported to help troubleshoot issues and maintain system security.
With Safewhere Identify, administrators can customize logging to suit their needs. They can choose which types of data to log and where to log it, such as a text file, Windows event log, or custom database. They can also adjust log levels and specify which event IDs should be logged.
Using Safewhere Identify's logging feature, administrators can gain valuable insights into system activity and take proactive steps to ensure system security and stability. Plus, the built-in log viewer makes it easy to explore the logs of your Safewhere Identify instance.

A10 – Server-Side Request Forgery (SSRF)

Safewhere follows a zero-trust principle and verifies all user and external data. APIs in Safewhere don't fetch remote resources based on end-user supplied URLs. However, we follow some extra best practices to reduce risks even more, such as:

  • Sanitizing and validating all client-supplied input data.
  • All URLs that Safewhere Identify need to fetch data from are configured by system administrators only.
  • Protecting XML processing code against all common XML attacks. This is especially important because SAML 2.0 and WS-Federation standards are all about processing XML messages.
  • All traffic to Safewhere Identify is through HTTPS (port 443), and all other ports must not be open. This can greatly block all inessential intranet traffic.