Skip to main content

Technical information leak - Errors

Need​

Prevention of technical information leaks through error messages

Context​

  • Usage of Python 3.6 for developing Python applications
  • Usage of Django for building web applications in Python

Description​

Non compliant code​

# views.py

from django.http import HttpResponse
from django.views import View

class MyView(View):
    def post(self, request, *args, **kwargs):
        data = request.POST
        message = data['message']
        return HttpResponse('Message received: {}'.format(message))

In the given Python code using the Django framework, there is a MyView class that handles POST requests. The post method extracts data from the request using request.POST. This data is assumed to have a 'message' key, which is then used to create a response.

The vulnerability lies in the fact that the server assumes that the 'message' key will always be present in the request data. If a user sends a POST request without the 'message' key or sends massive requests or massive characters in the body of the application, the server will throw a KeyError, revealing technical information about the server and application structure.

This can lead to an information leak, allowing an attacker to gain knowledge about the server's internal workings and potentially exploit other vulnerabilities.

Steps​

  • Implement error handling to catch exceptions and prevent them from being exposed to the user.
  • Use Django's built-in rate limiting features to prevent users from sending too many requests in a short period of time.
  • Validate the input data to ensure it meets certain criteria before processing it. This can help prevent errors caused by unexpected or malicious input.
  • Limit the size of the request body to prevent users from sending massive amounts of data that could cause the server to crash or slow down.
  • Log errors for further analysis and debugging, but do not expose these logs to the user.

Compliant code​

from django.http import HttpResponse, JsonResponse
from django.views import View
from django.core.exceptions import ValidationError
from django.views.decorators.csrf import csrf_exempt
from django.utils.decorators import method_decorator
from django.conf import settings
from rest_framework.decorators import throttle_classes
from rest_framework.throttling import AnonRateThrottle

@method_decorator(csrf_exempt, name='dispatch')
@throttle_classes([AnonRateThrottle])
class MyView(View):
    def post(self, request, *args, **kwargs):
        try:
            data = request.POST
            message = data.get('message')
            if message is None:
                raise ValidationError('Message is required.')
            if len(message) > settings.MAX_MESSAGE_LENGTH:
                raise ValidationError('Message is too long.')
            return HttpResponse('Message received: {}'.format(message))
        except Exception as e:
            return JsonResponse({'error': 'An error occurred.'}, status=400)

The updated code includes several improvements to address the identified vulnerability:

  1. Error Handling: The try/except block is used to catch any exceptions that occur during the processing of the request. If an exception is caught, a generic error message is returned to the user, preventing any technical information from being leaked.

  2. Rate Limiting: The @throttle_classes([AnonRateThrottle]) decorator is used to limit the rate at which requests can be made to the endpoint. This helps to prevent the server from being overwhelmed by a large number of requests in a short period of time.

  3. Input Validation: The message field is checked to ensure it is not None and does not exceed a maximum length. If either of these checks fail, a ValidationError is raised. This helps to prevent errors caused by unexpected or malicious input.

  4. Request Body Size Limiting: The length of the message field is checked against a maximum length defined in the settings. If the message is too long, a ValidationError is raised. This helps to prevent the server from being overwhelmed by large amounts of data.

  5. Error Logging: While not shown in the code, it is recommended to log any exceptions that are caught for further analysis and debugging. However, these logs should not be exposed to the user.

References​

Last updated on