@intentsolutionsio/penetration-tester 2.0.0 → 3.0.4

package/skills/probing-dangerous-http-methods/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: probing-dangerous-http-methods
+description: |
+  Probe a target for HTTP methods that should not be enabled in
+  production — TRACE (XST attack), unrestricted PUT/DELETE,
+  DEBUG/CONNECT, WebDAV (PROPFIND/MKCOL/COPY/MOVE), and Allow header
+  enumeration.
+  Use when: penetration test rules of engagement include HTTP method
+  testing, OR a load balancer change went live and you suspect default
+  methods were exposed.
+  Threshold: TRACE returns 200 on any path (XST), PUT/DELETE returns
+  anything other than 405/403/404 on a non-API endpoint, OPTIONS Allow
+  header lists DEBUG/CONNECT/PROPFIND, or WebDAV methods succeed.
+  Trigger with: "audit http methods", "trace check", "options
+  enumeration", "webdav probe".
+allowed-tools:
+  - Read
+  - Bash(python3:*)
+  - Bash(curl:*)
+disallowed-tools:
+  - Bash(rm:*)
+  - Edit(/etc/*)
+version: 3.0.0-dev
+author: Jeremy Longshore <jeremy@intentsolutions.io>
+license: MIT
+compatibility: Designed for Claude Code
+tags:
+  - security
+  - http-methods
+  - xst
+  - webdav
+  - pentest
+---
+
+# Probing Dangerous HTTP Methods
+
+## Overview
+
+Most HTTP methods beyond GET/POST/HEAD are vestigial — leftover from
+WebDAV authoring stacks of the early 2000s, debugging features in
+legacy servers, or default-enabled methods nobody disabled at install
+time. Each enabled method that the application doesn't use is an
+attack surface: TRACE enables Cross-Site Tracing (XST), PUT enables
+arbitrary file upload to unprotected paths, CONNECT enables proxy
+abuse against internal services, WebDAV enables directory manipulation.
+
+This skill probes the canonical method set and grades each based on
+its presence and response.
+
+## When the skill produces findings
+
+| Finding | Severity | Threshold | Affected control |
+|---|---|---|---|
+| TRACE method enabled | **HIGH** | TRACE returns 200 with request echo | OWASP A05:2021, CWE-693 |
+| PUT method enabled outside API path | **HIGH** | PUT returns 200/201/204 on non-API path | CWE-434 |
+| DELETE method enabled outside API path | **HIGH** | DELETE returns 200/204 on non-API path | CWE-285 |
+| CONNECT method enabled | **CRITICAL** | CONNECT returns 200 (proxy abuse open) | CWE-441 |
+| DEBUG method enabled | **HIGH** | DEBUG returns response (legacy IIS / dev servers) | CWE-489 |
+| WebDAV methods enabled (PROPFIND/MKCOL/COPY/MOVE) | **HIGH** | Any return 207 or 201 | CWE-538 |
+| Allow header discloses unused methods | **LOW** | OPTIONS Allow includes methods app doesn't use | CWE-200 |
+| OPTIONS returns full method enumeration | **LOW** | Allow:* or broad list | CWE-200 |
+
+## Prerequisites
+
+- Python 3.9+
+- Authorization for non-local targets
+
+## Instructions
+
+### Step 1 — Confirm authorization
+
+```text
+"Do you have authorization to perform HTTP method probing on this
+ target? I need confirmation before proceeding."
+```
+
+### Step 2 — Run the scanner
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/skills/probing-dangerous-http-methods/scripts/probe_methods.py \
+    https://example.com \
+    --authorized
+```
+
+Options:
+
+```
+Usage: probe_methods.py URL [OPTIONS]
+
+Options:
+  --authorized      Attest authorization (required)
+  --output FILE
+  --format FMT      json | jsonl | markdown (default: markdown)
+  --min-severity SEV (default: info)
+  --timeout SECS
+  --is-api          Treat URL as API endpoint (relaxes PUT/DELETE checks)
+```
+
+By default the scanner treats the URL as a non-API endpoint where
+PUT/DELETE should return 405. With `--is-api`, those methods are
+expected and don't trigger findings — only the auth checks behind them
+matter (delegated to other skills).
+
+### Step 3 — Interpret findings
+
+CRITICAL CONNECT-open = your reverse proxy is letting external clients
+connect to arbitrary internal hosts (e.g., metadata endpoints in
+AWS/GCP). Ship same-hour fix.
+
+HIGH TRACE = XST attack open. Combined with any XSS, attacker can
+read HttpOnly cookies via XHR. Ship-within-sprint fix.
+
+HIGH WebDAV = file upload + manipulation surface. Audit `references/
+PLAYBOOK.md` § disabling WebDAV.
+
+### Step 4 — Cross-skill chaining
+
+After this skill, suggest:
+
+- `auditing-cors-policy` (#3) if Allow-Methods:* surfaced
+- `detecting-debug-endpoints` (#7) for the broader exposed-feature
+  audit if DEBUG/TRACE both fired
+
+## Examples
+
+### Example 1 — Post-deploy method audit
+
+User: "We rolled out a new ALB config. Audit the method surface."
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/skills/probing-dangerous-http-methods/scripts/probe_methods.py \
+    https://api.example.com \
+    --authorized --is-api --min-severity high
+```
+
+### Example 2 — TRACE / XST audit after XSS finding
+
+User: "Found XSS on /search; checking if XST chain is possible."
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/skills/probing-dangerous-http-methods/scripts/probe_methods.py \
+    https://example.com \
+    --authorized
+```
+
+If TRACE-enabled finding fires, the XST chain works: attacker XSS
+issues a TRACE request via XHR, the server echoes the request
+(including HttpOnly cookies that XHR-set-cookies access can't normally
+read), JavaScript reads the response body, full session theft.
+
+### Example 3 — WebDAV legacy audit on a recently-acquired domain
+
+User: "We just acquired example.io — quick method-surface check before
+we re-point DNS."
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/skills/probing-dangerous-http-methods/scripts/probe_methods.py \
+    https://example.io \
+    --authorized --min-severity medium
+```
+
+Often surfaces decade-old WebDAV / DEBUG defaults that nobody disabled
+on the previous owner's stack.
+
+## Output
+
+JSON / JSONL / Markdown. Exit 0 / 1 / 2 per `lib/report.py`.
+
+## Error Handling
+
+- **Method returns 405** → expected behavior, no finding
+- **Method returns 403** → access-controlled (acceptable), no finding,
+  but INFO note recorded
+- **Method returns 500** → INFO finding flagging error-handling concern
+- **Connection error** → exit 2
+
+## Resources
+
+- `references/THEORY.md` — Per-method attack semantics
+- `references/PLAYBOOK.md` — How to disable each method per server type
+- `../analyzing-tls-config/references/AUTHORIZATION.md` — Active-scan
+  authorization

package/skills/probing-dangerous-http-methods/references/PLAYBOOK.md

@@ -0,0 +1,234 @@
+# HTTP Methods — Remediation Playbook
+
+## Disable TRACE
+
+### nginx
+
+```nginx
+server {
+    listen 443 ssl http2;
+    server_name example.com;
+
+    if ($request_method = TRACE) {
+        return 405;
+    }
+
+    # ... rest of config ...
+}
+```
+
+The `if` directive is generally discouraged in nginx, but this is the
+canonical pattern for method filtering and is safe.
+
+### Apache (httpd 2.4)
+
+```apache
+TraceEnable Off
+```
+
+This is a server-global directive; place it in the main config.
+
+### IIS
+
+1. IIS Manager → site → Request Filtering → HTTP Verbs tab.
+2. Click "Deny Verb" → enter `TRACE`.
+3. Apply.
+
+### AWS ALB
+
+ALB doesn't expose method-level filtering directly. Use a Lambda@Edge
+function or WAF rule:
+
+```json
+{
+    "Type": "RegexMatchStatement",
+    "FieldToMatch": {"Method": {}},
+    "RegexString": "^(TRACE|CONNECT|DEBUG|PROPFIND|MKCOL|COPY|MOVE)$",
+    "Action": "Block"
+}
+```
+
+### Cloudflare WAF
+
+```
+http.request.method in {"TRACE" "CONNECT" "DEBUG" "PROPFIND" "MKCOL" "COPY" "MOVE"}
+```
+
+Action: Block.
+
+## Disable CONNECT
+
+CONNECT should never be enabled on a public-facing server. If your
+audit found it enabled, the cause is one of:
+
+### Apache with mod_proxy as forward proxy
+
+Bad:
+
+```apache
+ProxyRequests On
+```
+
+Fix: change to `ProxyRequests Off`. The reverse-proxy `ProxyPass` and
+`ProxyPassReverse` directives still work without it.
+
+### nginx misconfigured as forward proxy
+
+Check for `proxy_method CONNECT` anywhere in config and remove.
+
+### Squid or other proxy software exposed publicly
+
+Move the proxy behind authentication or behind a VPN; don't expose it
+publicly.
+
+## Disable DEBUG (IIS)
+
+1. IIS Manager → site → Handler Mappings.
+2. Find any handler with DEBUG in its verb list (typically aspnet
+   handlers).
+3. Edit → remove DEBUG from the Verb field.
+4. Restart IIS.
+
+Express dev: ensure `process.env.NODE_ENV === 'production'`. The
+Express dev middleware exposes DEBUG only in non-production mode.
+
+## Disable PUT and DELETE on non-API paths
+
+### nginx
+
+```nginx
+location / {
+    limit_except GET POST HEAD {
+        deny all;
+    }
+}
+
+location /api/ {
+    # API location — all methods allowed; auth handled by upstream
+    proxy_pass http://api-backend;
+}
+```
+
+### Apache
+
+```apache
+<Location />
+    <LimitExcept GET POST HEAD>
+        Require all denied
+    </LimitExcept>
+</Location>
+
+<Location /api>
+    # API location
+</Location>
+```
+
+### Express (Node.js)
+
+By default, Express only handles routes you register. To explicitly
+block:
+
+```js
+app.all('*', (req, res, next) => {
+    const allowed = ['GET', 'POST', 'HEAD', 'OPTIONS'];
+    if (!allowed.includes(req.method)) {
+        return res.status(405).send('Method Not Allowed');
+    }
+    next();
+});
+```
+
+## Disable WebDAV
+
+### nginx
+
+Check vhost for any `dav_methods` directive:
+
+```nginx
+location / {
+    dav_methods off;  # explicit
+}
+```
+
+The default is `off`, but some sample configs enable it implicitly.
+
+If your nginx was compiled with `--with-http_dav_module`, recompile
+without it or move to a packaged binary that doesn't include it.
+
+### Apache
+
+```apache
+# Comment out or remove:
+# LoadModule dav_module modules/mod_dav.so
+# LoadModule dav_fs_module modules/mod_dav_fs.so
+
+# If you can't remove the module, deny WebDAV methods explicitly:
+<Location />
+    <LimitExcept GET POST HEAD OPTIONS>
+        Require all denied
+    </LimitExcept>
+</Location>
+```
+
+### IIS
+
+Server Manager → Roles & Features → uncheck "WebDAV Publishing" under
+Web Server (IIS) → Common HTTP Features. Restart IIS.
+
+Or via PowerShell:
+
+```powershell
+Uninstall-WindowsFeature -Name Web-DAV-Publishing
+```
+
+## Restrict OPTIONS Allow header
+
+The right approach is to let the framework compute Allow from
+registered routes; most modern frameworks do this by default.
+
+### nginx custom Allow response
+
+If you need to override:
+
+```nginx
+location /api/users {
+    if ($request_method = OPTIONS) {
+        add_header Allow "GET, POST, PUT, DELETE, OPTIONS";
+        return 204;
+    }
+}
+```
+
+## CI integration
+
+```yaml
+- name: HTTP method probe
+  run: |
+    python3 plugins/security/penetration-tester/skills/probing-dangerous-http-methods/scripts/probe_methods.py \
+        "${{ secrets.PROD_URL }}" \
+        --authorized \
+        --min-severity high \
+        --format json \
+        --output method-probe.json
+- run: |
+    if jq 'any(.severity == "critical" or .severity == "high")' method-probe.json | grep -q true; then
+      echo "::error::Dangerous HTTP method found enabled"
+      exit 1
+    fi
+```
+
+Recommended cadence: every deploy + nightly. WAF/LB config drift is
+the most common regression source.
+
+## Verification after remediation
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/skills/probing-dangerous-http-methods/scripts/probe_methods.py \
+    https://example.com \
+    --authorized \
+    --min-severity medium
+```
+
+Expected: exit 0, no MEDIUM-or-higher findings. INFO findings about
+"OPTIONS Allow discloses unused methods" may persist if your framework's
+default Allow is broad; consider customizing per the section above.

package/skills/probing-dangerous-http-methods/references/THEORY.md

@@ -0,0 +1,145 @@
+# HTTP Methods — Theory
+
+## TRACE and XST
+
+RFC 7231 §4.3.8 defines TRACE as a debugging method: the server should
+echo the request back to the client. The intent was diagnostic — see
+exactly what intermediate proxies added or stripped.
+
+The problem: in 2003, Jeremiah Grossman demonstrated Cross-Site Tracing
+(XST). An attacker who can execute JavaScript on the origin (e.g., via
+XSS) issues an XHR request with method TRACE. The server echoes the
+request body — including HttpOnly cookies that XHR-set-cookies cannot
+normally read. The attacker's JavaScript reads the response body and
+exfiltrates the cookies.
+
+HttpOnly was meant to make session cookies inaccessible to JavaScript;
+TRACE makes them accessible again. The fix is to disable TRACE on
+every web server, period. There is no legitimate production use case
+that requires TRACE.
+
+Modern servers ship with TRACE disabled by default. If you see TRACE
+enabled on a target, it's typically a server with hand-rolled config
+that forgot to disable it, or a stale install of older nginx/Apache.
+
+## CONNECT
+
+CONNECT (RFC 7231 §4.3.6) is for HTTP proxies: the client asks the
+proxy to open a TCP tunnel to a specified destination. Once the tunnel
+is established, the proxy blindly forwards bytes both ways.
+
+The danger: if your reverse proxy implements CONNECT, external clients
+can ask it to connect to ARBITRARY internal hosts. The proxy obediently
+opens TCP to internal-database:5432 and forwards bytes. Cloud metadata
+endpoints (169.254.169.254 in AWS / GCP / Azure) are a particular
+prize — they require no authentication, exposing credentials and
+config to anyone who can reach them.
+
+nginx and Apache reject CONNECT by default. Seeing CONNECT enabled
+means someone misconfigured `ProxyRequests On` (Apache) or a
+similar nginx pattern.
+
+## DEBUG
+
+Microsoft's IIS shipped a DEBUG HTTP method for ASP.NET application
+debugging. Sending `DEBUG /path HTTP/1.0` with `Command: stop-debug`
+header would gracefully halt active debugging sessions. The auth model
+was implicit — if you could send the request, you could stop debug.
+
+Modern stacks don't use DEBUG. If you see it enabled, the target is
+either:
+
+- An older IIS install with debugging features incompletely disabled
+- A development server (Flask dev, Django runserver) exposed publicly
+- A custom server that recognizes the method by accident
+
+Any of those is worth investigating.
+
+## PUT and DELETE
+
+Both are legitimate REST methods. The "dangerous" part is when they're
+exposed on paths the application doesn't actually serve as REST APIs.
+
+The classic exploit: server allows PUT on `/uploads/`. Attacker PUTs a
+`.php` (or `.jsp` or `.aspx`) file. Server stores it. Attacker
+requests the file; server-side runtime executes it. Full RCE from one
+unauthenticated PUT.
+
+Modern frameworks (Express, FastAPI, Spring, Rails) don't enable
+PUT/DELETE on routes unless you explicitly bind handlers. The danger
+is at the server-software layer: older nginx with WebDAV module
+loaded, older Apache with mod_dav, IIS with WebDAV authoring feature.
+
+If the target is an actual REST API (`/api/v1/users/{id}` should
+accept PUT/DELETE with auth), use `--is-api` to suppress the
+PUT/DELETE finding — at that point, the audit moves to skill #21
+(`confirming-pentest-authorization`) and the authentication-validator
+plugin.
+
+## WebDAV (PROPFIND, MKCOL, COPY, MOVE)
+
+RFC 4918 defines WebDAV — an extension of HTTP for collaborative
+authoring. Methods:
+
+- PROPFIND: list directory contents + properties
+- MKCOL: create new directory
+- COPY: copy file/dir on server
+- MOVE: move file/dir on server
+- LOCK/UNLOCK: file locking for collaborative editing
+
+In modern web stacks WebDAV is essentially unused. It survives as a
+default in:
+
+- Older nginx with `dav_methods` enabled in vhost
+- Apache with mod_dav loaded
+- IIS with WebDAV Publishing role
+
+If WebDAV is enabled and any write method (MKCOL, MOVE, COPY) succeeds
+without auth, the consequence is identical to enabling PUT — arbitrary
+file write becomes a code-execution vector if the target serves
+executable file types.
+
+PROPFIND alone is information disclosure (directory listing). Bounded
+risk but rarely intentional in 2026.
+
+## OPTIONS and Allow header
+
+OPTIONS is meant to be informational — "what can I do here?" The
+response's Allow header lists supported methods. This is fine in
+principle.
+
+The problem: many servers respond with a broad Allow header that
+includes methods the application doesn't use. Attackers scrape Allow
+to enumerate the method surface and pick targets.
+
+The fix isn't to disable OPTIONS (CORS preflight needs it) — it's to
+configure the Allow response to list only methods the application
+actually supports. Many frameworks compute Allow dynamically from
+registered route handlers, which gives you the correct answer for
+free.
+
+`Allow: *` is the worst case — server-asserted "anything goes." Even
+when paired with proper handler-level checks, the disclosure of
+"anything is on the table" is information attackers can use.
+
+## Why this skill's defaults treat non-API paths strictly
+
+The "is-API" assumption is binary in this skill: either the URL is a
+REST API endpoint where PUT/DELETE are expected, or it isn't. In real
+production stacks there are mixed cases — `/api/v1/users` serves PUT,
+`/index.html` doesn't. The right operational pattern is to run this
+skill twice per target with `--is-api` toggled, against representative
+URLs of each type.
+
+For monolithic apps where everything is on `/`, treat as non-API and
+fix any PUT/DELETE exposure by adding `limit_except GET POST { deny
+all; }` at the server level.
+
+## Primary sources
+
+- [RFC 7231 — HTTP/1.1 Semantics §4.3](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3)
+- [RFC 4918 — WebDAV](https://datatracker.ietf.org/doc/html/rfc4918)
+- [OWASP WSTG-CONF-06 — Test HTTP Methods](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods)
+- Jeremiah Grossman — Cross-Site Tracing (XST), 2003
+- [CWE-441 — Unintended Proxy or Intermediary](https://cwe.mitre.org/data/definitions/441.html)
+- [CWE-538 — File and Directory Information Exposure](https://cwe.mitre.org/data/definitions/538.html)