# Ss Leaks Detection

> Detect and analyze Server-Side Leaks (SS-Leaks) vulnerabilities in web applications. Use this skill whenever the user mentions server-side leaks, information disclosure, error message analysis, stack trace exposure, or wants to audit web applications for sensitive data leakage. This skill helps identify when server-side information is being improperly exposed to clients through error messages, debug output, or other response channels.

- Skill: `abelrguezr/ss-leaks-detection` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add abelrguezr/ss-leaks-detection`
- Raw SKILL.md: https://api.skillmd.com/api/skills/abelrguezr/ss-leaks-detection/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: abelrguezr (https://skillmd.com/u/abelrguezr)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/abelrguezr/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:

```bash
# 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:

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

### 3. Response Header Analysis

Examine HTTP headers for leaked information:

```bash
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:

```bash
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

```bash
# 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:

```bash
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:

```bash
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**
   ```python
   # Django
   DEBUG = False
   
   # Node.js
   process.env.NODE_ENV = 'production'
   ```

2. **Implement custom error pages**
   ```html
   <!-- 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
   # 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](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/05-Testing_for_Client-side_Caching/)
- [SS-Leaks Research](https://infosec.zeyu2001.com/2023/from-xs-leaks-to-ss-leaks)

## Example Workflow

### Step 1: Initial Reconnaissance

```bash
# 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

```bash
# 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

```bash
# 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
```python
# 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
```javascript
// 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
// 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.