SS-Leaks Detection and Analysis

A skill for identifying and analyzing Server-Side Leaks vulnerabilities in web applications.

What are SS-Leaks?

Server-Side Leaks (SS-Leaks) occur when a web application inadvertently exposes sensitive server-side information to clients. Unlike XSS (Cross-Site Scripting) which executes client-side code, SS-Leaks reveal information about:

• Server configuration and environment
• Database structure and queries
• File system paths
• Authentication tokens and credentials
• Stack traces and error details
• Internal network topology

Detection Methods

1. Error Message Analysis

Trigger errors to observe what information is revealed:

# Test with malformed input
curl -X POST "https://target.com/api/endpoint" -d "invalid=payload"

# Test with SQL injection patterns
curl "https://target.com/search?q=' OR 1=1--"

# Test with null bytes and special characters
curl "https://target.com/file?name=test%00.txt"

2. Debug Endpoint Discovery

Check for exposed debug interfaces:

# Common debug paths
/debug
/debugger
/__debug__
/phpinfo.php
/info.php
/actuator/health
/actuator/env

3. Response Header Analysis

Examine HTTP headers for leaked information:

curl -I https://target.com | grep -iE "(server|x-powered-by|x-debug|set-cookie)"

4. Error Page Testing

Trigger 404, 500, and other error pages to see what's exposed:

curl https://target.com/nonexistent-page-12345
curl https://target.com/api/undefined-endpoint

Common SS-Leak Patterns

Pattern 1: Stack Trace Exposure

What to look for:

• Full stack traces in error responses
• File paths and line numbers
• Internal class/method names

Example:

Error: NullPointerException at com.example.service.UserService.getUser(UserService.java:42)
    at com.example.controller.UserController.handleRequest(UserController.java:15)

Pattern 2: Database Query Leaks

What to look for:

• SQL queries in error messages
• Database schema information
• Table and column names

Example:

SQL Error: Unknown column 'user_id' in 'field list'
Query: SELECT * FROM users WHERE id = ?

Pattern 3: Configuration Disclosure

What to look for:

• Environment variables
• API keys and secrets
• Database connection strings
• Server paths

Example:

DB_HOST=production-db.internal.corp
DB_USER=admin
DB_PASS=********
API_KEY=sk_live_abc123...

Pattern 4: Framework Debug Output

What to look for:

• Django debug pages
• Rails exception reports
• PHP error displays
• Node.js stack traces

Exploitation Techniques

Technique 1: Error-Based Information Gathering

1. Send malformed requests to trigger errors
2. Parse error responses for sensitive data
3. Map application structure from error details

# Automated error triggering
for param in $(seq 1 100); do
  curl -s "https://target.com/api?id=$param" | grep -i "error\|exception\|trace"
done

Technique 2: Parameter Pollution

Test how the application handles unexpected parameters:

curl "https://target.com/api?debug=true&verbose=1&show_errors=1"
curl "https://target.com/api?_=debug&_=verbose"

Technique 3: Content-Type Manipulation

Try different content types to trigger different error handlers:

curl -H "Content-Type: application/xml" -d "<invalid>" https://target.com/api
curl -H "Content-Type: application/json" -d "{invalid}" https://target.com/api

Remediation Guidance

Immediate Actions

1. Disable debug mode in production

   # Django
   DEBUG = False
   
   # Node.js
   process.env.NODE_ENV = 'production'
   

2. Implement custom error pages

   <!-- Generic error page without technical details -->
   <h1>Something went wrong</h1>
   <p>Please try again later or contact support.</p>
   

3. Sanitize error responses

   # Python example
   def handle_exception(e):
       log_error(e)  # Log full error internally
       return "An error occurred"  # Generic message to user
   

Long-term Improvements

1. Implement proper logging

   • Log detailed errors server-side
   • Show generic messages to users
   • Use log aggregation tools

2. Security headers

   X-Content-Type-Options: nosniff
   X-Frame-Options: DENY
   X-XSS-Protection: 1; mode=block
   

3. Regular security audits

   • Automated scanning for information disclosure
   • Manual review of error handling
   • Penetration testing

Testing Checklist

• Test all error conditions (404, 500, 403, etc.)
• Verify debug endpoints are disabled
• Check response headers for sensitive info
• Test with malformed input across all endpoints
• Review error logs for information leakage
• Validate custom error pages are in place
• Confirm no stack traces in production responses
• Check for exposed configuration in responses

Tools and Resources

Automated Scanners

• Nuclei: Template-based vulnerability scanner
• OWASP ZAP: Web application security scanner
• Burp Suite: Professional security testing tool

Manual Testing

• curl: HTTP client for testing
• Browser DevTools: Inspect network responses
• Custom scripts: Tailored error triggering

References

• OWASP Information Disclosure
• SS-Leaks Research

Example Workflow

Step 1: Initial Reconnaissance

# Map the application
curl -s https://target.com | grep -i "error\|debug\|trace"

# Check common debug paths
for path in /debug /__debug__/ /phpinfo.php /info.php; do
  curl -s -o /dev/null -w "%{http_code}" https://target.com$path
done

Step 2: Error Triggering

# Test various error conditions
curl "https://target.com/api?invalid=1"
curl "https://target.com/search?q='"
curl "https://target.com/file?name=../../../etc/passwd"

Step 3: Analysis

# Save and analyze responses
curl "https://target.com/api?error=1" > error_response.txt
grep -i "password\|secret\|key\|token\|path\|trace" error_response.txt

Step 4: Reporting

Document findings with:

• Vulnerability type
• Affected endpoints
• Evidence (screenshots, response samples)
• Risk assessment
• Remediation recommendations

Risk Assessment

Severity	Criteria
Critical	Exposes credentials, API keys, or internal network info
High	Reveals database structure, file paths, or stack traces
Medium	Shows framework version, server configuration
Low	Generic error messages with minimal info

Best Practices

1. Never trust client input - Always validate and sanitize
2. Log internally, show generically - Keep detailed logs server-side
3. Use environment variables - Never hardcode secrets
4. Implement rate limiting - Prevent automated error probing
5. Regular updates - Keep frameworks and dependencies patched
6. Security training - Educate developers on information disclosure risks

Common Frameworks

Django

# settings.py
DEBUG = False
ALLOWED_HOSTS = ['yourdomain.com']

# Custom error handlers
from django.conf.urls import handler404, handler500
handler404 = 'yourapp.views.custom_404'
handler500 = 'yourapp.views.custom_500'

Node.js/Express

// Production error handler
app.use((err, req, res, next) => {
  console.error(err.stack); // Log internally
  res.status(500).json({ error: 'Internal server error' }); // Generic response
});

PHP

// php.ini for production
display_errors = Off
log_errors = On
error_log = /var/log/php_errors.log

Conclusion

SS-Leaks are a common but often overlooked vulnerability class. By systematically testing for information disclosure and implementing proper error handling, organizations can significantly reduce their attack surface. Remember: what you don't know can't be exploited, but what you expose can be weaponized.

Always test in a controlled environment and obtain proper authorization before scanning any web application.