How to remediate – HTTP Verb Tampering

1. Introduction

HTTP Verb Tampering is an attack where attackers bypass authentication checks by using HTTP verbs other than those expected by a web application. This can allow unauthorised access to sensitive data and functionality. Systems that rely on verb-based security mechanisms, such as restricting access to only GET requests, are vulnerable. A successful attack could compromise confidentiality, integrity, and availability of the affected application.

2. Technical Explanation

HTTP Verb Tampering occurs because web servers often respond to all HTTP methods (GET, POST, PUT, DELETE, PATCH, etc.), while applications may only explicitly handle a subset. If an application restricts access based on GET requests alone, an attacker can attempt the same action using other verbs like POST or PUT. This bypasses the intended security controls.

• Root cause: Insufficient input validation and reliance on HTTP verb-based authentication without blocking unexpected methods.
• Exploit mechanism: An attacker sends a request with an alternative HTTP method (e.g., POST instead of GET) to access a restricted resource or function. For example, if only GET requests are allowed for viewing a profile page, the attacker might use a POST request with the same URL parameters.
• Scope: Web applications and servers that implement verb-based authentication without proper validation of HTTP methods.

3. Detection and Assessment

To confirm vulnerability, check if alternative HTTP verbs can access resources restricted to standard ones. A thorough method involves using a web proxy to intercept requests and modify the HTTP method.

• Quick checks: Use browser developer tools or `curl` to send POST, PUT, DELETE, and PATCH requests to URLs that are only intended for GET requests. Check if these requests return the same content as a valid GET request.
• Scanning: Burp Suite’s scanner can identify HTTP Verb Tampering vulnerabilities. Nessus plugin ID 16378 may also detect this issue. These are examples only, and results should be verified manually.
• Logs and evidence: Examine web server access logs for requests using unexpected HTTP methods to restricted URLs. Look for non-GET requests accessing sensitive resources.

curl -X POST https://example.com/sensitive_page

4. Solution / Remediation Steps

The most effective solution is to block all unexpected HTTP verbs at the web server or application level, rather than maintaining a blocklist of allowed verbs. This prevents attackers from exploiting any newly introduced methods.

4.1 Preparation

• Ensure you have access to modify the web server or application configuration files. A rollback plan involves restoring the original configuration file.
• A change window may be required depending on the production environment, with approval from relevant stakeholders.

4.2 Implementation

1. Step 1: Configure your web server (e.g., Apache, Nginx, IIS) to reject requests using unsupported HTTP methods.
2. Step 2: If using a web application framework, configure the framework to only allow expected HTTP methods for specific routes or controllers.

4.3 Config or Code Example

Before

# Apache example - allowing all methods
<Directory /var/www/html>
    AllowOverride All
    Require all granted
</Directory>

After

# Apache example - blocking unexpected methods
<Directory /var/www/html>
    AllowOverride All
    Require all granted
    <LimitExcept GET HEAD>
        Deny from all
    </LimitExcept>
</Directory>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent HTTP Verb Tampering attacks. Least privilege reduces the impact of successful exploitation, while input validation prevents attackers from sending malicious requests. Safe defaults ensure that unexpected methods are blocked by default.

• Practice 1: Implement least privilege to limit the damage an attacker can cause if they bypass authentication.
• Practice 2: Use robust input validation to block any unexpected or malformed HTTP requests.

4.5 Automation (Optional)

# Example Ansible task for Apache
- name: Block unexpected HTTP methods in Apache configuration
  lineinfile:
    path: /etc/apache2/sites-available/000-default.conf
    regexp: '^<LimitExcept GET HEAD'
    line: '<LimitExcept GET HEADn        Deny from alln    </LimitExcept>'
  notify: Restart Apache

5. Verification / Validation

• Post-fix check: Use `curl -X POST https://example.com/sensitive_page` and verify a 403 Forbidden or similar error is returned.
• Re-test: Repeat the quick checks from Section 3 to confirm that alternative HTTP methods are no longer successful.
• Smoke test: Verify that standard GET requests to known working pages still return the expected content.
• Monitoring: Monitor web server logs for blocked requests using unexpected HTTP methods as an indicator of potential attacks.

curl -X POST https://example.com/sensitive_page

6. Preventive Measures and Monitoring

Regularly update security baselines to include blocking of unwanted HTTP methods. Implement checks in CI/CD pipelines to prevent deployments with insecure configurations. A sensible patch or config review cycle should be established based on the risk profile.

• Baselines: Update your web server baseline configuration to block unexpected HTTP methods as a standard practice.
• Pipelines: Add static analysis checks in CI/CD pipelines to identify and prevent deployments with insecure configurations that allow unwanted HTTP methods.

7. Risks, Side Effects, and Roll Back

Blocking all unexpected HTTP verbs could potentially break legitimate functionality if the application relies on non-standard methods that were not initially identified. A roll back involves restoring the original web server configuration file.

• Roll back: Restore the original web server configuration file from backup. Restart the web service.

8. References and Resources

• Vendor advisory or bulletin: N/A
• NVD or CVE entry: N/A
• Product or platform documentation relevant to the fix: OWASP HTTP Verb Tampering