From 057d7b5246b6097bd36012083eb87936efbbdb36 Mon Sep 17 00:00:00 2001 From: sandiyochristan Date: Thu, 6 Aug 2026 21:47:00 +0530 Subject: [PATCH 1/3] feat(skills): add safe-mode crawling guard and network-layer protocol skills Add three new skills to expand agent capabilities: - custom/safe_mode_crawling: Systematic guard against destructive side effects when agents autonomously crawl and test targets. Covers HTTP method risk heuristics, high-risk endpoint pattern recognition, destructive operation detection, idempotency checks, and a decision framework for when to stop and surface to operator. - protocols/ssl_tls_analysis: SSL/TLS configuration assessment covering cipher suite enumeration, certificate chain validation, protocol downgrade attacks (POODLE, BEAST), and known implementation vulnerabilities (Heartbleed, ROBOT, DROWN, CCS Injection). - protocols/smb_netbios_enumeration: SMB/NetBIOS enumeration covering null session testing, share discovery, user enumeration, message signing assessment, and known protocol vulnerabilities (EternalBlue, SMBGhost). All skills follow existing structure: YAML frontmatter with name and description, practical examples with working commands, validation methods, false positive guidance, and CVSS context. All commands reference tools available in the Strix sandbox (nmap, openssl, nuclei). No Python code changes. No existing skill modifications. --- strix/skills/custom/safe_mode_crawling.md | 140 +++++++++++++++ .../protocols/smb_netbios_enumeration.md | 110 ++++++++++++ strix/skills/protocols/ssl_tls_analysis.md | 170 ++++++++++++++++++ 3 files changed, 420 insertions(+) create mode 100644 strix/skills/custom/safe_mode_crawling.md create mode 100644 strix/skills/protocols/smb_netbios_enumeration.md create mode 100644 strix/skills/protocols/ssl_tls_analysis.md diff --git a/strix/skills/custom/safe_mode_crawling.md b/strix/skills/custom/safe_mode_crawling.md new file mode 100644 index 00000000..3282c30b --- /dev/null +++ b/strix/skills/custom/safe_mode_crawling.md @@ -0,0 +1,140 @@ +--- +name: safe-mode-crawling +description: Systematic guard against destructive side effects when crawling and testing — recognize irreversible operations before invoking them, prefer read-only reconnaissance, and surface high-risk actions to the operator +--- + +# Safe-Mode Crawling Guard + +Autonomous agents that drive browsers, submit forms, and fire HTTP requests can cause real damage to target environments — deleting data, triggering payments, sending emails, or mutating production state. This skill teaches agents to recognize destructive operations **before** executing them, prefer read-only reconnaissance, and escalate to the operator when an action's side effects are uncertain. + +## Why This Matters + +An agent pointed at a staging or production application with admin credentials can: +- `DELETE` database records, user accounts, or storage objects +- Trigger email/SMS notifications to real users +- Process payments or refunds through payment gateways +- Reset passwords, revoke API keys, or invalidate sessions +- Execute bulk operations (purge caches, drop tables, wipe logs) +- Submit forms that create real orders, tickets, or support requests + +These are not hypothetical — they are the natural consequence of an autonomous agent exploring admin panels and API endpoints without constraint. + +## Recognizing Destructive Operations + +### HTTP Method Heuristics + +| Method | Default Risk | Notes | +|--------|-------------|-------| +| `GET`, `HEAD`, `OPTIONS` | 🟢 Safe | Read-only by specification; safe to explore | +| `POST` | 🟡 Caution | Creates resources; may trigger side effects | +| `PUT`, `PATCH` | 🟡 Caution | Modifies existing resources | +| `DELETE` | 🔴 High Risk | Removes resources; often irreversible | + +**Exception:** Some APIs use `POST` for destructive operations (e.g., `POST /api/users/delete`, `POST /admin/purge-cache`). Always check the endpoint semantics, not just the HTTP method. + +### High-Risk Endpoint Patterns + +Watch for these patterns in URLs, form actions, and API routes: + +**Deletion / Removal** +- `/delete`, `/remove`, `/destroy`, `/purge`, `/wipe`, `/drop` +- `/api/*/delete`, `/admin/*/remove` +- Bulk variants: `/bulk-delete`, `/delete-all`, `/clear-all` + +**State Mutation** +- `/reset`, `/revoke`, `/invalidate`, `/deactivate`, `/disable` +- `/password/reset`, `/api-keys/revoke`, `/sessions/invalidate` + +**Financial / Transactional** +- `/payment`, `/charge`, `/refund`, `/purchase`, `/checkout` +- `/subscribe`, `/cancel-subscription`, `/billing` + +**Communication Triggers** +- `/send`, `/notify`, `/email`, `/sms`, `/webhook/trigger` +- `/invite`, `/broadcast`, `/publish` + +**Admin / System** +- `/admin/*/execute`, `/admin/*/run` +- `/migrate`, `/seed`, `/truncate`, `/backup/delete` + +### Form Analysis + +Before submitting any form, check: +1. **Action URL** — does it match a high-risk pattern above? +2. **Submit button text** — "Delete", "Remove", "Reset", "Send", "Pay", "Confirm" +3. **Confirmation dialogs** — JavaScript confirms are a signal the app considers the action risky +4. **Hidden fields** — `_method=DELETE`, `action=destroy`, `confirm=true` +5. **CSRF tokens** — presence indicates state-changing operation + +## Decision Framework + +``` +Is this action read-only (GET/HEAD/OPTIONS)? +├── YES → Proceed +└── NO → Does the endpoint match a high-risk pattern? + ├── YES → STOP. Log the finding. Do NOT execute. + │ Surface to operator with: URL, method, parameters, and risk assessment. + └── NO → Is this a standard form submission / API call for testing? + ├── YES → Check: can this action be reversed? + │ ├── YES (e.g., create a test user that can be deleted) → Proceed with caution + │ └── NO or UNCERTAIN → STOP. Surface to operator. + └── NO → Proceed with standard testing +``` + +## Operational Rules + +### Before Any Mutating Request + +1. **Identify the operation** — What does this endpoint actually do? Read the endpoint name, form labels, button text, and API documentation if available. +2. **Assess reversibility** — Can the action be undone? Creating a test record is usually reversible; deleting a production record is not. +3. **Check scope** — Is this a single-resource operation or a bulk operation? Bulk operations are categorically higher risk. +4. **Prefer read-only alternatives** — Can the same vulnerability be demonstrated with a GET-based information disclosure instead of a destructive POST? + +### Idempotency Checks + +Before repeating any mutating request: +- Has this exact request already been sent in this session? +- Did the first attempt succeed? If so, do not retry — the side effect has already occurred. +- For test data creation: use unique, identifiable values (e.g., `strix_test_`) so cleanup is possible. + +### When to Stop and Surface + +**Always stop and report to the operator when:** +- The action would delete or modify real user data +- The action would trigger external communication (email, SMS, webhook) +- The action involves payment processing or financial transactions +- The action would modify authentication state (password reset, key revocation) +- The action is a bulk/batch operation affecting multiple resources +- You are uncertain about the side effects + +**Format for surfacing:** +``` +⚠️ HIGH-RISK ACTION DETECTED +Endpoint: DELETE /api/v1/users/42 +Method: DELETE +Risk: Irreversible deletion of user account +Context: Found during IDOR testing on user management panel +Recommendation: Test with a disposable test account instead, or confirm with operator +``` + +## Validation + +1. Demonstrate that the safe-mode guard prevents execution of destructive operations by showing the agent correctly identifies and skips high-risk endpoints +2. Confirm that read-only testing paths still discover the vulnerability (e.g., proving IDOR via GET before attempting DELETE) +3. Document any high-risk operations that were surfaced to the operator instead of executed +4. Verify that test data created during scanning uses identifiable prefixes for cleanup + +## Integration with Other Skills + +- **IDOR testing** — Prove authorization bypass with GET requests first; only attempt state-changing operations with disposable test data +- **CSRF testing** — Demonstrate the vulnerability exists without actually triggering the destructive action on real data +- **Business logic** — Map the workflow read-only before attempting to exploit state transitions +- **Authentication/JWT** — Test token manipulation without invalidating real sessions + +## Pro Tips + +1. Start every engagement by mapping the application **read-only** — enumerate endpoints, understand data model, identify admin functions — before attempting any writes +2. If the target has a test/sandbox mode, prefer it over production endpoints +3. When testing APIs, use obviously fake data (`test@strix-pentest.example`, `strix_test_*`) so the operator can identify and clean up agent-created records +4. Document every mutating request you *choose not to send* — this is valuable information for the operator and demonstrates responsible testing methodology +5. A vulnerability that could cause damage is still a valid finding even if you don't trigger the damage — describe the attack path, show the preconditions are met, and let the operator decide on full exploitation diff --git a/strix/skills/protocols/smb_netbios_enumeration.md b/strix/skills/protocols/smb_netbios_enumeration.md new file mode 100644 index 00000000..947ca168 --- /dev/null +++ b/strix/skills/protocols/smb_netbios_enumeration.md @@ -0,0 +1,110 @@ +--- +name: smb-netbios-enumeration +description: SMB/NetBIOS enumeration covering null sessions, share discovery, user enumeration, and known protocol vulnerabilities (e.g., EternalBlue, SMBGhost) +--- + +# SMB/NetBIOS Enumeration + +Server Message Block (SMB) and NetBIOS are critical attack surfaces on Windows networks (and Samba on *nix). Misconfigured SMB can expose file shares, user lists, password policies, and domain information. Vulnerable SMB versions (SMBv1) or unpatched SMBv3 implementations can lead to unauthenticated remote code execution. + +## Attack Surface + +**Scope** +- TCP 445 (Direct SMB over TCP) +- TCP 139 (SMB over NetBIOS) +- UDP 137 (NetBIOS Name Service) +- UDP 138 (NetBIOS Datagram Service) + +**What to Test** +- Authentication requirements (Null session, Guest access) +- Share permissions (Read/Write access on IPC$, C$, ADMIN$, custom shares) +- Information disclosure (Users, groups, domain info, password policies) +- Vulnerability to known RCE/DoS flaws (MS17-010, CVE-2020-0796) +- Message signing configuration (SMB relay susceptibility) + +## Key Vulnerabilities + +### Null Sessions and Guest Access + +**Anonymous Enumeration** +Historically, Windows allowed "Null Sessions" (anonymous access without credentials) to IPC$. This permits enumeration of users, groups, shares, and password policies. While restricted in modern Windows versions by default, misconfigurations or legacy systems still exhibit this. + +**Guest Access** +The built-in Guest account might be enabled and have access to shares, leading to sensitive data exposure. + +### Protocol Vulnerabilities + +| Vuln | CVE | Description | Test | +|------|-----|-------------|------| +| EternalBlue | MS17-010 / CVE-2017-0144 | RCE in SMBv1. Exploited widely (WannaCry). | `nmap --script smb-vuln-ms17-010 -p 445 ` | +| SMBGhost / CoronaBlue | CVE-2020-0796 | RCE/DoS in SMBv3.1.1 compression. | `nmap --script smb-vuln-cve-2020-0796 -p 445 ` | +| SMBleed | CVE-2020-1206 | Information disclosure in SMBv3.1.1 decompression. | Often tested alongside SMBGhost. | + +### SMB Message Signing + +**SMB Relay Attacks** +If SMB signing is not required (`Message signing enabled but not required`), the server is vulnerable to SMB relay attacks. An attacker can intercept NTLM authentication traffic and relay it to the server to gain unauthorized access. + +## Testing Methodology + +### 1. Protocol and Configuration Check + +```bash +# General SMB discovery and signing check +nmap -n -Pn -p 139,445 --script smb-os-discovery,smb-security-mode +``` + +### 2. Null Session and Share Enumeration + +```bash +# Using smbclient (anonymous) +smbclient -N -L // + +# Using enum4linux (comprehensive enumeration) +enum4linux -a + +# Using nmap for shares +nmap -n -Pn -p 445 --script smb-enum-shares +``` + +### 3. Vulnerability Scanning + +```bash +# Check for known SMB vulnerabilities +nmap -n -Pn -p 445 --script "smb-vuln-*" +``` + +## Validation + +1. **Demonstrate Access** — Show the output of an anonymous/guest connection listing shares or reading a file. +2. **Prove Enumeration** — Extract valid usernames or password policy details using a null session. +3. **Confirm Vulnerabilities** — Run specific vulnerability checks (e.g., MS17-010) and verify the output indicates vulnerability. + +## False Positives + +- **Firewall Filtering** — Ports appear open, but deep inspection or scripts fail due to intermediate firewalls. +- **SMB Signing "Enabled"** — The service might support signing, but if it's not *required*, it's still vulnerable to relay. Pay attention to the exact wording. +- **Honeypots** — Deliberately vulnerable-looking SMB services that trap scanners. + +## CVSS Context + +| Finding | Typical CVSS | Rationale | +|---------|-------------|-----------| +| EternalBlue (MS17-010) | 9.3 (Critical) | Remote Code Execution | +| SMBGhost (CVE-2020-0796) | 10.0 (Critical) | Remote Code Execution | +| Anonymous Share Access (Read/Write) | 7.5 - 9.0 (High/Critical) | Data exposure or modification depending on share content | +| Null Session User Enumeration | 5.3 (Medium) | Information disclosure aiding further attacks | +| SMB Signing Not Required | 5.3 (Medium) | Enables relay attacks, requiring adjacent network position | + +## Pro Tips + +1. When testing shares, look for configuration files, backups, and scripts that might contain hardcoded credentials. +2. `IPC$` is for inter-process communication; you can't typically browse files on it, but it's used for enumeration. +3. If anonymous access fails, always test with any valid credentials you've obtained, no matter how low-privileged. + +## Tooling + +- **nmap** — Essential for discovery and vulnerability checks (`smb-os-discovery`, `smb-enum-shares`, `smb-vuln-*`). +- **smbclient** — Command-line SMB client, excellent for testing connectivity and manual browsing. +- **enum4linux** — Comprehensive tool for extracting information from Windows and Samba hosts. +- **CrackMapExec / NetExec** — Advanced post-exploitation and enumeration tools (if available in the environment). diff --git a/strix/skills/protocols/ssl_tls_analysis.md b/strix/skills/protocols/ssl_tls_analysis.md new file mode 100644 index 00000000..01d9f86e --- /dev/null +++ b/strix/skills/protocols/ssl_tls_analysis.md @@ -0,0 +1,170 @@ +--- +name: ssl-tls-analysis +description: SSL/TLS configuration assessment covering cipher suite enumeration, certificate chain validation, protocol downgrade attacks, and known implementation vulnerabilities +--- + +# SSL/TLS Configuration Analysis + +SSL/TLS misconfigurations remain among the most common network-layer findings. Weak cipher suites, expired certificates, protocol downgrade vulnerabilities, and implementation flaws expose encrypted communications to interception, decryption, and man-in-the-middle attacks. + +## Attack Surface + +**Scope** +- Any service exposing TLS: HTTPS (443), SMTPS (465/587), IMAPS (993), LDAPS (636), database TLS, custom ports +- Load balancers, reverse proxies, CDN edge nodes (each may have independent TLS configuration) +- Internal services using self-signed or improperly chained certificates + +**What to Test** +- Protocol versions supported (SSLv3, TLS 1.0/1.1/1.2/1.3) +- Cipher suite selection and ordering +- Certificate validity, chain completeness, and trust anchoring +- Key exchange strength and forward secrecy +- Known implementation vulnerabilities (BEAST, POODLE, Heartbleed, ROBOT, etc.) +- HSTS, certificate transparency, OCSP stapling configuration + +## Key Vulnerabilities + +### Protocol Downgrade + +**Legacy Protocol Support** +- SSLv3 → POODLE attack (CVE-2014-3566); padding oracle on CBC ciphers +- TLS 1.0 → BEAST attack (CVE-2011-3389); CBC IV predictability +- TLS 1.1 → No known critical attacks but lacks modern security features; deprecated by RFC 8996 + +**Detection** +```bash +# Check for SSLv3 support +nmap --script ssl-enum-ciphers -p 443 | grep -i "SSLv3" + +# Or with openssl +openssl s_client -ssl3 -connect :443 2>&1 | grep -i "alert" +``` + +### Weak Cipher Suites + +**Critical Weaknesses** +- `NULL` ciphers — no encryption at all +- `EXPORT` ciphers — 40/56-bit keys; trivially breakable (FREAK, Logjam) +- `RC4` ciphers — biased keystream; practical plaintext recovery (CVE-2013-2566) +- `DES`/`3DES` — 56/112-bit effective; Sweet32 birthday attack (CVE-2016-2183) +- `CBC` mode without TLS 1.3 — vulnerable to padding oracle attacks in older implementations + +**No Forward Secrecy** +- `RSA` key exchange (not `ECDHE`/`DHE`) — compromised server key decrypts all past traffic +- Static `DH` parameters — precomputed logjam tables for common 1024-bit groups + +### Certificate Issues + +**Chain Problems** +- Expired certificate or intermediate +- Self-signed certificate in production +- Incomplete chain (missing intermediates) +- Wrong hostname (CN/SAN mismatch) +- Revoked certificate (CRL/OCSP) + +**Key Weakness** +- RSA key < 2048 bits +- ECDSA key < 256 bits (P-256) +- SHA-1 signed certificates (deprecated since 2017) + +### Implementation Vulnerabilities + +| Vuln | CVE | Test | +|------|-----|------| +| Heartbleed | CVE-2014-0160 | `nmap --script ssl-heartbleed -p 443 ` | +| POODLE | CVE-2014-3566 | Check for SSLv3+CBC support | +| ROBOT | CVE-2017-13099 | `nmap --script ssl-robot -p 443 ` (if script available) | +| DROWN | CVE-2016-0800 | Check for SSLv2 support on any server sharing the RSA key | +| CCS Injection | CVE-2014-0224 | `nmap --script ssl-ccs-injection -p 443 ` | +| CRIME/BREACH | CVE-2012-4929 | Check TLS compression; `Accept-Encoding: gzip` response analysis | +| Renegotiation | CVE-2009-3555 | `openssl s_client -connect :443` then type `R` | + +## Testing Methodology + +### 1. Enumerate Supported Protocols and Ciphers + +```bash +# Comprehensive nmap scan +nmap -n -Pn --script ssl-enum-ciphers -p 443,8443 + +# Quick openssl check for specific protocol +openssl s_client -tls1 -connect :443 < /dev/null 2>&1 +openssl s_client -tls1_1 -connect :443 < /dev/null 2>&1 +openssl s_client -tls1_2 -connect :443 < /dev/null 2>&1 +openssl s_client -tls1_3 -connect :443 < /dev/null 2>&1 +``` + +### 2. Inspect Certificate Chain + +```bash +# Full certificate details +openssl s_client -connect :443 -showcerts < /dev/null 2>&1 | openssl x509 -noout -text + +# Check specific fields +openssl s_client -connect :443 < /dev/null 2>&1 | openssl x509 -noout \ + -subject -issuer -dates -fingerprint -ext subjectAltName +``` + +### 3. Test for Known Vulnerabilities + +```bash +# Heartbleed +nmap -n -Pn --script ssl-heartbleed -p 443 + +# CCS Injection +nmap -n -Pn --script ssl-ccs-injection -p 443 + +# Multiple checks in one pass +nmap -n -Pn --script "ssl-*" -p 443 +``` + +### 4. Check Security Headers + +```bash +# HSTS header +curl -sI https:// | grep -i strict-transport + +# Expected: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload +``` + +## Validation + +1. **Demonstrate the weakness** — Show the specific weak protocol/cipher is negotiable, not just advertised +2. **Prove impact** — For protocol downgrade, show the client can be forced to use the weak protocol; for weak ciphers, confirm the server selects them when offered exclusively +3. **Certificate issues** — Show the exact chain failure (expired date, hostname mismatch, missing intermediate) +4. **Implementation vulns** — Confirm with Nmap NSE scripts or equivalent tool output +5. **Rate accurately** — TLS 1.0 support alone is Medium; combine with CBC ciphers for High; SSLv3 or Heartbleed is Critical + +## False Positives + +- Server advertises weak ciphers but never selects them (server preference enforced) — verify by offering only the weak cipher +- Certificate expired in alternate SAN but primary domain is valid +- CDN/WAF terminates TLS before reaching origin — the finding applies to the edge, not the origin +- HSTS missing on a non-browser API endpoint — lower severity than a user-facing site +- TLS 1.0 enabled but only for specific legacy clients behind a load balancer policy + +## CVSS Context + +| Finding | Typical CVSS | Rationale | +|---------|-------------|-----------| +| SSLv3 enabled + CBC ciphers (POODLE) | 7.5 (High) | Network-exploitable padding oracle | +| TLS 1.0 only (no TLS 1.2/1.3) | 5.3 (Medium) | Deprecated protocol, known weaknesses | +| Heartbleed (confirmed) | 9.1 (Critical) | Memory disclosure, key extraction | +| Self-signed cert in production | 5.9 (Medium) | No trust chain; enables MITM | +| Missing HSTS | 4.3 (Medium) | Protocol downgrade on first visit | +| Weak DH parameters (< 2048 bit) | 5.3 (Medium) | Logjam precomputation feasible | +| No forward secrecy (RSA key exchange) | 5.3 (Medium) | Past traffic decryptable if key leaked | + +## Pro Tips + +1. Always test all TLS-enabled ports, not just 443 — SMTP STARTTLS (587), database TLS, and custom service ports often have weaker configurations +2. Check if the same RSA key is shared across multiple services — one SSLv2 service enables DROWN on all of them +3. For CDN-fronted targets, also test the origin directly if accessible — CDN may mask origin TLS weaknesses +4. Certificate transparency logs (crt.sh) can reveal additional subdomains and cert history +5. Modern TLS 1.3 has no known cipher suite weaknesses — if the server supports only TLS 1.3, focus testing on certificate chain and implementation instead + +## Tooling + +- **nmap** (preinstalled) — `ssl-enum-ciphers`, `ssl-heartbleed`, `ssl-ccs-injection` NSE scripts +- **openssl** (preinstalled) — Protocol probing, certificate inspection, manual cipher testing +- **nuclei** (preinstalled) — TLS misconfiguration templates: `nuclei -u https:// -tags ssl,tls` From 8e99c63b23b4916d2bff28b4ea299cb54bf3568e Mon Sep 17 00:00:00 2001 From: sandiyochristan Date: Thu, 6 Aug 2026 22:03:08 +0530 Subject: [PATCH 2/3] fix(skills): check high-risk patterns before HTTP methods in safe-mode crawling Resolves Greptile PR review feedback pointing out that checking GET/HEAD/OPTIONS first could authorize destructive actions mapped to read-only methods. The decision framework now checks high-risk URL patterns first, regardless of HTTP method. --- strix/skills/custom/safe_mode_crawling.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/strix/skills/custom/safe_mode_crawling.md b/strix/skills/custom/safe_mode_crawling.md index 3282c30b..e216ad42 100644 --- a/strix/skills/custom/safe_mode_crawling.md +++ b/strix/skills/custom/safe_mode_crawling.md @@ -69,11 +69,11 @@ Before submitting any form, check: ## Decision Framework ``` -Is this action read-only (GET/HEAD/OPTIONS)? -├── YES → Proceed -└── NO → Does the endpoint match a high-risk pattern? - ├── YES → STOP. Log the finding. Do NOT execute. - │ Surface to operator with: URL, method, parameters, and risk assessment. +Does the endpoint match a high-risk pattern (e.g., /delete, /payment)? +├── YES → STOP. Log the finding. Do NOT execute. +│ Surface to operator with: URL, method, parameters, and risk assessment. +└── NO → Is this action strictly read-only (GET/HEAD/OPTIONS)? + ├── YES → Proceed └── NO → Is this a standard form submission / API call for testing? ├── YES → Check: can this action be reversed? │ ├── YES (e.g., create a test user that can be deleted) → Proceed with caution From 5a34df9786a2a5a0ca4754d4cbd02acc7924ee57 Mon Sep 17 00:00:00 2001 From: sandiyochristan Date: Thu, 6 Aug 2026 23:58:07 +0530 Subject: [PATCH 3/3] fix(skills): check endpoint semantics for all HTTP methods in safe-mode guard The decision tree previously auto-approved GET/HEAD/OPTIONS requests that didn't match a high-risk URL pattern, missing state-changing operations exposed through GET (e.g., GET /admin/deleteUser?id=5). Now all requests go through semantic analysis regardless of HTTP method. Addresses Greptile review feedback on PR #989. --- strix/skills/custom/safe_mode_crawling.md | 29 +++++++++++++---------- 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/strix/skills/custom/safe_mode_crawling.md b/strix/skills/custom/safe_mode_crawling.md index e216ad42..1de358d3 100644 --- a/strix/skills/custom/safe_mode_crawling.md +++ b/strix/skills/custom/safe_mode_crawling.md @@ -25,12 +25,12 @@ These are not hypothetical — they are the natural consequence of an autonomous | Method | Default Risk | Notes | |--------|-------------|-------| -| `GET`, `HEAD`, `OPTIONS` | 🟢 Safe | Read-only by specification; safe to explore | +| `GET`, `HEAD`, `OPTIONS` | 🟢 Usually Safe | Read-only by specification, but **not guaranteed** — some apps use GET for state changes | | `POST` | 🟡 Caution | Creates resources; may trigger side effects | | `PUT`, `PATCH` | 🟡 Caution | Modifies existing resources | | `DELETE` | 🔴 High Risk | Removes resources; often irreversible | -**Exception:** Some APIs use `POST` for destructive operations (e.g., `POST /api/users/delete`, `POST /admin/purge-cache`). Always check the endpoint semantics, not just the HTTP method. +**Critical:** HTTP method alone is NOT sufficient to determine safety. Some applications expose state-changing operations through `GET` (e.g., `GET /api/users/delete?id=5`, `GET /admin/reset-password?user=admin`, `GET /logout`, `GET /unsubscribe`). Similarly, `POST` is used for destructive operations (e.g., `POST /api/users/delete`, `POST /admin/purge-cache`). **Always check endpoint semantics — URL path, query parameters, and context — regardless of HTTP method.** ### High-Risk Endpoint Patterns @@ -69,18 +69,23 @@ Before submitting any form, check: ## Decision Framework ``` -Does the endpoint match a high-risk pattern (e.g., /delete, /payment)? -├── YES → STOP. Log the finding. Do NOT execute. -│ Surface to operator with: URL, method, parameters, and risk assessment. -└── NO → Is this action strictly read-only (GET/HEAD/OPTIONS)? - ├── YES → Proceed - └── NO → Is this a standard form submission / API call for testing? - ├── YES → Check: can this action be reversed? - │ ├── YES (e.g., create a test user that can be deleted) → Proceed with caution - │ └── NO or UNCERTAIN → STOP. Surface to operator. - └── NO → Proceed with standard testing +1. Does the endpoint match a high-risk pattern (e.g., /delete, /payment, /reset)? + ├── YES → STOP. Log the finding. Do NOT execute. + │ Surface to operator with: URL, method, parameters, and risk assessment. + └── NO → Continue to step 2. + +2. Does the endpoint semantics suggest state change? (Check URL path, query params, + button text, form action, API docs — even for GET/HEAD/OPTIONS.) + ├── YES or UNCERTAIN → Treat as mutating. Go to step 3. + └── NO, confirmed read-only → Proceed. + +3. Can this action be reversed? + ├── YES (e.g., create a test user that can be deleted) → Proceed with caution. + └── NO or UNCERTAIN → STOP. Surface to operator. ``` +> **Why GET/HEAD/OPTIONS are not auto-approved:** The HTTP spec says these methods _should_ be safe, but real-world applications violate this. A `GET /admin/deleteUser?id=5` is just as destructive as `DELETE /api/users/5`. The decision tree checks endpoint semantics for **every** request, regardless of method. + ## Operational Rules ### Before Any Mutating Request