How to Inadvertently Allow HTTP 500 Errors from Leaking App Internal Info

By /

Listen to this Post

Featured Image
When an application returns an HTTP 500 error, it can unintentionally expose sensitive internal information, such as database schemas, connection strings, file paths, and even snippets of source code. This leakage occurs when developers or administrators misconfigure security policies, allowing detailed error messages to reach end-users—including potential attackers.

The Incident

A misconfigured F5 ASM (Application Security Manager) allowed HTTP 500 errors to bypass security policies. Instead of blocking these errors, the system was set to permit them, exposing stack traces and internal application details.

Example of Faulty Code (C / .NET)

public IActionResult Index() 
{ 
var model = "This is a good page"; 
Response.StatusCode = 500; // Should be 200 
return View("Index", model); 
}

The correct approach should have been:

public IActionResult Index() 
{ 
try 
{ 
var model = "This is a good page"; 
return View("Index", model); // Returns HTTP 200 
} 
catch (Exception ex) 
{ 
Response.StatusCode = 500; // Only set 500 on actual errors 
return View("Error"); 
} 
}

You Should Know: Preventing Information Leakage

  1. Configure Web Servers to Suppress Detailed Errors
    • IIS (web.config):
      <configuration> 
<system.web> 
<customErrors mode="RemoteOnly" defaultRedirect="Error.html" /> 
</system.web> 
<system.webServer> 
<httpErrors errorMode="DetailedLocalOnly" /> 
</system.webServer> 
</configuration>
  • Apache (httpd.conf):
    ServerSignature Off 
ErrorDocument 500 /custom-error.html

  • Nginx (nginx.conf):

    server { 
error_page 500 /custom-error.html; 
location = /custom-error.html { 
internal; 
} 
}

2. WAF (Web Application Firewall) Best Practices

  • F5 ASM Rule: Ensure HTTP 500 responses are blocked by default.
  • ModSecurity Rule:
    SecRule RESPONSE_STATUS "@streq 500" "id:1000,phase:3,deny,msg:'Internal Server Error Exposure'"

3. Logging & Monitoring Suspicious Requests

  • Linux Command to Monitor 500 Errors:
    tail -f /var/log/nginx/error.log | grep "500"
  • Windows PowerShell Command:
    Get-EventLog -LogName Application -EntryType Error | Where-Object { $_.Message -like "500" }

4. Automated Testing for Error Handling

  • Using cURL to Test:
    curl -I http://example.com/force-error
  • Using OWASP ZAP for Security Testing:
    zap-cli quick-scan --spider -o "-config scanner.attackStrength=HIGH" http://example.com

What Undercode Say

Misconfigured error handling is a common security pitfall. Attackers actively probe applications for HTTP 500 responses to extract sensitive data. Always:
– Enforce strict WAF rules to block raw error responses.
– Implement custom error pages.
– Log and monitor server-side errors.
– Regularly audit security policies to prevent accidental exposure.

Expected Output:

✔ Block HTTP 500 responses in WAF policies.

✔ Replace stack traces with generic error messages.

✔ Monitor logs for repeated 500 errors indicating probing attempts.

Prediction

As web applications grow more complex, misconfigurations leading to data leaks will remain a top attack vector. Automated security tools and stricter compliance checks will become essential in mitigating these risks.

Relevant Course: F5 ASM Security Training (Launching in 30 days)

IT/Security Reporter URL:

Reported By: Grahammattingley How – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

Join Our Cyber World:

💬 Whatsapp | 💬 Telegram

Related Posts: