Skip to content

Latest commit

 

History

History
96 lines (85 loc) · 9.46 KB

threat-modeling.md

File metadata and controls

96 lines (85 loc) · 9.46 KB

Threat Model Analysis for cube-js/cube

Threat: Schema Poisoning via Unvetted External Schema Sources

  • Description: An attacker provides a malicious Cube.js schema definition from an untrusted external source (e.g., a URL, a third-party repository, or a compromised internal source). The attacker could inject malicious JavaScript code into the schema, alter data definitions to expose sensitive information, or modify access control rules. This could be achieved through social engineering, exploiting a vulnerability in a schema loading mechanism, or compromising a trusted source.
  • Impact:
    • Data breaches: Exposure of sensitive data.
    • Data corruption: Modification or deletion of data.
    • Code execution: Execution of arbitrary code on the Cube.js server.
    • Denial of service: Disruption of the Cube.js service.
    • Complete system compromise.
  • Affected Component:
    • cube.js configuration file (specifically, how schemas are loaded).
    • Schema loading logic within the @cubejs-backend/server-core module (or relevant core module handling schema loading).
    • Any custom schema loaders implemented by the user.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Strictly control schema sources: Load schemas only from trusted, local sources (e.g., version-controlled files within the project). Avoid loading schemas from external URLs or untrusted repositories.
    • Implement schema validation: Use a schema validator (e.g., a JSON Schema validator or a custom validator) to ensure that the schema conforms to a predefined structure and does not contain any malicious code.
    • Code review: Thoroughly review all schema files for potential security issues.
    • Sandboxing (if dynamic schema loading is unavoidable): If dynamic schema loading is absolutely necessary, consider using a sandboxed environment (e.g., a separate process or a virtual machine) to isolate the schema loading process and prevent it from affecting the main Cube.js server. This is a complex mitigation and should be carefully evaluated.
    • Content Security Policy (CSP): If schemas are loaded dynamically, use CSP to restrict the sources from which scripts can be loaded.

Threat: Data Source Credential Leakage via Configuration Exposure

  • Description: An attacker gains access to the Cube.js configuration file (cube.js or environment variables) and extracts the database credentials. This could happen through a server compromise, a misconfigured web server exposing the configuration file, or accidental disclosure (e.g., committing credentials to a public repository).
  • Impact:
    • Direct database access: The attacker can bypass Cube.js and directly access the database, potentially reading, modifying, or deleting data.
    • Data breach: Exposure of all data stored in the database.
  • Affected Component:
    • cube.js configuration file.
    • Environment variables used to store database credentials.
    • Any custom configuration loading mechanisms.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Secrets Management: Use a dedicated secrets management service (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager) to store and manage database credentials. Never store credentials directly in the cube.js file or in unencrypted environment variables.
    • Least Privilege: Ensure the database user used by Cube.js has only the minimum necessary permissions.
    • File Permissions: Secure the cube.js file with appropriate file system permissions (e.g., read-only for the user running the Cube.js process, and no access for other users).
    • Regular Credential Rotation: Implement a policy for regularly rotating database credentials.
    • Environment Variable Security: If using environment variables, ensure they are set securely and are not exposed to unauthorized users or processes.

Threat: Query Parameter Manipulation Leading to Unauthorized Data Access

  • Description: An attacker manipulates the parameters passed to the Cube.js API (e.g., filters, dimensions, measures) to bypass intended access controls and retrieve data they should not have access to. This exploits weaknesses in how the application uses Cube.js's query building capabilities, rather than a direct SQL injection. The attacker might try to guess or enumerate valid parameter values, or exploit logical flaws in the application's use of Cube.js.
  • Impact:
    • Data breach: Exposure of sensitive data.
    • Information disclosure: Leakage of information about the data structure or other users.
  • Affected Component:
    • Cube.js API endpoints (e.g., /cubejs-api/v1/load).
    • The application's frontend code that interacts with the Cube.js API.
    • The application's backend code that processes Cube.js API requests (if any).
    • query object processing within the @cubejs-backend/query-orchestrator (or relevant module).
  • Risk Severity: High
  • Mitigation Strategies:
    • Strict Input Validation: Implement rigorous input validation on the application side for all parameters passed to the Cube.js API. Validate data types, formats, and allowed values. Do not rely solely on Cube.js's internal validation.
    • Whitelist Allowed Parameters: Define a whitelist of allowed parameters and reject any requests that contain unexpected parameters.
    • Row-Level Security (RLS): Use Cube.js's RLS features (e.g., securityContext, queryTransformer) to enforce fine-grained access control based on user attributes.
    • Data Masking: Use Cube.js's data masking features to redact sensitive data from query results based on user roles.
    • Parameterized Queries (Database Level): Even though Cube.js handles query generation, ensure the underlying database driver uses parameterized queries to prevent any potential SQL injection vulnerabilities that might arise from unexpected Cube.js behavior.

Threat: Denial of Service via Resource-Intensive Queries

  • Description: An attacker sends crafted queries to the Cube.js API that consume excessive server resources (CPU, memory, database connections) or database resources, leading to a denial of service. This could involve queries with a large number of dimensions, complex filters, or operations on large datasets.
  • Impact:
    • Service unavailability: The Cube.js API becomes unresponsive, preventing legitimate users from accessing data.
    • Database overload: The underlying database becomes overloaded and may crash.
  • Affected Component:
    • Cube.js API endpoints.
    • @cubejs-backend/query-orchestrator (or relevant module handling query execution).
    • Database connection pool.
    • The underlying database server.
  • Risk Severity: High
  • Mitigation Strategies:
    • Query Timeouts: Set reasonable timeouts for Cube.js API requests and database queries.
    • Query Limits: Limit the number of dimensions, measures, and filters that can be used in a single query. Use Cube.js's queryLimits configuration.
    • Rate Limiting: Implement rate limiting on the Cube.js API to prevent an attacker from flooding the server with requests.
    • Pre-Aggregations: Use Cube.js's pre-aggregation feature to pre-compute frequently used queries and reduce the load on the database. This is a key mitigation for DoS.
    • Resource Monitoring: Monitor server and database resource usage and set up alerts for unusual activity.
    • Database Optimization: Optimize the database schema and indexes for performance.
    • Caching: Use Cube.js's caching mechanisms (e.g., Redis) to reduce the number of queries that need to be executed against the database.

Threat: Dependency Vulnerability Exploitation

  • Description: An attacker exploits a known vulnerability in a Cube.js dependency (e.g., a Node.js library, a database driver) to gain unauthorized access to the server, execute arbitrary code, or cause a denial of service.
  • Impact:
    • Varies widely depending on the specific vulnerability, but could range from information disclosure to complete system compromise.
  • Affected Component:
    • Any Cube.js module or dependency that contains a vulnerability.
  • Risk Severity: Varies (Critical to High, depending on the vulnerability)
  • Mitigation Strategies:
    • Dependency Management: Use a dependency management tool (e.g., npm, yarn) to keep track of dependencies and their versions.
    • Vulnerability Scanning: Regularly scan dependencies for known vulnerabilities using a tool like npm audit, yarn audit, Snyk, or Dependabot.
    • Update Dependencies: Promptly update dependencies to the latest versions, especially when security patches are released.
    • Dependency Pinning: Consider pinning dependency versions to prevent unexpected updates that could introduce new vulnerabilities or break compatibility. However, balance this with the need to apply security updates.
    • Monitor Security Advisories: Subscribe to security advisories for Cube.js and its dependencies.