spoofing

Spoofing Identity Analysis

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "spoofing" with this command: npx skills add florianbuetow/claude-code/florianbuetow-claude-code-spoofing

Spoofing Identity Analysis

Analyze source code for spoofing threats where attackers can impersonate legitimate users or system components. Maps to STRIDE S -- violations of the Authentication security property.

Supported Flags

Read ../../shared/schemas/flags.md for the full flag specification. This skill supports all cross-cutting flags including --scope , --depth , --severity , --format , --fix , --quiet , and --explain .

Framework Context

Read ../../shared/frameworks/stride.md , specifically the S - Spoofing Identity section, for the threat model backing this analysis. Key concerns: credential theft/reuse, session hijacking, token theft, IP spoofing, certificate spoofing.

Workflow

  1. Determine Scope

Parse flags and resolve the target file list per the flags spec. Filter to files likely relevant to authentication and identity:

  • Route handlers and API controllers with login/register/auth logic

  • Authentication middleware and guard functions

  • Session management modules and cookie configuration

  • Token generation, signing, and validation code

  • OAuth/OIDC integration points and callback handlers

  • Configuration files containing credential settings or auth parameters

  • Password reset and account recovery flows

  1. Analyze for Spoofing Threats

For each in-scope file, apply the Analysis Checklist below. Read each file fully at --depth standard or trace cross-file auth flows at --depth deep . Pay special attention to trust boundaries where identity is established or propagated between components.

  1. Report Findings

Output findings per ../../shared/schemas/findings.md using the SPOOF ID prefix (e.g., SPOOF-001 ). Set references.stride to "S" on every finding.

Analysis Checklist

Work through these questions against the scoped code. Each "yes" may produce a finding.

  • Plaintext credentials -- Are passwords, API keys, or tokens stored in plaintext in source, config, or database fields? Search for assignment patterns to variables named password , secret , api_key , token . Check database migration files for password columns without encryption or hashing annotations.

  • Weak hashing -- Are passwords hashed with MD5, SHA-1, or unsalted SHA-256 instead of bcrypt/scrypt/argon2? Look for md5( , sha1( , hashlib.sha256 without salt, crypto.createHash('md5') . Check if a work factor / cost parameter is configured for adaptive hashing.

  • Missing authentication -- Are there route handlers or API endpoints with no auth middleware applied? Check route definitions for missing authenticate , requireAuth , @login_required , or equivalent guards. Map all routes and flag any that handle sensitive data but lack auth in their middleware chain.

  • Session fixation -- Is the session ID regenerated after login? Look for session creation that does not call regenerate() , rotate() , or equivalent after credential verification. Also check that session cookies use Secure , HttpOnly , and SameSite attributes.

  • Token validation gaps -- Are JWTs verified with proper algorithm pinning? Search for algorithms=["none"] , missing verify_signature , or absent aud /iss claims checks. Verify that token expiration (exp ) is enforced and that refresh token rotation is implemented.

  • Certificate verification disabled -- Is TLS certificate validation turned off? Look for verify=False , rejectUnauthorized: false , InsecureSkipVerify: true , or CURLOPT_SSL_VERIFYPEER set to 0. Even in test code, this pattern often leaks to production.

  • IP-based authentication -- Is access granted solely based on IP address or X-Forwarded-For without additional factors? These headers are trivially spoofable. Check if internal APIs rely on source IP as the only access control.

  • Credential comparison timing -- Are secrets compared with == instead of constant-time comparison (hmac.compare_digest , crypto.timingSafeEqual , ConstantTimeCompare )? Timing attacks can leak credential bytes progressively.

  • Default credentials -- Are there hardcoded default usernames/passwords (e.g., admin /admin , test /test ) in source or seed data that may ship to production? Check if seed scripts are gated behind environment checks.

  • OAuth/OIDC misconfig -- Is the state parameter missing from OAuth flows, enabling CSRF? Is the redirect URI validated loosely or with wildcards? Check if the nonce claim is verified in OIDC ID tokens.

  • MFA bypass paths -- If MFA is implemented, are there code paths that skip the second factor? Look for conditional checks that short-circuit MFA for certain user types, remember-me tokens without expiry, or backup code implementations without rate limiting.

  • Account enumeration -- Do login or password-reset endpoints return different responses for valid vs. invalid accounts? Check error messages and HTTP status codes for discrepancies that reveal whether a username exists.

Pragmatism Notes

  • Not every application needs MFA. Evaluate auth requirements proportional to the sensitivity of the data and operations protected.

  • Timing attacks on password comparison are real but require network proximity and many requests. Rate them medium unless the comparison protects a high-value secret with no rate limiting.

  • Test/dev seed data with default credentials is common and acceptable if gated behind environment checks. Only flag if the gate is missing or weak.

  • Cookie attribute issues (missing SameSite ) are defense-in-depth. They matter more when combined with other findings like missing CSRF.

What to Look For

Concrete code patterns and grep heuristics to surface spoofing risks:

  • Hardcoded secrets: Strings assigned to variables matching password|secret|key|token|credential that contain literal values rather than env/vault references. Grep: (password|secret|api_key|token)\s*[:=]\s*['"][^'"]{8,} .

  • Weak hash imports: import md5 , require('md5') , from hashlib import sha1 , crypto.createHash('sha1') , MessageDigest.getInstance("MD5") .

  • Unprotected routes: Route definitions (app.get , router.post , @app.route , @GetMapping ) without auth middleware in the chain. Compare against routes that do have auth to identify gaps.

  • Disabled TLS verification: verify=False , rejectUnauthorized: false , InsecureSkipVerify , SSL_VERIFY_NONE , CURLOPT_SSL_VERIFYPEER.*0 .

  • JWT algorithm none: algorithm.*none , alg.*none , verify_signature.*false , algorithms.*HS256 when RS256 is expected (algorithm confusion). Also jwt.decode(.*verify=False .

  • Session handling: Absence of session.regenerate , req.session.destroy , or session ID rotation logic near login handlers. Missing cookie flags: secure , httpOnly , sameSite .

  • Timing-unsafe comparison: Direct == or != on token/secret variables without constant-time wrappers. Grep: (token|secret|key|hash)\s*[!=]=\s* .

  • Account enumeration signals: Different error messages at login -- e.g., "user not found" vs. "wrong password" instead of a uniform "invalid credentials" response.

Output Format

Each finding must conform to ../../shared/schemas/findings.md .

id: SPOOF-<NNN> severity: critical | high | medium | low confidence: high | medium | low location: file, line, function, snippet description: What the spoofing risk is and how it could be exploited impact: What an attacker gains by exploiting this fix: Concrete remediation with diff when possible references: stride: "S" cwe: CWE-287 (Improper Authentication) or relevant CWE metadata: tool: spoofing framework: stride category: S

Severity Guidelines for Spoofing

Severity Criteria

critical

Unauthenticated access to sensitive endpoints, plaintext credential storage, disabled certificate verification in production code

high

Weak password hashing (MD5/SHA-1), missing session regeneration after login, JWT algorithm confusion allowing forgery

medium

IP-based auth as sole factor, missing OAuth state parameter, timing-unsafe secret comparison, MFA bypass paths

low

Default credentials in dev/test seeds, verbose auth error messages revealing user existence, missing SameSite cookie attribute

Common CWE References

CWE Description

CWE-287 Improper Authentication

CWE-256 Plaintext Storage of a Password

CWE-327 Use of a Broken Crypto Algorithm

CWE-384 Session Fixation

CWE-295 Improper Certificate Validation

CWE-346 Origin Validation Error

CWE-798 Hardcoded Credentials

CWE-208 Observable Timing Discrepancy

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

spec-writer

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

dos

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

attack-surface

No summary provided by upstream source.

Repository SourceNeeds Review