Skip to content

Latest commit

 

History

History
250 lines (183 loc) · 16.9 KB

mitigations.md

File metadata and controls

250 lines (183 loc) · 16.9 KB

Mitigation Strategies Analysis for bcit-ci/codeigniter

Mitigation Strategy: Enable CSRF Protection

Mitigation Strategy: Enable CSRF Protection

  • Description:

    1. Open the config/config.php file located in your application's application/config/ directory.
    2. Locate the configuration setting $config['csrf_protection'].
    3. Change the value from FALSE to TRUE: $config['csrf_protection'] = TRUE;.
    4. Optionally, customize CSRF settings like $config['csrf_token_name'], $config['csrf_cookie_name'], and $config['csrf_expire'] in config/config.php to adjust token names, cookie names, and expiration times.
    5. Ensure you are using CodeIgniter's form helper (form_open()) to generate forms, which automatically includes CSRF tokens. For AJAX requests, you will need to manually include the CSRF token in your request headers or data.

  • Threats Mitigated:

    • Cross-Site Request Forgery (CSRF) - Severity: High - Attackers can force authenticated users to perform actions without their knowledge or consent.

  • Impact:

    • CSRF - Impact: High - Significantly reduces the risk of CSRF attacks by validating the presence and correctness of a CSRF token in requests.

  • Currently Implemented:

    • Yes, CSRF protection is enabled in config/config.php.

  • Missing Implementation:

    • N/A - CSRF protection is globally enabled. Verify that all forms are generated using CodeIgniter's form helper or that CSRF tokens are correctly implemented in AJAX requests.

Mitigation Strategy: Configure Secure Session Management (Database Driver)

Mitigation Strategy: Configure Secure Session Management (Database Driver)

  • Description:

    1. Open the config/config.php file in your application's application/config/ directory.
    2. Locate the configuration setting $config['sess_driver'].
    3. Change the value from the default 'files' to 'database': $config['sess_driver'] = 'database';.
    4. Ensure your database configuration in config/database.php is correctly configured and the database user has the necessary permissions.
    5. Create the required session table in your database as defined in CodeIgniter's documentation, typically using a migration.
    6. Further enhance session security by setting $config['sess_cookie_secure'] = TRUE; and $config['sess_cookie_httponly'] = TRUE; in config/config.php to restrict cookie transmission to HTTPS and prevent JavaScript access. Configure $config['sess_expiration'] and $config['sess_time_to_update'] to manage session lifetime and regeneration frequency.

  • Threats Mitigated:

    • Session Hijacking - Severity: High - Attackers can steal session IDs to impersonate users.
    • Session Fixation - Severity: Medium - Attackers can force users to use a known session ID.
    • Information Disclosure (Session Data) - Severity: Medium - Risk of session data exposure if stored insecurely.

  • Impact:

    • Session Hijacking - Impact: High - Database session storage is more secure than file-based storage, especially in shared hosting.
    • Session Fixation - Impact: Medium - Database driver, combined with secure cookie settings and session regeneration, strengthens protection against fixation.
    • Information Disclosure (Session Data) - Impact: Medium - Database storage, when properly secured, reduces the risk of unauthorized access to session data compared to default file storage.

  • Currently Implemented:

    • No, the application is currently using the default 'files' session driver.

  • Missing Implementation:

    • Session driver needs to be changed to 'database' in config/config.php.
    • Database session table needs to be created.
    • Database configuration in config/database.php should be reviewed for security.

Mitigation Strategy: Implement Context-Aware Output Encoding using esc()

Mitigation Strategy: Implement Context-Aware Output Encoding using esc()

  • Description:

    1. In your CodeIgniter views (.php files in application/views/), identify all instances where dynamic data (user input, database data) is displayed.
    2. Wrap each variable being outputted with CodeIgniter's esc() function.
    3. Specify the appropriate context for encoding as the second parameter of esc(). Use 'html' for general HTML output, 'js' for JavaScript, 'url' for URLs, 'css' for CSS, and 'attr' for HTML attributes. Example: <?php echo esc($variable, 'html'); ?>.
    4. Train developers to consistently use esc() for all dynamic output in views to prevent XSS vulnerabilities.

  • Threats Mitigated:

    • Cross-Site Scripting (XSS) - Severity: High - Attackers can inject malicious scripts into web pages viewed by other users.

  • Impact:

    • XSS - Impact: High - esc() function effectively prevents XSS by encoding output based on the context, neutralizing malicious scripts.

  • Currently Implemented:

    • Partially implemented. esc() is used in some newer views, but older views may lack proper output encoding.

  • Missing Implementation:

    • Systematically audit all views to ensure esc() is used for all dynamic output.
    • Establish coding standards and developer training to mandate the use of esc() in all new code.

Mitigation Strategy: Utilize Parameterized Queries or Query Builder for Database Interactions

Mitigation Strategy: Utilize Parameterized Queries or Query Builder for Database Interactions

  • Description:

    1. When interacting with databases in CodeIgniter models and controllers, always use CodeIgniter's Query Builder or parameterized queries.
    2. Avoid constructing raw SQL queries using string concatenation, which is vulnerable to SQL injection.
    3. Use Query Builder methods like $this->db->where(), $this->db->insert(), $this->db->update(), $this->db->get(), etc., to build database queries securely.
    4. If raw queries are absolutely necessary, use query bindings (placeholders) with $this->db->query() to pass user inputs as parameters. Example: $this->db->query("SELECT * FROM users WHERE username = ?", array($username));.

  • Threats Mitigated:

    • SQL Injection - Severity: Critical - Attackers can manipulate database queries to gain unauthorized access, modify data, or compromise the database.

  • Impact:

    • SQL Injection - Impact: High - Using Query Builder or parameterized queries effectively prevents SQL injection by separating SQL code from user-provided data.

  • Currently Implemented:

    • Mostly implemented. Query Builder is generally used, but legacy code or specific areas might still use vulnerable raw queries.

  • Missing Implementation:

    • Conduct a thorough code review of models and controllers to identify and refactor any instances of raw SQL queries built with string concatenation.
    • Reinforce secure database query practices in developer training and code review processes.

Mitigation Strategy: Validate File Types and Extensions using Upload Library

Mitigation Strategy: Validate File Types and Extensions using Upload Library

  • Description:

    1. When implementing file upload functionality using CodeIgniter's Upload Library, configure the $config['allowed_types'] setting.
    2. Whitelist only the permitted file types and extensions in $config['allowed_types']. For example: $config['allowed_types'] = 'gif|jpg|png|jpeg|pdf';. Avoid blacklisting file types.
    3. Set this configuration before initializing the Upload Library in your controller.
    4. Ensure file type validation is performed server-side by the Upload Library before moving the uploaded file. Do not rely solely on client-side validation.

  • Threats Mitigated:

    • Remote Code Execution (File Upload) - Severity: High - Attackers could upload malicious executable files if file type validation is insufficient.
    • Cross-Site Scripting (File Upload) - Severity: Medium - Risk of uploading files containing embedded scripts (e.g., SVG with JavaScript).

  • Impact:

    • Remote Code Execution (File Upload) - Impact: High - Whitelisting file types significantly reduces the risk of uploading and executing malicious files.
    • Cross-Site Scripting (File Upload) - Impact: Medium - Reduces the risk of XSS through uploaded files, especially when combined with secure handling and serving of uploaded content.

  • Currently Implemented:

    • Partially implemented. File upload functionality exists, but allowed_types might not be strictly whitelisted in all upload handlers.

  • Missing Implementation:

    • Review all file upload implementations in controllers.
    • Ensure $config['allowed_types'] is configured with a strict whitelist of allowed extensions for each file upload feature.
    • Replace any blacklisting approaches with whitelisting.

Mitigation Strategy: Implement Secure Routing

Mitigation Strategy: Implement Secure Routing

  • Description:

    1. Carefully define routes in application/config/routes.php to control access to controllers and actions.
    2. Use specific routes instead of relying heavily on default routing, which can sometimes expose unintended functionality.
    3. Protect administrative or sensitive functionalities by placing them under specific routes and implementing authentication and authorization checks within the corresponding controllers.
    4. Avoid overly broad or wildcard routes that might inadvertently expose actions or controllers.

  • Threats Mitigated:

    • Unauthorized Access - Severity: Medium to High - Improperly configured routes can lead to unauthorized access to application features and data.
    • Information Disclosure - Severity: Medium - Exposure of unintended functionalities or information due to misconfigured routing.

  • Impact:

    • Unauthorized Access - Impact: Medium - Well-defined routes and access control in controllers limit unauthorized access.
    • Information Disclosure - Impact: Medium - Secure routing reduces the risk of exposing unintended information or functionalities.

  • Currently Implemented:

    • Generally implemented. Routes are defined in routes.php, but a review for overly permissive routes and proper protection of sensitive areas is recommended.

  • Missing Implementation:

    • Review routes.php to ensure routes are specific and not overly permissive.
    • Verify that sensitive functionalities are protected by specific routes and access control mechanisms in controllers.

Mitigation Strategy: Utilize CodeIgniter's Logging for Error Handling

Mitigation Strategy: Utilize CodeIgniter's Logging for Error Handling

  • Description:

    1. Configure CodeIgniter's logging in application/config/config.php by setting $config['log_threshold'] to an appropriate level (e.g., 1 for errors, 2 for debug and errors, 3 for info, debug and errors, 4 for all messages).
    2. Ensure $config['log_path'] is set to a secure directory outside the web root if possible, or within a protected directory.
    3. In your controllers and models, use CodeIgniter's log_message() function to log errors, exceptions, and security-related events. Example: log_message('error', 'Database connection failed.');.
    4. Regularly monitor and review the generated log files to identify potential issues, errors, and security incidents.

  • Threats Mitigated:

    • Information Disclosure (Error Details in Production) - Severity: Medium - Detailed error messages displayed to users in production can reveal sensitive information.
    • Security Monitoring Gaps - Severity: Medium - Lack of logging hinders the ability to detect and respond to security incidents.

  • Impact:

    • Information Disclosure (Error Details in Production) - Impact: Medium - Using logging and disabling display_errors prevents sensitive error details from being shown to users.
    • Security Monitoring Gaps - Impact: Medium - Logging provides valuable data for security monitoring and incident response.

  • Currently Implemented:

    • Yes, logging is configured and enabled.

  • Missing Implementation:

    • Review $config['log_threshold] to ensure appropriate logging level is set.
    • Verify $config['log_path] points to a secure location.
    • Ensure log_message() is used strategically throughout the application to log relevant events, especially errors and security-related actions.

Mitigation Strategy: Disable display_errors in Production

Mitigation Strategy: Disable display_errors in Production

  • Description:

    1. Open the main index.php file in your web root directory.
    2. Locate the line that sets ENVIRONMENT constant. Ensure it is set to 'production' for production environments.
    3. Below the ENVIRONMENT setting, find the conditional block that checks the environment:
    switch (ENVIRONMENT)
{
    case 'development':
        error_reporting(-1);
        ini_set('display_errors', 1);
    break;

    case 'testing':
    case 'production':
        ini_set('display_errors', 0);
        if (version_compare(PHP_VERSION, '5.3', '>='))
        {
            error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT & ~E_USER_NOTICE & ~E_USER_DEPRECATED);
        }
        else
        {
            error_reporting(E_ALL & ~E_NOTICE &  ~E_STRICT & ~E_USER_NOTICE);
        }
    break;

    default:
        header('HTTP/1.1 503 Service Unavailable.', TRUE, 503);
        echo 'An application error has occurred.';
        exit(1); // EXIT_ERROR
}
    1. Confirm that within the 'production' case, ini_set('display_errors', 0); is set to disable error display.

  • Threats Mitigated:

    • Information Disclosure (Error Details) - Severity: Medium - Displaying PHP errors in production can reveal sensitive information about the application's internal workings, file paths, and database structure.

  • Impact:

    • Information Disclosure (Error Details) - Impact: Medium - Disabling display_errors prevents the exposure of sensitive error details to users in production.

  • Currently Implemented:

    • Yes, display_errors is disabled in index.php for the 'production' environment.

  • Missing Implementation:

    • N/A - display_errors is correctly disabled for production. Ensure the ENVIRONMENT constant is correctly set to 'production' in production deployments.

Mitigation Strategy: Avoid Relying Solely on Global XSS Filtering

Mitigation Strategy: Avoid Relying Solely on Global XSS Filtering

  • Description:

    1. While CodeIgniter offers a global XSS filter ($config['global_xss_filtering'] in config/config.php), do not rely on it as your primary XSS prevention mechanism.
    2. Understand that global XSS filtering can be bypassed and may not be effective against all types of XSS attacks.
    3. Ensure that you are primarily using context-aware output encoding with esc() in your views as described in the "Implement Context-Aware Output Encoding using esc()" mitigation strategy.
    4. Consider leaving $config['global_xss_filtering'] set to FALSE to avoid a false sense of security and to enforce the use of esc() for output encoding. If enabled, treat it as a supplementary, not primary, security measure.

  • Threats Mitigated:

    • Cross-Site Scripting (XSS) - Severity: High - Relying solely on global XSS filtering can lead to vulnerabilities if the filter is bypassed or ineffective.

  • Impact:

    • XSS - Impact: Medium (if relying on global filter) / Impact: Low (if using esc() primarily) - Global XSS filtering alone provides limited protection. Proper output encoding with esc() is significantly more effective.

  • Currently Implemented:

    • Global XSS filtering is currently disabled ($config['global_xss_filtering'] = FALSE;).

  • Missing Implementation:

    • N/A - Global XSS filtering is disabled, which encourages the correct approach of using esc() for output encoding. Ensure developers understand not to enable and rely on global XSS filtering as a primary security measure.