How to remediate – Web Form Sending Credentials Using GET (PCI-DSS check)

1. Introduction

The Web Form Sending Credentials Using GET vulnerability occurs when a web application transmits login details via an HTTP GET request. This means usernames and passwords are visible in server access logs, potentially exposing sensitive data to unauthorised parties. Systems with publicly accessible web forms are usually affected. Confidentiality is the primary impact, as credentials can be intercepted.

2. Technical Explanation

This vulnerability happens because HTTP GET requests append data to the URL. This data is then often logged by web servers and proxies. An attacker could access these logs to retrieve usernames and passwords. The Common Weakness Enumeration (CWE) ID for this issue is CWE-533. A typical attack involves an attacker gaining access to server logs or intercepting network traffic containing the URL with embedded credentials.

• Root cause: Data submitted via HTTP GET instead of POST.
• Exploit mechanism: An attacker accesses server logs, proxy logs, or browser history where the request URI (containing the username and password) is stored. For example, an attacker could view Apache access logs to find a URL like /login?username=test&password=secret.
• Scope: Web applications using HTTP GET for credential submission are affected. This includes custom-built web apps and potentially older versions of commercial software.

3. Detection and Assessment

Confirming this vulnerability involves checking how forms submit data. A quick check is to inspect the network traffic when submitting a form. A thorough method is to review server logs for exposed credentials.

• Quick checks: Use your browser’s developer tools (Network tab) and observe if login details appear in the URL when submitting the form.
• Scanning: Nessus plugin ID 10429 can detect this issue, but results should be verified manually.
• Logs and evidence: Examine web server access logs for URLs containing usernames and passwords after a successful login attempt. Look for patterns like ?username=...&password=... in log files such as Apache’s access.log or IIS logs.

curl -v https://example.com/login?username=test&password=secret

4. Solution / Remediation Steps

The fix is to change web application forms to use HTTP POST instead of GET. This prevents credentials from being visible in URLs and logs.

4.1 Preparation

• Ensure you have access to the source code or configuration files for the web application. A roll back plan is to revert the code change from your version control system.
• A change window may be needed depending on service impact and approval policies.

4.2 Implementation

1. Step 1: Modify the HTML form tag to use the POST method instead of GET. Change `
   
   ` to `

   `.
2. Step 2: Update the server-side code that handles the form submission to process data sent via POST requests. This usually involves accessing request parameters differently (e.g., using `$_POST` in PHP instead of `$_GET`).
3. Step 3: Test the updated form thoroughly with various inputs and user accounts.

4.3 Config or Code Example

Before

<form action="/login" method="GET">
  Username: <input type="text" name="username"><br>
  Password: <input type="password" name="password"><br>
  <input type="submit" value="Login">
</form>

After

<form action="/login" method="POST">
  Username: <input type="text" name="username"><br>
  Password: <input type="password" name="password"><br>
  <input type="submit" value="Login">
</form>

4.4 Security Practices Relevant to This Vulnerability

Several security practices help prevent this issue.

• Practice 1: Input validation prevents malicious data from being submitted through the form, regardless of the method used.
• Practice 2: Using secure defaults ensures forms are configured with POST as the default submission method where possible.

4.5 Automation (Optional)

No specific automation is recommended for this vulnerability due to its code-level nature, but static analysis tools can help identify GET requests handling sensitive data.

5. Verification / Validation

Confirm the fix by checking that credentials are no longer visible in URLs and server logs.

• Re-test: Re-run the earlier detection method by inspecting server logs for exposed credentials; they should no longer be present.
• Smoke test: Verify that users can still log in successfully and access protected resources.
• Monitoring: Check web server access logs periodically for any unexpected URL parameters containing sensitive data as an example alert.

curl -v https://example.com/login # Should not show username or password in the URL

6. Preventive Measures and Monitoring

Update security baselines to include this check.

• Baselines: Update your web application security baseline to require HTTP POST for all forms handling sensitive data.
• Pipelines: Integrate static analysis tools into your CI/CD pipeline to identify GET requests used for credential submission.
• Asset and patch process: Review code changes regularly to ensure that new forms are not vulnerable to this issue. A monthly review cycle is sensible.

7. Risks, Side Effects, and Roll Back

Changing from GET to POST may require updates to client-side code or configurations if they rely on the URL parameters.

• Risk or side effect 1: Client-side JavaScript that parses URL parameters for login details will break. Mitigation is to update the JavaScript code to access form data directly.
• Roll back: Revert the changes made to the HTML form tag and server-side code, restoring the original GET method.

8. References and Resources

Links to relevant documentation.

• Vendor advisory or bulletin: No specific vendor advisory available for this general vulnerability.
• NVD or CVE entry: https://cwe.mitre.org/data/definitions/533.html
• Product or platform documentation relevant to the fix: https://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3