Technical information leak - Headers
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.