169 lines
5.1 KiB
Markdown
169 lines
5.1 KiB
Markdown
---
|
|
name: security-best-practices
|
|
description: Apply security hardening, input validation, and protection measures across all operations
|
|
---
|
|
|
|
## When to use
|
|
Use when the user asks to:
|
|
- Secure an application or system
|
|
- Audit code for vulnerabilities
|
|
- Set up authentication/authorization
|
|
- Harden configurations
|
|
- Perform security reviews
|
|
- Handle secrets and credentials
|
|
|
|
## Core Principles
|
|
|
|
### 1. Defense in Depth
|
|
Apply multiple layers of security:
|
|
- Input validation
|
|
- Authentication
|
|
- Authorization
|
|
- Output encoding
|
|
- Encryption
|
|
- Auditing
|
|
|
|
### 2. Least Privilege
|
|
Agents/tools should have only the permissions they need:
|
|
- File access: restrict to specific directories
|
|
- Network: allow only required endpoints
|
|
- Tools: disable dangerous ones when not needed
|
|
|
|
### 3. Fail Securely
|
|
Errors should not reveal sensitive information:
|
|
- Generic error messages to users
|
|
- Detailed errors only in logs (protected)
|
|
- Secure defaults (deny by default)
|
|
|
|
## Security Checklist
|
|
|
|
### Input Validation
|
|
- [ ] Validate all user inputs (type, length, format, range)
|
|
- [ ] Sanitize to remove/escape dangerous characters
|
|
- [ ] Use parameterized queries (no string concatenation)
|
|
- [ ] Reject unexpected values early
|
|
|
|
### Authentication & Authorization
|
|
- [ ] Use strong, salted password hashing (bcrypt, Argon2)
|
|
- [ ] Implement multi-factor authentication for sensitive operations
|
|
- [ ] Enforce least privilege (RBAC/ABAC)
|
|
- [ ] Use short-lived tokens, rotate regularly
|
|
- [ ] Validate permissions on every request
|
|
|
|
### Secrets Management
|
|
- [ ] Never hardcode secrets in source code
|
|
- [ ] Use environment variables or secret vaults
|
|
- [ ] Rotate credentials regularly
|
|
- [ ] Different secrets per environment (dev/staging/prod)
|
|
- [ ] Don't log secrets (redact from logs)
|
|
|
|
### Data Protection
|
|
- [ ] Encrypt sensitive data at rest (AES-256)
|
|
- [ ] Use TLS 1.2+ for data in transit
|
|
- [ ] Secure backups (encrypted, access-controlled)
|
|
- [ ] Anonymize/pseudonymize PII when possible
|
|
|
|
### Output Encoding
|
|
- [ ] Encode data before rendering (HTML escape, SQL escape, shell escape)
|
|
- [ ] Use templating engines with auto-escaping
|
|
- [ ] Content Security Policy (CSP) headers for web apps
|
|
|
|
### Dependency Security
|
|
- [ ] Regularly audit dependencies for CVEs
|
|
- [ ] Use minimal dependencies
|
|
- [ ] Pin versions (avoid floating ranges)
|
|
- [ ] Update promptly when vulnerabilities disclosed
|
|
|
|
## Code Review Security Points
|
|
|
|
Review code for:
|
|
- **SQL injection**: raw queries with string concatenation
|
|
- **XSS**: unescaped output in HTML/JS
|
|
- **CSRF**: missing tokens on state-changing requests
|
|
- **Path traversal**: user-controlled file paths without validation
|
|
- **Insecure deserialization**: untrusted data → object creation
|
|
- **Hardcoded secrets**: passwords, API keys in source
|
|
- **Weak crypto**: MD5, SHA1, custom algorithms, hardcoded keys
|
|
|
|
## Configuration Hardening
|
|
|
|
### File permissions
|
|
```bash
|
|
chmod 600 ~/.openclaw/credentials/*.json # Owner read/write only
|
|
chmod 700 ~/.openclaw/workspace # Restrict workspace
|
|
```
|
|
|
|
### Network security
|
|
- Firewall: allow only necessary ports
|
|
- VPN for remote access
|
|
- Disable unnecessary services
|
|
|
|
### Audit logging
|
|
Log all security events:
|
|
- Authentication attempts (success/failure)
|
|
- Authorization failures
|
|
- Configuration changes
|
|
- Data access (especially PII)
|
|
Include: timestamp, user, action, IP, outcome
|
|
|
|
## Incident Response
|
|
|
|
If a breach is suspected:
|
|
1. **Isolate**: Cut off network access if possible
|
|
2. **Preserve logs**: Don't delete; copy for analysis
|
|
3. **Assess scope**: Which systems/data affected?
|
|
4. **Notify**: Follow disclosure procedures
|
|
5. **Remediate**: Patch vulnerabilities, rotate credentials
|
|
6. **Post-mortem**: Document lessons learned
|
|
|
|
## Tools for Security Audit
|
|
|
|
Use OpenClaw skills:
|
|
- `security-review`: Automated code security scan
|
|
- `systematic-debugging`: Identify root cause of vulnerabilities
|
|
- `code-quality-gate`: Enforce security standards
|
|
|
|
External tools:
|
|
- OWASP ZAP / Burp Suite (web scanning)
|
|
- Trivy / Grype (dependency scanning)
|
|
- Bandit / Semgrep (SAST)
|
|
- sqlmap (SQL injection testing)
|
|
|
|
## Examples
|
|
|
|
<Good>
|
|
Database query with parameterized statement:
|
|
```python
|
|
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))
|
|
```
|
|
</Good>
|
|
|
|
<Bad>
|
|
```python
|
|
query = f"SELECT * FROM users WHERE email = '{email}'"
|
|
cursor.execute(query) # SQL injection vulnerability
|
|
```
|
|
</Bad>
|
|
|
|
## Compliance Considerations
|
|
|
|
Depending on industry:
|
|
- **GDPR**: Data protection, privacy by design, breach notification
|
|
- **PCI DSS**: Payment card data handling
|
|
- **HIPAA**: Healthcare data encryption and access logs
|
|
- **SOC 2**: Security controls and audit trails
|
|
|
|
## Verification Checklist
|
|
- [ ] All user inputs validated and sanitized
|
|
- [ ] No hardcoded secrets in codebase
|
|
- [ ] Secrets stored securely (env vars, vault)
|
|
- [ ] Database queries use parameterized statements
|
|
- [ ] Output properly encoded for context (HTML, SQL, shell)
|
|
- [ ] Authentication strong (bcrypt, 2FA)
|
|
- [ ] Authorization checks on all protected actions
|
|
- [ ] Sensitive data encrypted at rest and in transit
|
|
- [ ] Audit logs capture security events
|
|
- [ ] Dependencies up-to-date with no known CVEs
|
|
- [ ] Regular security scans performed
|
|
- [ ] Incident response plan documented
|