Technical information leak - Headers - Python

Technical information leak - Headers - Python

Need

Prevention of technical information leakage through server response headers

Context

  • Usage of Python 3.0+ for developing Python applications
  • Usage of Django for building web applications in Python

Description

Non compliant code

        # Django settings file
from django.conf import settings

settings.configure(
    DEBUG=True,
    SECRET_KEY='thisisasecretkey',
    ROOT_URLCONF=__name__,
    MIDDLEWARE_CLASSES=(
        'django.middleware.common.CommonMiddleware',
        'django.middleware.csrf.CsrfViewMiddleware',
        'django.middleware.clickjacking.XFrameOptionsMiddleware',
    ),
)

# Simple view function
def hello_world(request):
    return HttpResponse("Hello World")

This is a basic Django application with a simple view function hello_world that returns a HTTP response "Hello World".

The vulnerability lies in the server response headers that this Django application sends back to the client. By default, Django server response headers include technical information such as the Django version, which can be exploited by attackers to identify potential security vulnerabilities.

In the above code, Django's built-in middleware classes are used, which include CommonMiddleware, CsrfViewMiddleware, and XFrameOptionsMiddleware. These middleware classes handle tasks such as cross-site request forgery protection and clickjacking protection. However, they do not remove or alter the server response headers to prevent information leakage.

An attacker can inspect the server response headers and find out the Django version by looking at the 'X-Powered-By' or 'Server' headers. If the Django version has known vulnerabilities, the attacker can use this information to launch targeted attacks against the application. This is why it is a common security best practice to remove or obfuscate such technical information from the server response headers.

Steps

  • Remove or modify the server response headers that are providing unnecessary technical information. This can be done by creating a custom middleware in Django.
  • In the custom middleware, override the 'process_response' method to modify or delete the headers that are leaking information.
  • Ensure that the 'DEBUG' setting is set to 'False' in the production environment to prevent the leakage of any sensitive information.
  • Regularly update and patch the server and its components to minimize the risk of known vulnerabilities being exploited.

Compliant code

        # Django settings file
from django.conf import settings

settings.configure(
    DEBUG=False,  # Ensure DEBUG is set to False in production
    SECRET_KEY='thisisasecretkey',
    ROOT_URLCONF=__name__,
    MIDDLEWARE_CLASSES=(
        'django.middleware.common.CommonMiddleware',
        'django.middleware.csrf.CsrfViewMiddleware',
        'django.middleware.clickjacking.XFrameOptionsMiddleware',
        'myapp.middleware.RemoveHeadersMiddleware',  # Add custom middleware
    ),
)

# Custom middleware to remove sensitive headers
class RemoveHeadersMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        response = self.get_response(request)
        self.process_response(request, response)
        return response

    def process_response(self, request, response):
        # Remove or modify headers that are leaking information
        response['Server'] = ''
        response['X-Powered-By'] = ''
        return response

# Simple view function
def hello_world(request):
    return HttpResponse("Hello World")

The above code fixes the vulnerability by creating a custom middleware in Django that removes or modifies the server response headers that are providing unnecessary technical information.

In the settings.configure method, DEBUG is set to False to prevent the leakage of any sensitive information in a production environment.

The custom middleware, RemoveHeadersMiddleware, is added to the MIDDLEWARE_CLASSES tuple. This middleware overrides the process_response method to modify or delete the headers that are leaking information. In this case, the 'Server' and 'X-Powered-By' headers are set to an empty string, effectively removing them from the response.

This approach ensures that technical information such as technology names or component versions are not leaked through the server response headers, thereby mitigating the risk of this information being used to exploit known vulnerabilities.

References