Skip to content

Latest commit

 

History

History
165 lines (130 loc) · 11.8 KB

mitigations.md

File metadata and controls

165 lines (130 loc) · 11.8 KB

Mitigation Strategies Analysis for go-sql-driver/mysql

Mitigation Strategy: Least Privilege Principle (Database User Permissions)

  • 1. Least Privilege Principle (Database User Permissions)

    • Description:

      1. Within the MySQL server (using the MySQL command line, a GUI tool like MySQL Workbench, or a script), identify all distinct functionalities of the application that require database access.
      2. For each functionality, determine the minimum set of database privileges required. Use SHOW GRANTS FOR 'user'@'host'; to inspect existing privileges.
      3. Create separate MySQL users for each distinct functionality (or group functionalities with identical needs). Use CREATE USER 'user'@'host' IDENTIFIED BY 'password';.
      4. Grant only the necessary privileges to each user. Use the GRANT statement with specific table and column restrictions. For example:
        • GRANT SELECT ON database.table TO 'user'@'host'; (Read-only access to a specific table)
        • GRANT INSERT, UPDATE ON database.table TO 'user'@'host'; (Insert and update access)
        • GRANT SELECT (column1, column2) ON database.table TO 'user'@'host'; (Read-only access to specific columns)
        • GRANT EXECUTE ON PROCEDURE database.procedure_name TO 'user'@'host'; (Execute a stored procedure)
        • Crucially, avoid: GRANT ALL PRIVILEGES ..., GRANT ... WITH GRANT OPTION, and privileges on the mysql database itself (unless absolutely necessary for administrative users, not application users).
      5. Use FLUSH PRIVILEGES; after making changes to user privileges to ensure they take effect.
      6. Regularly review and audit the database user privileges using SHOW GRANTS and revoke any unnecessary privileges using REVOKE.

    • Threats Mitigated:

      • Unauthorized Data Access: (Severity: High) - Limits what an attacker can see even with a compromised application component.
      • Unauthorized Data Modification/Deletion: (Severity: High) - Limits what an attacker can change or delete.
      • Privilege Escalation: (Severity: Medium) - Reduces the chance of an attacker gaining higher privileges within the database.

    • Impact:

      • Unauthorized Access/Modification/Deletion: Risk significantly reduced. The impact of a compromise is confined to the specific functionality of the compromised user.
      • Privilege Escalation: Risk reduced, as fewer avenues for escalation exist.

    • Currently Implemented:

      • A separate read-only user exists for reporting.

    • Missing Implementation:

      • The main application uses a single user with broad privileges. High Priority to Fix. Create separate users for different modules.

Mitigation Strategy: Connection Security (TLS/SSL) - Server-Side Configuration

  • 2. Connection Security (TLS/SSL) - Server-Side Configuration

    • Description:

      1. Obtain a TLS/SSL certificate. Options include:
        • Self-signed: For testing only. Not secure for production.
        • Trusted CA: From a commercial Certificate Authority (e.g., Let's Encrypt). Recommended for production.
        • Internal CA: If your organization has its own Certificate Authority.
      2. Configure the MySQL server to require TLS/SSL. Edit the MySQL configuration file (my.cnf or my.ini, typically in /etc/mysql/ or /etc/my.cnf.d/). Add or modify the following settings within the [mysqld] section: 
        ssl-ca=/path/to/ca.pem  # Path to the CA certificate (if using a CA)
ssl-cert=/path/to/server-cert.pem  # Path to the server's certificate
ssl-key=/path/to/server-key.pem  # Path to the server's private key
require_secure_transport=ON # Forces all connections to use TLS
      3. Restart the MySQL server for the changes to take effect.
      4. Verify the configuration:
        • From a client machine, try connecting without TLS. It should fail.
        • Connect with TLS and verify the certificate using a tool like openssl s_client -connect dbhost:3306 -starttls mysql.

    • Threats Mitigated:

      • Man-in-the-Middle (MITM) Attacks: (Severity: High) - Prevents interception and modification of communication.
      • Eavesdropping: (Severity: High) - Prevents attackers from listening to database traffic.

    • Impact:

      • MITM Attacks: Risk reduced to Negligible (when combined with client-side certificate verification).
      • Eavesdropping: Risk reduced to Negligible.

    • Currently Implemented:

      • TLS is enabled on the server, but require_secure_transport is likely OFF (needs verification).

    • Missing Implementation:

      • Verify require_secure_transport=ON is set. Medium Priority.

Mitigation Strategy: Auditing (MySQL Server Configuration)

  • 3. Auditing (MySQL Server Configuration)

    • Description:

      1. Choose an auditing method:
        • General Query Log: Logs every SQL statement. High performance impact. Useful for short-term debugging or targeted investigations. Not recommended for continuous use in production.
        • Slow Query Log: Logs queries that exceed a defined execution time (long_query_time). Lower performance impact. Good for identifying performance bottlenecks and potentially suspicious queries.
        • MySQL Enterprise Audit: (Requires a commercial MySQL license) Provides advanced auditing features, including filtering, user activity monitoring, and compliance reporting. Best option for comprehensive auditing.
        • MariaDB Audit Plugin: (If using MariaDB, a fork of MySQL) A free and open-source alternative to MySQL Enterprise Audit.
      2. Configure the chosen method:
        • General Query Log: 
          [mysqld]
general_log=ON
general_log_file=/path/to/general.log
log_output=FILE  # Or TABLE (for logging to the mysql.general_log table)
        • Slow Query Log: 
          [mysqld]
slow_query_log=ON
slow_query_log_file=/path/to/slow.log
long_query_time=1  # Log queries taking longer than 1 second (adjust as needed)
log_output=FILE  # Or TABLE
log_slow_admin_statements=ON # Log slow administrative statements
log_queries_not_using_indexes=ON # Log queries that don't use indexes
        • MySQL Enterprise Audit / MariaDB Audit Plugin: Refer to the respective documentation for configuration details. These plugins offer extensive configuration options.
      3. Configure log rotation: Use a tool like logrotate (on Linux) to prevent log files from growing indefinitely.
      4. Secure the log files: Ensure that the log files are protected from unauthorized access and modification. Set appropriate file permissions.
      5. Regularly review the logs: Establish a process for reviewing the audit logs for suspicious activity.

    • Threats Mitigated:

      • Intrusion Detection: (Severity: Medium) - Helps detect malicious activity.
      • Forensic Analysis: (Severity: Medium) - Provides a record for investigations.
      • Compliance: (Severity: Low) - May be required for compliance.

    • Impact:

      • Intrusion Detection/Forensic Analysis: Provides valuable information.
      • Compliance: Helps meet requirements.

    • Currently Implemented:

      • No database auditing is enabled.

    • Missing Implementation:

      • Enable the slow query log (at a minimum) and configure log rotation. Consider a more comprehensive auditing solution if required. Medium Priority.

Mitigation Strategy: Disable multiStatements (Server-Side - If Possible)

  • 4. Disable multiStatements (Server-Side - If Possible)

    • Description:

      • While primarily controlled by the client (via the DSN), some MySQL server configurations might have settings that globally disable or restrict multi-statement execution. This is less common and less reliable than controlling it on the client-side, but it's worth checking.
      • There isn't a single, universally reliable server-side setting to completely disable multiStatements for all clients. The client's DSN setting usually takes precedence.
      • However, you can investigate:
        • Stored Procedures/Functions: If you are using stored procedures or functions, ensure they are not designed in a way that could be vulnerable to SQL injection if multiStatements were enabled on the client. Review their code carefully.
        • User Permissions (Again): While not a direct disable, ensure that application users do not have privileges that would allow them to create or modify stored procedures or functions. This limits the potential impact if an attacker did manage to use multiStatements.

    • Threats Mitigated:

      • SQL Injection (with multiStatements): (Severity: Critical) - Reduces the potential impact of SQL injection if the client enables multiStatements.

    • Impact:

      • SQL Injection (with multiStatements): Provides a small, additional layer of defense, but primarily relies on the client-side DSN setting.

    • Currently Implemented:

      • Unknown. Needs investigation of stored procedures/functions (if any).

    • Missing Implementation:

      • Review stored procedures/functions for potential vulnerabilities related to multiStatements. Low Priority (since the client-side setting is the primary control).

Mitigation Strategy: Network Segmentation (MySQL Server Placement)

  • 5. Network Segmentation (MySQL Server Placement)

    • Description:

      1. Physically or logically separate the MySQL server from the application server and any public-facing networks.
      2. Use a firewall (hardware or software) to strictly control access to the MySQL server.
      3. Allow only:
        • Connections from the application server's IP address(es) on the MySQL port (default: 3306).
        • Connections from authorized administrative hosts (if necessary) on a different port (e.g., a dedicated management port), and ideally using SSH tunneling or a VPN.
      4. Block all other incoming connections.
      5. Regularly review and audit the firewall rules.

    • Threats Mitigated:

      • Unauthorized Access to Database Server: (Severity: High) - Prevents direct access from the internet or other compromised systems.
      • Lateral Movement: (Severity: High) - Limits an attacker's ability to move from a compromised application server to the database.

    • Impact:

      • Unauthorized Access/Lateral Movement: Risk significantly reduced.

    • Currently Implemented:

      • The application and database servers are on the same subnet.

    • Missing Implementation:

      • Move the database server to a separate, isolated network segment and configure firewall rules. High Priority.