CWE-650: Trusting HTTP Permission Methods on the Server Side

What is Trusting HTTP Permission Methods on the Server Side?

• Overview: Trusting HTTP Permission Methods on the Server Side (CWE-650) occurs when an application assumes that HTTP GET requests are only used for data retrieval and do not alter server-side resources, which may lead to unintended state changes if GET requests are improperly handled.

• Exploitation Methods:

• Attackers can exploit this by crafting GET requests that modify or delete resources, bypassing intended access controls.
• Common attack patterns include using GET requests to perform actions typically reserved for POST, PUT, or DELETE methods, like updating or deleting data.

• Security Impact:

• Direct consequences include unauthorized data modification, deletion, or creation, potentially compromising data integrity.
• Potential cascading effects might involve further unauthorized access or data exposure if state changes lead to security misconfigurations.
• Business impact could involve data breaches, loss of customer trust, regulatory fines, and operational disruption.

• Prevention Guidelines:

• Ensure that GET requests do not have side effects or alter server-side resources; use appropriate HTTP methods for state-changing operations.
• Implement strict access controls and validation to ensure that only authorized users can perform actions that modify resources.
• Recommended tools and frameworks include web application firewalls (WAFs) and secure coding practices in frameworks that enforce RESTful principles, ensuring correct use of HTTP methods.

Corgea can automatically detect and fix Trusting HTTP Permission Methods on the Server Side in your codebase. [Try Corgea free today](https://corgea.app).

Technical Details

Likelihood of Exploit: High

Affected Languages: Not Language-Specific

Affected Technologies: Not specified

Vulnerable Code Example

from flask import Flask, request

app = Flask(__name__)

@app.route('/update_user/<int:user_id>', methods=['GET', 'POST'])
def update_user(user_id):
    # Vulnerability: Using GET for state-changing operations
    # GET requests should not alter server state as they can be cached or pre-fetched by browsers
    if request.method == 'GET':
        # Insecure: Modifying user data via GET request
        update_user_in_db(user_id, request.args.get('name'), request.args.get('email'))
        return "User updated via GET", 200
    elif request.method == 'POST':
        update_user_in_db(user_id, request.form['name'], request.form['email'])
        return "User updated via POST", 200

def update_user_in_db(user_id, name, email):
    # Simulated database update
    print(f"Updating user {user_id} with name={name}, email={email}")

How to fix Trusting HTTP Permission Methods on the Server Side?

To address this vulnerability, it's crucial to restrict state-changing operations to HTTP methods specifically intended for such purposes, such as POST, PUT, or DELETE. GET requests should strictly be used for safe, read-only operations.

The best practice is to:

1. Ensure GET requests do not perform operations that change the server's state.
2. Use POST or other appropriate methods for operations that modify server state.
3. Validate HTTP methods for each route to ensure compliance with RESTful standards.

Fixed Code Example

from flask import Flask, request

app = Flask(__name__)

@app.route('/update_user/<int:user_id>', methods=['POST'])
def update_user(user_id):
    # Fix: Restrict the endpoint to use POST method only
    # This ensures that state changes are made through methods intended for such use
    update_user_in_db(user_id, request.form['name'], request.form['email'])
    return "User updated via POST", 200

def update_user_in_db(user_id, name, email):
    # Simulated database update
    print(f"Updating user {user_id} with name={name}, email={email}")

In the fixed code, the update_user endpoint is restricted to POST requests only. This change ensures that any state-changing operation is explicitly requested via a method that is semantically intended for such changes, preventing unauthorized modifications through GET requests. This aligns with RESTful principles, enhancing both security and clarity in API design.