System Information Leakage

Learn how to prevent system information leakage with real code examples and best practices. Protect your application from exposing sensitive system details and technical information.

Tools recognizing this:

Opengrep Fortify Checkmarx SonarQube Snyk Semgrep CodeQL

What is System Information Leakage and How Does it Work?

System Information Leakage occurs when an application inadvertently reveals sensitive technical information, such as stack traces, error messages, or system details. This information can be valuable to attackers, helping them understand the system's architecture and potential vulnerabilities.

The exposed information might include:

Stack traces with internal code paths
Database error messages
Server versions and technologies
Internal IP addresses or hostnames
System file paths
Debug information

This guide covers System Information Leakage, examples, prevention methods, and how to secure your application using real-world techniques.

One Simple System Information Leakage Example

Consider this common example of error handling:

try {
    processRequest();
} catch (Exception e) {
    response.sendError(500, e.toString());
}

This could expose sensitive information like:

java.sql.SQLException: Error executing query at line 42 in /var/www/app/dao/UserDAO.java

The error message reveals: Internal file pathsImplementation detailsDatabase information

System Information Leakage Prevention Methods: How to Fix Your Code

The most effective way to fix System Information Leakage is to implement proper error handling with custom error messages and logging. This involves catching specific exceptions, logging them securely, and showing generic error messages to users.

Code Samples

Vulnerable Code

try {
    processRequest();
} catch (Exception e) {
    
    response.sendError(500, e.toString());
}

Fixed Code

try {
    processRequest();
} catch (Exception e) {
    String errorId = generateErrorId();
    logger.error("Unexpected error: " + errorId, e);
    response.sendError(500, "An unexpected error occurred. Reference: " + errorId);
}

Fix Explanation

The vulnerable code exposes detailed error information to users.The fix generates a unique error ID for tracking.Internal details are logged securely but hidden from users.Users receive a generic message with a reference ID.

Vulnerable Code

app.use((err, req, res, next) => {
    console.error(err.stack);
    res.status(500).send(err.stack);
});

Fixed Code

app.use((err, req, res, next) => {
    const errorId = generateUniqueId();
    console.error(`Error ${errorId}:`, err);
    res.status(500).json({
        error: 'Internal Server Error',
        reference: errorId
    });
});

Fix Explanation

The vulnerable code sends stack traces directly to clients.The fix implements a custom error handler with unique IDs.Error details are logged server-side only.Clients receive a sanitized JSON response with reference ID.

Vulnerable Code

try:
    process_request()
except Exception as e:
    logging.error(str(e))
    return jsonify({'error': str(e)}), 500

Fixed Code

try:
    process_request()
except Exception as e:
    error_id = generate_error_id()
    logging.error(f"Error {error_id}: {str(e)}", exc_info=True)
    return jsonify({
        'error': 'Internal Server Error',
        'reference': error_id
    }), 500

Fix Explanation

The vulnerable code exposes exception details in the response.The fix implements error tracking with unique identifiers.Full error details are logged securely.Users receive a generic error message with reference ID.

Vulnerable Code

try
{
    ProcessRequest();
}
catch (Exception ex)
{
    _logger.LogError(ex.ToString());
    return StatusCode(500, ex.Message);
}

Fixed Code

try
{
    ProcessRequest();
}
catch (Exception ex)
{
    var errorId = Guid.NewGuid().ToString();
    _logger.LogError(ex, "Error {ErrorId}: {Message}", errorId, ex.Message);
    return StatusCode(500, new
    {
        Error = "An unexpected error occurred",
        Reference = errorId
    });
}

Fix Explanation

The vulnerable code returns exception messages to clients.The fix generates a GUID for error tracking.Structured logging captures full error details.Users receive a safe error response with reference ID.

Vulnerable Code

try {
    processRequest();
} catch (Exception $e) {
    error_log($e->getMessage());
    http_response_code(500);
    echo $e->getMessage();
}

Fixed Code

try {
    processRequest();
} catch (Exception $e) {
    $errorId = uniqid('err_');
    error_log("Error $errorId: " . $e->getMessage());
    http_response_code(500);
    echo json_encode([
        'error' => 'Internal Server Error',
        'reference' => $errorId
    ]);
}

Fix Explanation

The vulnerable code displays exception messages to users.The fix generates unique error identifiers.Error details are logged but not exposed.Users receive a JSON response with reference ID.

Vulnerable Code

try {
    processRequest();
} catch (const std::exception& e) {
    syslog(LOG_ERR, e.what());
    std::cout << "Error: " << e.what() << std::endl;
}

Fixed Code

try {
    processRequest();
} catch (const std::exception& e) {
    std::string errorId = generateErrorId();
    syslog(LOG_ERR, "Error %s: %s", errorId.c_str(), e.what());
    std::cout << "Internal Error. Reference: " << errorId << std::endl;
}

Fix Explanation

The vulnerable code prints exception details to output.The fix implements error tracking with unique IDs.Full error details are logged securely.Users see only a reference ID for support.

Need more help in preventing System Information Leakage?

Mobb supports fixing many forms of System Information Leakage vulnerabilities, and can mitigate your issues in batch.

Start now for free at app.mobb.ai

We'd love your feedback!

We're excited to hear your thoughts and ideas about fixing vulnerabilities.

Book a meeting or Contact us if you have any corrections, questions or suggestions. Start now for free at https://app.mobb.ai

PreviousRegex Missing Timeout NextMobb REST API Guide

Last updated 8 months ago

Was this helpful?