Ss Leaks Detection

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

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.