Skip to content

Latest commit

 

History

History
43 lines (36 loc) · 5.05 KB

attack-surface.md

File metadata and controls

43 lines (36 loc) · 5.05 KB

Attack Surface Analysis for getredash/redash

Attack Surface: Data Source Credential Compromise (Redash Storage)

  • Description: Exposure of credentials used by Redash to connect to data sources, specifically due to vulnerabilities within Redash's storage and handling of these credentials.
  • How Redash Contributes: Redash stores these credentials, making it the primary target for attackers seeking access to connected data sources. This is a core function of Redash.
  • Example: An attacker exploits a vulnerability in Redash to gain access to the server and retrieves the encrypted database credentials. If the encryption is weak or the key is compromised, the attacker gains access to the data sources.
  • Impact: Complete compromise of connected data sources. Data theft, modification, or deletion. Potential for lateral movement.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Secure Redash Deployment: Follow all Redash security best practices (secure server, HTTPS, strong Redash user passwords, MFA, regular updates). This is the foundation of security.
    • Environment Variables: Store credentials in environment variables, not directly in Redash's configuration files or database.
    • Encryption Key Management: Ensure Redash's encryption keys (for at-rest credential encryption) are securely managed, protected, and rotated regularly. This is a developer responsibility.
    • Principle of Least Privilege (Redash Users): Restrict access to data source configurations within Redash to only authorized users.
    • Audit Redash Access: Regularly audit Redash access logs to detect any unauthorized attempts to access data source configurations.

Attack Surface: Data Source Exploitation via SQLi/NoSQLi (Redash-Mediated)

  • Description: Exploitation of vulnerabilities within connected data sources, but specifically facilitated by Redash's lack of proper input sanitization. This focuses on Redash's role as the intermediary.
  • How Redash Contributes: Redash acts as the intermediary. If Redash doesn't properly sanitize user input for the specific data source type, it enables the injection attack. This is a direct Redash responsibility.
  • Example: A user crafts a malicious SQL query within Redash. Redash fails to properly escape the input for the target PostgreSQL database, allowing the attacker to execute arbitrary SQL commands.
  • Impact: Compromise of the connected data source. Data theft, modification, or deletion. Potential for command execution.
  • Risk Severity: High
  • Mitigation Strategies:
    • Redash Input Validation (Per Data Source Type): Redash developers must implement robust input validation and sanitization specific to each supported data source type. This is critical and ongoing work. This is the primary defense from Redash's perspective.
    • Parameterized Queries (Redash-Side): Redash must use parameterized queries (prepared statements) whenever possible, for all data source types. This is a developer responsibility.
    • Web Application Firewall (WAF): A WAF can provide an additional layer of defense, but it should not be relied upon as the primary mitigation. It can help detect and block known attack patterns.

Attack Surface: Redash Application Vulnerabilities (Authentication/Authorization)

  • Description: Vulnerabilities within the Redash application code itself, specifically related to authentication and authorization, allowing attackers to bypass security controls.
  • How Redash Contributes: This is entirely a Redash issue. The vulnerability exists within Redash's code.
  • Example: An attacker exploits a broken access control vulnerability in Redash to gain access to dashboards and queries they should not be able to see, bypassing authentication or permission checks.
  • Impact: Unauthorized access to Redash and potentially connected data sources (depending on the vulnerability). Data theft, modification, or deletion.
  • Risk Severity: High
  • Mitigation Strategies:
    • Regular Updates: Keep Redash up-to-date with the latest security patches. This is absolutely critical.
    • Multi-Factor Authentication (MFA): Enable MFA for all Redash users, especially administrators.
    • Secure Session Management: Redash developers must follow secure session management best practices (random IDs, HTTPS-only cookies, proper expiration). This is a developer responsibility.
    • Penetration Testing: Conduct regular penetration testing of the Redash application to identify and address vulnerabilities.
    • Security Audits: Perform regular security audits of Redash's codebase, focusing on authentication and authorization logic.
    • Strong Password Policies: Enforce strong password policies.