@gpzhang2001/sharpkit-skills 0.2.1

package/skills/vulnerabilities/argument_injection.md

@@ -0,0 +1,157 @@
+---
+name: argument-injection
+description: Test shell-free command argument injection across argv builders and CLI parsers, including option smuggling, response/config-file parsing, argument-boundary reparsing, and Windows Unicode-to-ANSI Best-Fit transformations
+---
+
+# Argument Injection
+
+Use this skill when attacker-influenced data reaches a trusted command-line program, even when no shell is involved. The security question is whether the input changes the program's **option set, operands, configuration, subcommand, or downstream parser state**.
+
+Load `rce` when a shell parses the command string. Load `semantic_confusion` when validation and the final CLI/filesystem/configuration consumer see different representations.
+
+## Model Every Parser Boundary
+
+Build the actual transformation chain:
+
+```text
+request value
+  -> application validation
+  -> argv builder or command-line string serializer
+  -> OS/process creation API
+  -> runtime argv construction
+  -> target option parser
+  -> response/config/auth file parser, URL parser, or subcommand
+```
+
+Do not treat all process APIs alike:
+
+- POSIX `execve(path, argv, envp)` and list-form subprocess APIs preserve array-element boundaries. Whitespace inside one element does not create another argument.
+- Shell/string forms introduce shell tokenization before the target program sees `argv`.
+- Windows process creation commonly serializes an argument array into one command-line string and lets the child runtime parse it back. Quoting rules differ across CRTs and applications.
+- Some programs deliberately reparse an argument as a response file, configuration file, URL, expression, template, or nested command language.
+
+Record the exact API, platform, runtime, target binary/version, option parser, and final `argv` observed by the child.
+
+## Primitive 1: Option and Subcommand Injection
+
+An attacker-controlled value placed where an operand is expected can be interpreted as an option when it begins with an option prefix:
+
+```text
+intended: ["tool", USER_VALUE]
+supplied: USER_VALUE = "--output=/controlled/path"
+actual:   tool parses an output option instead of an operand
+```
+
+Inventory security-relevant option classes rather than memorizing one payload:
+
+- output, upload, extraction, log, cache, plugin, template, or configuration paths
+- alternate URL schemes, proxies, certificates, credentials, and authentication files
+- hooks, helpers, filters, interpreters, external programs, or dynamic libraries
+- config overrides, environment definitions, working directories, and search paths
+- subcommands that expose administrative, import/export, restore, diagnostic, or execution features
+
+Check whether the target supports `--` as an end-of-options marker and whether the application places it before the untrusted operand. Do not assume every CLI honors `--`, or that it applies after a subcommand switches to a second parser.
+
+## Primitive 2: Argument-Boundary Breakout
+
+Require a component that reparses or reconstructs arguments. Candidate boundaries include:
+
+- shell or command-string construction
+- Windows quoting/escaping mismatches between parent and child runtimes
+- newline-, NUL-, delimiter-, or quote-sensitive custom launchers
+- wrappers that join an array and later split it
+- CGI/interpreter mappings that turn request data into command-line options
+
+Distinguish these outcomes:
+
+```text
+["tool", "user --flag"]       # one argv element; no split by execve
+["tool", "user", "--flag"]  # extra argv element reached the target
+["tool", "@args.txt"]        # one element, then reparsed by the target
+```
+
+Logs often render arrays as strings and can falsely suggest splitting. Capture the child's real arguments through source instrumentation, a wrapper process, debugger, audit trace, `/proc/<pid>/cmdline`, or the platform equivalent.
+
+## Primitive 3: Response, Config, and Authentication Files
+
+Many trusted programs consume a second language after argv parsing:
+
+- `@response-file` syntax used by compilers, linkers, JVM tooling, and custom launchers
+- `--config`, `-K`, credentials/auth files, include files, and rc/profile paths
+- newline-delimited key/value files generated from attacker-controlled fields
+- file contents where control characters create a new directive, identity, host, or option
+
+Trace both attacker influence over the **file path** and influence over the **file content**. Correct shell quoting does not protect a file that is later tokenized by a different grammar. Record duplicate-key behavior, newline rules, comments, escaping, include directives, and first/last-value precedence.
+
+## Windows Unicode-to-ANSI Best-Fit
+
+On Windows, narrow-character APIs and CRT startup paths can convert Unicode command-line, environment, or filesystem data into an ANSI code page. Best-Fit mappings may introduce ASCII characters after earlier validation.
+
+Relevant boundaries include:
+
+- `GetCommandLineA` or a narrow `main(int, char **)` startup path
+- `GetEnvironmentVariableA`, `GetCurrentDirectoryA`, and narrow filesystem APIs
+- framework or native-extension transitions from UTF-16 strings to an ANSI code page
+
+`CommandLineToArgvW` is the documented Windows command-line parser; there is no documented `CommandLineToArgvA`. Determine which CRT or application-specific parser constructs narrow `argv`.
+
+Treat mappings as code-page-specific hypotheses, not universal payloads. Candidate transformations include soft hyphen to `-`, fullwidth/compatibility slash characters to `/` or `\`, and compatibility quotes or letters to ASCII equivalents. Capture:
+
+- submitted Unicode code points and encoded bytes
+- active system/process code page
+- wide string before conversion
+- narrow bytes and final `argv` or filesystem path after conversion
+
+Using wide-character APIs removes this particular conversion boundary but does not fix ordinary option injection.
+
+## Reconnaissance
+
+In source, locate process creation and work forward into the consumer:
+
+```text
+exec*  posix_spawn  subprocess  ProcessBuilder  Runtime.exec
+CreateProcess  ShellExecute  child_process  os/exec  Command
+```
+
+For each attacker-controlled argument, answer:
+
+1. Is it a distinct argv element or part of a command string?
+2. Can it begin with the target's option prefix?
+3. Is an end-of-options marker supported and correctly positioned?
+4. Does a wrapper, CRT, shell, or target reparse it?
+5. Can it select a response/config/auth file or inject directives into one?
+6. Which target option or subcommand turns that control into read, write, request, identity, or execution capability?
+
+For black-box testing, compare an ordinary operand with option-prefixed, delimiter-bearing, control-character, and platform-specific Unicode variants. Match tests to options that actually exist in the deployed binary/version.
+
+## Validation
+
+- Show the final `argv` or secondary parser input, not only the application log line.
+- Pair the candidate with a control where the same bytes remain a literal operand.
+- Demonstrate the exact option, directive, subcommand, path, or handler selected.
+- Reproduce against the deployed binary, runtime, code page, and configuration.
+- Separate option control, additional-argument control, arbitrary directive control, and command execution; they are different primitives.
+
+## False Positives
+
+- The input is one argv element and the target treats it only as a positional operand.
+- `--` is supported, placed before the value, and not bypassed by a subparser.
+- A strict allowlist prevents option prefixes and all later transformations preserve it.
+- A delimiter appears only in logging or display formatting.
+- A response/config path is controllable but its contents or directives are not.
+- A Unicode character is accepted but no narrow/Best-Fit conversion occurs.
+- The injected option exists on another release or platform but not the deployed target.
+
+## Remediation
+
+- Use argument-array process APIs and avoid shell/string construction.
+- Insert `--` before untrusted operands where every relevant parser supports it.
+- Validate operands against the target CLI's grammar, not a generic shell blacklist.
+- Fix security-sensitive option names and configuration paths in trusted code.
+- Generate configuration/auth files with a format-aware serializer that rejects control characters and ambiguous duplicates.
+- On Windows, keep data in wide-character APIs and verify child-runtime parsing rules.
+- Enforce authorization again at the privileged operation selected by the CLI.
+
+## Summary
+
+Argument injection is control of a trusted program's behavior through its argv or a parser reached from argv. Preserve parser boundaries in the model: list-form execution, command-string tokenization, Windows runtime conversion, option parsing, and response/config-file parsing are distinct stages with distinct exploit conditions.

package/skills/vulnerabilities/authentication_jwt.md

@@ -0,0 +1,166 @@
+---
+name: authentication-jwt
+description: JWT and OIDC security testing covering token forgery, algorithm confusion, and claim manipulation
+---
+
+# Authentication / JWT / OIDC
+
+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.
+
+## Attack Surface
+
+- 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
+
+## Reconnaissance
+
+### 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`
+
+### 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"`)
+
+## Key Vulnerabilities
+
+### 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 `"alg":"none"` and drop the signature if libraries accept it
+- ECDSA malleability/misuse: weak verification settings accepting non-canonical signatures
+
+### 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
+
+### 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)
+
+### 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)
+
+### 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
+- Device/Backchannel flows: codes and tokens accepted by unintended clients or services
+
+### 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
+
+### 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
+
+## 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
+
+### 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
+
+## 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
+
+### SSO Federation
+
+- Misconfigured trust between multiple IdPs/SPs, mixed metadata, or stale keys lead to acceptance of foreign tokens
+
+## 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
+
+## Testing Methodology
+
+1. **Inventory issuers/consumers** - Identity providers, API gateways, services, mobile/web clients
+2. **Capture tokens** - Access and ID tokens for multiple roles; note header, claims, signature
+3. **Map verification endpoints** - `/.well-known`, `/jwks.json`
+4. **Build matrix** - Token Type × Audience × Service; attempt cross-use
+5. **Mutate components** - Headers (alg, kid, jku/x5u/jwk), claims (iss/aud/azp/sub/exp), signatures
+6. **Verify enforcement** - What is actually checked vs assumed
+
+## 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
+
+## 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
+
+## 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
+
+## 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
+4. Exploit JWKS caching and rotation races; try retired keys and missing kid fallbacks
+5. Exercise OIDC flows with PKCE/state/nonce variants and mixed clients; look for mix-up
+6. Try DPoP/mTLS absence to replay tokens from different devices
+7. Treat refresh as its own surface: rotation, reuse detection, and audience scoping
+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
+
+## Tooling
+
+- `jwt_tool -t <url> -rh "Authorization: Bearer <token>" -M at` runs the
+  full attack matrix (alg=none, RS→HS confusion, kid injection, claim
+  edits) and reports which mutations the server still accepts.
+- `jwt_tool <token> -C -d <wordlist>` brute-forces HMAC secrets when an
+  HS-family signature is in use.
+- Use `jwt_tool` to mint a token under a key you control once you find an
+  acceptance path (kid/jku/x5u/jwk), then replay via `repeat_request`.
+
+## Summary
+
+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.

package/skills/vulnerabilities/broken_function_level_authorization.md

@@ -0,0 +1,154 @@
+---
+name: broken-function-level-authorization
+description: BFLA testing for action-level authorization failures across endpoints, admin functions, and API operations
+---
+
+# Broken Function Level Authorization (BFLA)
+
+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.
+
+## Attack Surface
+
+- 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
+
+## 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
+
+## Reconnaissance
+
+### 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
+
+### 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
+
+## Key Vulnerabilities
+
+### 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)
+
+### 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
+
+### 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
+
+### 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
+
+### Content-Type Paths
+
+- JSON vs form vs multipart handlers using different middleware: send the action via the most permissive parser
+
+## 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
+
+```graphql
+mutation Promote($id:ID!){
+  a: updateUser(id:$id, role: ADMIN){ id role }
+}
+```
+
+### 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
+
+### WebSocket
+
+- Handshake-only auth: ensure per-message authorization on privileged events (e.g., admin:impersonate)
+- Try emitting privileged actions after joining standard channels
+
+### Multi-Tenant
+
+- Actions requiring tenant admin enforced only by header/subdomain; attempt cross-tenant admin actions by switching selectors with same token
+
+### Microservices
+
+- Internal RPCs trust upstream checks; reach them through exposed endpoints or SSRF; verify each service re-enforces authz
+
+## Bypass Techniques
+
+### Header Trust
+
+- Supply X-User-Id/X-Role/X-Organization headers; remove or contradict token claims; observe which source wins
+
+### Route Shadowing
+
+- Legacy/alternate routes (e.g., /admin/v1 vs /v2/admin) that skip new middleware chains
+
+### Idempotency and Retries
+
+- Retry or replay finalize/approve endpoints that apply state without checking actor on each call
+
+### Cache Key Confusion
+
+- Cached authorization decisions at edge leading to cross-user reuse; test with Vary and session swaps
+
+## Testing Methodology
+
+1. **Build Actor × Action matrix** - Unauth, basic, premium, staff/admin; enumerate actions per role
+2. **Obtain tokens/sessions** - For each role
+3. **Exercise every action** - Across all transports and encodings (JSON, form, multipart), including method overrides
+4. **Vary headers and selectors** - Org/tenant/project; test behind gateway vs direct-to-service
+5. **Include background flows** - Job creation/finalization, webhooks, queues; confirm re-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
+
+## 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
+
+## 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
+
+## 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
+
+## Summary
+
+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.