Error Handling and Information Leakage

Information Leakage: When Error Messages Become an Attacker's Guide

Information leakage occurs when an application reveals sensitive internal details — stack traces, database errors, file paths, configuration values, or framework versions — in responses visible to users or attackers. These details provide a roadmap for further exploitation.

What Leaks and Why It Matters

Stack Traces

A stack trace reveals the application's internal structure: file paths, function names, variable values, and the exact line where the error occurred. This tells the attacker:

• Which framework and version is in use (enabling targeted exploit development)
• The application's directory structure (enabling path traversal attacks)
• The flow of execution (enabling logic flaw discovery)

HTTP/1.1 500 Internal Server Error

Traceback (most recent call last):
  File "/app/routes/user.py", line 42, in get_user
    user = db.query(f"SELECT * FROM users WHERE id = {user_id}")
  File "/app/db/connection.py", line 15, in query
    cursor.execute(sql)
sqlalchemy.exc.ProgrammingError: (psycopg2.errors.SyntaxError) syntax error at or near "WHERE"

This stack trace reveals: the framework (SQLAlchemy), the database (PostgreSQL), the file structure, and the vulnerable query pattern.

Database Errors

Database errors often include table names, column names, and query fragments:

ERROR: relation "usr" does not exist

This tells the attacker the table is named users (not usr), and they can refine their SQL injection payload.

Framework and Version Disclosure

HTTP headers often reveal the server software and version:

Server: Apache/2.4.41 (Ubuntu)
X-Powered-By: Express/4.17.1

An attacker can look up known vulnerabilities for these exact versions.

File Paths

Errors that include file paths reveal the server's directory structure:

FileNotFoundError: [Errno 2] No such file or directory: '/var/www/app/config/database.yml'

This tells the attacker the application root is /var/www/app/ and that a config file exists at config/database.yml.

The Attacker's Workflow

Information leakage feeds into every phase of an attack:

1. Reconnaissance: Error messages reveal the technology stack, directory structure, and configuration details.
2. Vulnerability discovery: Stack traces point to the exact code location of a flaw.
3. Exploitation: Database errors refine injection payloads. File paths enable path traversal.
4. Post-exploitation: Verbose errors during lateral movement reveal internal service names and configurations.

Real-World Impact

In 2017, the Equifax breach was partially attributed to an Apache Struts vulnerability. While the vulnerability itself was the entry point, verbose error messages during the attack likely helped attackers understand the internal application structure and pivot to other systems.

Designing Secure Error Responses and Effective Logging

The goal of secure error handling is to provide useful information to legitimate users and developers while revealing nothing useful to attackers. This requires a deliberate separation between client-facing error messages and server-side diagnostic logs.

Generic Error Responses

Return the same generic error message regardless of the underlying cause:

# SECURE — generic error response
@app.errorhandler(500)
def internal_error(error):
    # Log the full error details server-side
    logger.error(f"Internal error: {error}", exc_info=True)
    
    # Return a generic message to the client
    return jsonify({
        'error': 'An internal error occurred',
        'reference': g.correlation_id
    }), 500

The client sees: {"error": "An internal error occurred", "reference": "abc-123-def"}

The server log contains the full stack trace, request details, and the correlation ID abc-123-def.

Correlation IDs

A correlation ID is a unique identifier assigned to each request. It appears in the client-facing error response and in all server-side log entries for that request. This allows support teams to trace a generic error to the full diagnostic details:

import uuid
from flask import g, request

@app.before_request
def assign_correlation_id():
    g.correlation_id = request.headers.get('X-Correlation-ID', str(uuid.uuid4()))

@app.after_request
def add_correlation_id_header(response):
    response.headers['X-Correlation-ID'] = g.correlation_id
    return response

When a user reports an error, they provide the correlation ID from the error response. The support team searches logs for that ID and finds the full stack trace, request parameters, and execution context.

What to Log (and What Not to Log)

Log:

• Request method, path, and correlation ID
• User ID (if authenticated)
• Error type and stack trace
• Request parameters (excluding sensitive fields)
• Response status code and duration
• Security-relevant events (authentication failures, authorization denials, rate limit triggers)

Never log:

• Passwords or password hashes
• Session tokens or API keys
• Credit card numbers or financial data
• Personally identifiable information (PII) beyond what is necessary
• Full request bodies containing sensitive data

# SECURE logging with sensitive data redaction
import copy

def sanitize_for_logging(data):
    sensitive_fields = {'password', 'token', 'credit_card', 'ssn', 'api_key'}
    sanitized = copy.deepcopy(data)
    for field in sensitive_fields:
        if field in sanitized:
            sanitized[field] = '[REDACTED]'
    return sanitized

logger.info(f"Request: {sanitize_for_logging(request.json)}")

Structured Logging

Use structured logging (JSON format) to make log analysis automated and consistent:

import json
import logging

class JSONFormatter(logging.Formatter):
    def format(self, record):
        log_entry = {
            'timestamp': self.formatTime(record),
            'level': record.levelname,
            'message': record.getMessage(),
            'correlation_id': getattr(record, 'correlation_id', None),
            'user_id': getattr(record, 'user_id', None),
            'path': getattr(record, 'path', None),
            'method': getattr(record, 'method', None),
            'status_code': getattr(record, 'status_code', None),
        }
        return json.dumps(log_entry)

Structured logs can be ingested by SIEM (Security Information and Event Management) systems for automated alerting on security events.

Practice: Fix Information Leakage

The following code leaks sensitive information. Identify the issues and fix them:

@app.route('/api/users/<user_id>')
def get_user(user_id):
    try:
        user = db.execute(f"SELECT * FROM users WHERE id = {user_id}").fetchone()
        if not user:
            return jsonify({'error': f'User {user_id} not found in table users'}), 404
        return jsonify(user)
    except Exception as e:
        return jsonify({'error': str(e), 'traceback': traceback.format_exc()}), 500

Issues:

1. The 404 error reveals the table name (users)
2. The 500 error returns the full exception message and stack trace to the client
3. The SQL query is also vulnerable to injection (f-string)

Fix:

@app.route('/api/users/<user_id>')
def get_user(user_id):
    try:
        user = db.execute("SELECT * FROM users WHERE id = %s", (user_id,)).fetchone()
        if not user:
            return jsonify({'error': 'User not found', 'reference': g.correlation_id}), 404
        return jsonify(user)
    except Exception as e:
        logger.error(f"Error fetching user {user_id}: {e}", exc_info=True)
        return jsonify({'error': 'An internal error occurred', 'reference': g.correlation_id}), 500