framework-patterns

name

framework-patterns

description

This skill should be used when the user asks about "framework vulnerabilities", "Next.js security", "Flask security", "Django security", "Rails security", "Spring security", "GraphQL security", "Server Actions", "render_template_string", "SSTI patterns", "redirect SSRF", "mass assignment", "actuator exposure", "SpEL injection", "introspection", or needs to identify framework-specific vulnerability patterns during whitebox security review.

Framework Security Patterns

Framework-specific vulnerability patterns that arise from how modern web frameworks handle requests, responses, and data flow. These patterns are more durable than version-specific CVEs.

Why Framework Patterns Matter

1. Frameworks have implicit behaviors - redirect(), Server Actions, template rendering have side effects
2. Trust assumptions differ - Internal vs external, server vs client boundaries
3. Chains emerge - Framework A's feature enables exploitation of Framework B's weakness

Pattern Categories

1. Request Handling Patterns

• Server Actions (Next.js) - Host header influence on internal requests
• Route Handlers - Missing authentication on API routes
• Middleware bypass - Path normalization differences

2. Template/Rendering Patterns

• SSTI (Flask, Jinja2, Django, Twig) - User input in template strings
• XSS via unsafe HTML insertion (React)
• Prototype pollution in SSR

3. Redirect Patterns

• Open redirect via unvalidated URLs
• SSRF via server-side redirect (Next.js, PHP)
• Header injection through redirect URLs

4. Deserialization Patterns

• Pickle (Python)
• Marshal (Ruby)
• PHP unserialize
• Java ObjectInputStream

Detection Workflow

1. Identify frameworks in use (package.json, requirements.txt, Gemfile)
2. Search for pattern signatures specific to each framework
3. Map data flow from user input to dangerous framework APIs
4. Check for sanitization or validation before reaching sink

Framework-Specific Skills

• nextjs-patterns.md - Next.js Server Actions, redirect, Route Handlers
• flask-patterns.md - Flask/Jinja2 SSTI, unsafe deserialization
• references/django-patterns.md - Django ORM bypass, template injection, CSRF bypass, settings exposure, mass assignment, open redirect
• references/rails-patterns.md - Rails mass assignment, SQL injection, SSTI, command injection, insecure deserialization, unscoped finds, arbitrary file render
• references/spring-security-patterns.md - Spring SpEL injection, method security misconfiguration, CORS, CSRF, actuator exposure, mass binding, insecure JWT
• references/graphql-patterns.md - GraphQL introspection, query depth/complexity abuse, batching attacks, authorization bypass, error disclosure

Integration with Audit Workflow

During /full-audit:

1. Step 1 identifies frameworks during language detection
2. Step 2 threat model considers framework-specific trust boundaries
3. Step 4 deep dive uses framework-specific sink patterns

Example: DoxPit Pattern

Frontend: Next.js with Server Actions
Backend: Flask with Jinja2 templates

Chain:
1. Server Action uses redirect() → Host header controls internal fetch URL
2. SSRF reaches Flask backend on internal port
3. Flask uses render_template_string() with user input
4. SSTI → RCE via Jinja2 payload

This pattern detection focuses on the code behavior, not version numbers.