xssi-and-client-framework

name

xssi-and-client-framework

description

XSSI (cross-site script inclusion) and client-side framework attack techniques -- JSONP hijacking, AngularJS sandbox escapes, Vue/React unsafe-HTML sinks, client-side prototype pollution gadgets, service-worker hijacking, Sass/SCSS server-side injection, and full DOM clobbering. Converted from master-pentest-prompt.md Phase 25. Use on any endpoint returning JS/JSONP containing authenticated data, and on any modern JS-framework-heavy frontend.

XSSI & client-side framework attacks

When to use

Any endpoint that returns a .js/JSONP response containing authenticated user data, and any target built on Angular/Vue/React or using service workers.

XSSI (cross-site script inclusion)

An endpoint returning JSONP/JS/a bare array that reflects authenticated user data with no CSRF/anti-XSSI token lets a third-party page read it cross-origin via <script src="//target/account.js"> -- the script tag itself has no same-origin restriction. Test JSON responses that start with [ (an array literal is valid, executable JS on its own) and check for missing X-Content-Type-Options and no auth check on the GET request.

JSONP hijacking specifically: a callback= parameter that echoes data back wrapped in a function call lets an attacker's page define that function and steal the authenticated response.

AngularJS template sandbox escapes

Older Angular 1.x sandbox bypasses (client-side, not server SSTI, but the same shape): {{constructor.constructor('alert(1)')()}}, {{$eval.constructor('alert(1)')()}}, or a request path containing ng-app that gets reflected into a template context.

Vue/React unsafe sinks

dangerouslySetInnerHTML (React), v-html (Vue), plain innerHTML sinks, and template-literal injection in server-rendered props -- check __NEXT_DATA__/window.__INITIAL_STATE__ specifically, since these often need double-encoding to actually trigger given they're JSON-embedded-in-HTML.

Client-side prototype pollution

Escalating to XSS or an open redirect through a gadget the app already has -- the URL constructor, fetch, or a location.href assignment that reads a polluted property.

Service worker hijack

A malicious service worker registration can persist client-side XSS across the worker's entire scope (which is path-based, so it can cover many pages at once) and across subdomains if scoped broadly. Test whether the service worker's own update mechanism trusts an unkeyed cache header.

Sass/SCSS server-side injection

Server-side Sass/SCSS compilation (Rails, node-sass) accepting attacker-influenced input can escalate to RCE through the compiler itself.

DOM clobbering (full list)

<img name=x>, <iframe name=f> -- id/name attribute collisions that shadow JS global variables, including iterable-clobbering variants where an attacker-controlled HTMLCollection gets treated as an array.

postMessage chain (full procedure)

Find every window.addEventListener('message', ...) handler (the reconnaissance skill's JS-mining checklist covers finding these), test the origin check specifically -- event.origin === 'exact-match' is safe, .includes()/.indexOf() checks are bypassable, and a check for literal string "null" can be satisfied by a sandboxed iframe. Send malicious data through any weak handler and see whether it reaches a privileged function call.