CWE-425: Direct Request ('Forced Browsing')

Learn about CWE-425 (Direct Request ('Forced Browsing')), its security impact, exploitation methods, and prevention guidelines.

What is Direct Request ('Forced Browsing')?

• Overview: CWE-425, Direct Request ('Forced Browsing'), occurs when a web application fails to enforce proper authorization on restricted resources, assuming they can only be accessed through specific navigation paths.

• Exploitation Methods:

  • Attackers can exploit this by directly navigating to URLs, scripts, or files that are supposed to be restricted.
  • Common attack patterns include guessing URLs or reviewing application pages to identify unprotected resources.

• Security Impact:

  • Direct consequences include unauthorized access to sensitive data or functionality.
  • Potential cascading effects could involve data breaches or further exploitation of the application.
  • Business impact includes loss of customer trust, legal liabilities, and potential regulatory fines.

• Prevention Guidelines:

  • Specific code-level fixes involve implementing and enforcing access controls on all resource requests, regardless of navigation path.
  • Security best practices include conducting thorough access control checks and not relying solely on UI-based navigation paths for security.
  • Recommended tools and frameworks include using web application firewalls and security testing tools to identify unauthorized access points.
Corgea can automatically detect and fix Direct Request ('Forced Browsing') in your codebase. [Try Corgea free today](https://corgea.app).

Technical Details

Likelihood of Exploit: Not specified

Affected Languages: Not Language-Specific

Affected Technologies: Web Based

Vulnerable Code Example

Python Example

from flask import Flask, request, send_from_directory

app = Flask(__name__)

@app.route('/download/<path:filename>')
def download_file(filename):
    # Vulnerable code: No authentication or authorization checks
    return send_from_directory('/var/www/files', filename)

In this vulnerable example, the /download/<path:filename> endpoint allows direct access to files in the /var/www/files directory without any authentication or authorization checks. This means any user, regardless of their permissions, can access any file in that directory simply by knowing or guessing the file name.

How to fix Direct Request ('Forced Browsing')?

To fix this vulnerability, you must ensure that authorization checks are performed before serving files from the server. This involves:

  1. Authentication Check: Ensure that the user is authenticated.
  2. Authorization Check: Verify that the authenticated user has permissions to access the requested file.
  3. File Validation: Ensure that the requested file path is valid and does not allow directory traversal attacks.
  4. Logging and Monitoring: Implement logging of access attempts for auditing and monitoring purposes.

Fixed Code Example

from flask import Flask, request, send_from_directory, abort
from functools import wraps

app = Flask(__name__)

def authenticate_user():
    # Placeholder function for user authentication
    # In practice, use a robust authentication mechanism
    return request.headers.get("Authorization") == "Bearer valid_token"

def authorize_user(filename):
    # Placeholder function for user authorization
    # Implement logic to check if the user has access to the specific file
    allowed_files = {"user1": ["file1.txt", "file2.txt"], "user2": ["file3.txt"]}
    user = "user1"  # Example: Identify user from session or token
    return filename in allowed_files.get(user, [])

@app.route('/download/<path:filename>')
def download_file(filename):
    if not authenticate_user():
        abort(401)  # Unauthorized
    
    if not authorize_user(filename):
        abort(403)  # Forbidden
    
    # Safe file serving after authorization
    try:
        # Validate filename to prevent directory traversal attacks
        if ".." in filename or filename.startswith("/"):
            abort(400)  # Bad Request
        
        return send_from_directory('/var/www/files', filename)
    except FileNotFoundError:
        abort(404)  # Not Found

In the fixed version, we incorporate several security measures:

  • Authentication: We check if the user is authenticated using a placeholder authenticate_user function. In a real-world application, this should involve checking a session, token, or other secure method.
  • Authorization: We verify if the authenticated user is authorized to access the requested file using a placeholder authorize_user function. This logic should be tailored to your application's requirements.
  • Input Validation: We check for directory traversal attempts by ensuring the filename does not contain suspicious patterns like .. or start with a /.
  • Error Handling: We handle potential errors, such as file not found, with appropriate HTTP status codes.
  • Security Best Practices: Ensure that the application uses secure methods for user identification, such as token-based authentication, and that all inputs are validated and sanitized.
Corgea Logo

Find this vulnerability and fix it with Corgea

Scan your codebase for CWE-425: Direct Request ('Forced Browsing') and get remediation guidance

Start for free and no credit card needed.