cyberaudit-skill 3.0.5 → 3.0.7

package/skills/cyberaudit/api/types/WEBSOCKET.md

@@ -0,0 +1,75 @@
+# WebSocket API — Security Audit Guide
+
+## Unique Risks
+
+WebSockets are persistent, bidirectional, and often bypass traditional web security controls:
+- No per-request headers or cookies after initial handshake
+- WAFs struggle to inspect WebSocket traffic
+- Long-lived connections increase attack surface
+
+## Vulnerability Patterns
+
+### CRITICAL — No Authentication on Connect
+```javascript
+const ws = new WebSocket('wss://api.example.com/ws');
+// No auth token sent → anyone can connect
+```
+Fix: require JWT/token in connection header or first message.
+
+### CRITICAL — No Per-Message Authorization
+Connection is authenticated, but subsequent messages are not authorized.
+```
+User connects (valid token) → sends: {"action": "deleteUser", "target": 5}
+No check if user is admin or owns user 5.
+```
+Fix: authorize every message independently.
+
+### HIGH — No Input Validation
+```
+ws.send(JSON.stringify({ action: "query", sql: "DROP TABLE users" }));
+```
+Fix: validate all message content server-side. Never trust the client.
+
+### HIGH — Message Injection
+If messages are parsed or rendered unescaped:
+```
+ws.send(JSON.stringify({ action: "chat", message: "<script>...</script>" }));
+```
+Fix: escape output, strip HTML, validate message schema.
+
+### MEDIUM — No Rate Limiting
+Without per-connection rate limiting:
+- Message flood
+- Resource exhaustion
+- Data exfiltration via rapid queries
+Fix: rate limit per connection, close connections that exceed limits.
+
+### MEDIUM — No Origin Validation
+```javascript
+// Server accepts connections from any origin
+```
+An attacker's website can open WebSocket connections on behalf of logged-in users (CSWSH — Cross-Site WebSocket Hijacking).
+Fix: validate Origin header during handshake.
+
+### MEDIUM — No Connection Timeout
+Connections stay open indefinitely, consuming resources.
+Fix: implement idle timeout, absolute timeout, and heartbeat.
+
+### LOW — Unencrypted Connections
+```
+const ws = new WebSocket('ws://api.example.com/ws');
+```
+Fix: mandatory WSS (TLS) for all WebSocket connections.
+
+## WebSocket-Specific Best Practices
+
+1. Authenticate on connection (token in first message or header)
+2. Authorize every message independently
+3. Validate all message content and schema
+4. Rate limit per connection
+5. Validate Origin header during handshake
+6. Implement idle timeout and absolute timeout
+7. Use WSS exclusively (no plain WS)
+8. Limit message size
+9. Log all connections and disconnections
+10. Monitor for abnormal message patterns

package/skills/cyberaudit/api/vulnerabilities/BOLA.md

@@ -0,0 +1,41 @@
+# BOLA — Broken Object Level Authorization (API1:2023)
+
+OWASP API Security Top 10 — #1
+
+## Description
+
+BOLA (also known as IDOR) occurs when an API does not verify that the requesting user is authorized to access a specific object. The attacker simply changes an object ID in the request to access another user's data.
+
+## Detection
+
+```javascript
+// Vulnerable: no ownership check
+app.get('/api/orders/:id', (req, res) => {
+  const order = db.orders.findById(req.params.id);
+  res.json(order);
+});
+
+// Secure: ownership check
+app.get('/api/orders/:id', authenticate, (req, res) => {
+  const order = db.orders.findById(req.params.id);
+  if (order.userId !== req.user.id && !req.user.isAdmin) {
+    return res.status(403).json({ error: 'Forbidden' });
+  }
+  res.json(order);
+});
+```
+
+## Testing
+
+1. Create user A and user B
+2. Get A's auth token
+3. Access B's resources by changing IDs
+4. If successful → BOLA
+
+## Remediation
+
+1. Verify ownership on every object access
+2. Use UUIDs instead of sequential IDs
+3. Implement proper authorization middleware
+4. Log all access control failures
+5. Test with automated scanners

package/skills/cyberaudit/api/vulnerabilities/BOPLA.md

@@ -0,0 +1,38 @@
+# BOPLA — Broken Function Level Authorization (API2:2023)
+
+OWASP API Security Top 10 — #2
+
+## Description
+
+BOPLA occurs when an API exposes administrative or privileged functions that regular users can access. The attacker uses a regular user token to call admin endpoints.
+
+## Detection
+
+```javascript
+// Vulnerable: no admin check
+app.delete('/api/admin/users/:id', authenticate, (req, res) => {
+  db.users.delete(req.params.id);
+  res.status(204).send();
+});
+
+// Secure: role check
+app.delete('/api/admin/users/:id', authenticate, authorize('admin'), (req, res) => {
+  db.users.delete(req.params.id);
+  res.status(204).send();
+});
+```
+
+## Testing
+
+1. Create a regular user and an admin user
+2. Get regular user token
+3. Try all admin endpoints with regular token
+4. If any succeed → BOPLA
+
+## Remediation
+
+1. Implement role-based access control
+2. Verify authorization on every admin function
+3. Never rely on route-level auth alone
+4. Use function-level authorization decorators/middleware
+5. Test with least-privilege tokens

package/skills/cyberaudit/api/vulnerabilities/INVENTORY.md

@@ -0,0 +1,47 @@
+# API Inventory — Asset Management
+
+## Why It Matters
+
+APIs proliferate faster than documentation:
+- Shadow APIs (undeclared, unmonitored)
+- Deprecated versions (still running, weaker security)
+- Debug endpoints (exposed in production)
+- Misconfigured new endpoints
+
+## Discovery Techniques
+
+### Automated
+```bash
+# Subdomain enumeration
+subfinder -d example.com | httpx -silent
+
+# Path enumeration
+ffuf -w /usr/share/wordlists/api.txt -u https://api.example.com/FUZZ
+
+# Swagger/OpenAPI discovery
+ffuf -w endpoints.txt -u https://example.com/FUZZ/swagger.json
+```
+
+### Manual
+- Review JavaScript source for API calls
+- Check network tab in browser devtools
+- Monitor DNS records for subdomain patterns
+- Review job postings for tech stack hints
+
+### From Response Analysis
+- Look for API version headers
+- Check response structure differences
+- Identify internal hostnames or IPs
+
+## Inventory Checklist
+
+- [ ] All API subdomains mapped
+- [ ] All API paths discovered
+- [ ] HTTP methods tested per path
+- [ ] Content types tested per endpoint
+- [ ] Authentication status per endpoint
+- [ ] Version history documented
+- [ ] Deprecated endpoints flagged
+- [ ] Debug/test endpoints identified
+- [ ] Third-party API dependencies listed
+- [ ] Shadow APIs found and documented

package/skills/cyberaudit/api/vulnerabilities/RATE-LIMITING.md

@@ -0,0 +1,66 @@
+# Rate Limiting — API Abuse Prevention
+
+## Why It Matters
+
+Without rate limiting:
+- Brute force: 10,000 passwords tested in 1 minute
+- Enumeration: entire user database scraped
+- DoS: server overwhelmed by single client
+- Financial: costs from cloud API calls
+
+## Implementation Patterns
+
+### By IP
+```nginx
+limit_req_zone $binary_remote_addr zone=api:10m rate=30r/m;
+```
+Pros: simple, no client changes
+Cons: shared IPs (NAT), proxy bypass
+
+### By User ID
+```javascript
+// After authentication
+const key = `ratelimit:${req.user.id}`;
+const count = await redis.incr(key);
+if (count > 100) return 429;
+```
+Pros: accurate per user
+Cons: requires auth, unauthenticated = IP fallback
+
+### By Token
+```javascript
+const key = `ratelimit:${req.headers['x-api-key']}`;
+```
+Pros: works for service accounts
+Cons: tokens can be shared
+
+### Hybrid
+```javascript
+const key = req.user?.id || req.ip;
+```
+Best approach: authenticated users by ID, anonymous by IP.
+
+## Recommended Limits
+
+| Endpoint Type | Limit | Window |
+|--------------|-------|--------|
+| Login        | 5     | 15 min |
+| Registration | 3     | 1 hour |
+| Password Reset| 3    | 1 hour |
+| General API  | 100   | 1 min  |
+| File Upload  | 10    | 1 hour |
+| Search       | 30    | 1 min  |
+| WebSocket Msg| 60    | 1 min  |
+
+## Response
+
+```http
+HTTP/1.1 429 Too Many Requests
+Retry-After: 900
+Content-Type: application/json
+
+{
+  "error": "rate_limit_exceeded",
+  "retry_after_seconds": 900
+}
+```

package/skills/cyberaudit/api/vulnerabilities/THIRD-PARTY-API.md

@@ -0,0 +1,57 @@
+# Third-Party API Security
+
+## The Trust Problem
+
+Your security depends on APIs you do not control:
+- Payment gateways, auth providers, SaaS integrations
+- Data enrichment services, analytics, monitoring
+- AI/ML APIs, cloud functions, webhooks
+
+## Risk Categories
+
+### 1. Data Exposure
+When your app sends data to third parties:
+  - Are they encrypting at rest?
+  - Do they log sensitive data?
+  - What happens to data on account deletion?
+  - Do they sell or share data?
+
+### 2. Supply Chain Attack
+When third-party API is compromised:
+  - Attacker controls responses
+  - Malicious data injected downstream
+  - Credential theft from third-party breach
+
+### 3. Webhook Abuse
+When third party calls your endpoint:
+  - Spoofed webhook calls
+  - Replay attacks
+  - Payload manipulation
+  - Webhook endpoint DDoS
+
+## Remediation
+
+### Outgoing Calls
+1. Enforce HTTPS with certificate validation
+2. Set timeouts on all requests
+3. Implement retry logic with exponential backoff
+4. Treat all external data as untrusted
+5. Validate response schemas
+6. Log all external calls for audit
+7. Store credentials in a secrets manager
+
+### Incoming Webhooks
+1. Verify webhook signatures (HMAC)
+2. Validate payload schema
+3. Use a webhook secret per integration
+4. Implement replay protection (timestamp + nonce)
+5. Rate limit per webhook source
+6. IP allowlist where possible
+7. Return 200 quickly, process async
+
+### Monitoring
+1. Monitor for unusual third-party response patterns
+2. Alert on third-party SLA breaches
+3. Review third-party security postures regularly
+4. Test third-party failure modes (graceful degradation)
+5. Keep third-party dependencies minimal

package/skills/cyberaudit/reports/REPORT-TEMPLATE-API.md

@@ -0,0 +1,89 @@
+# API Security Audit Report
+
+**Target:** [API Name/URL]
+**Date:** [YYYY-MM-DD]
+**Auditor:** [Name]
+**Version:** [API Version]
+
+## Executive Summary
+
+[Brief overview: scope, critical findings, overall risk level]
+
+**Risk Level:** [Critical / High / Medium / Low]
+**Endpoints Tested:** [X]
+**Vulnerabilities Found:** [X]
+
+## Scope
+
+### In Scope
+- [Endpoint 1]
+- [Endpoint 2]
+- [Authentication mechanism]
+- [API version]
+
+### Out of Scope
+- [Anything excluded]
+
+## Methodology
+
+- [X] Discovery & Mapping
+- [X] Authentication Testing
+- [X] Authorization Testing (BOLA/BOPLA)
+- [X] Input Validation
+- [X] Rate Limiting
+- [X] Data Exposure
+- [X] Configuration Review
+
+## Findings
+
+### CRITICAL
+| # | Finding | Endpoint | Impact | Remediation |
+|---|---------|----------|--------|-------------|
+| 1 | [Title] | [URL] | [Impact] | [Fix] |
+| 2 | [Title] | [URL] | [Impact] | [Fix] |
+
+### HIGH
+| # | Finding | Endpoint | Impact | Remediation |
+|---|---------|----------|--------|-------------|
+| 3 | [Title] | [URL] | [Impact] | [Fix] |
+
+### MEDIUM
+| # | Finding | Endpoint | Impact | Remediation |
+|---|---------|----------|--------|-------------|
+| 4 | [Title] | [URL] | [Impact] | [Fix] |
+
+## Detailed Findings
+
+### Finding 1: [Title] (Critical)
+**Endpoint:** [URL]
+**Description:** [Detailed description]
+**Request:**
+```http
+GET /api/...
+```
+**Response:**
+```http
+HTTP/1.1 200 OK
+{ ... }
+```
+**Impact:** [Business/technical impact]
+**Remediation:** [Step-by-step fix]
+**CVSS:** [Score]
+
+### Finding 2: [Title]
+...
+
+## Recommendations
+
+1. [Priority action]
+2. [Priority action]
+3. [Priority action]
+
+## Appendix
+
+### Tools Used
+- [Tool/version]
+
+### Reference
+- OWASP API Security Top 10 (2023)
+- [Other references]