# XSS platform.twitter.com

hub.html on platform.twitter.com passed postMessage URLs to openIntent without blocking javascript: scheme, enabling XSS in a popup on the twitter.com origin.

- Payout: hidden
- Severity: medium
- Program: X / xAI
- Found by: batram
- Disclosed: 2014-11-17
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/29328
- Library page: https://bugbountylibrary.com/r/h1%3A29328
- Tags: area:web domain:web impact:integrity kind:bounty platform:hackerone sev:medium tech:rest technique:source-review vuln:xss

**Target:** platform.twitter.com/widgets/hub.html postMessage handler
**Root cause:** The hub.html page accepted URLs via postMessage/FlashTransport and opened them via openIntent without validating the scheme, so a javascript: URL executed in the popup context on platform.twitter.com.
**Steps:**
1. Embed `https://platform.twitter.com/widgets/hub.html` in an iframe.
2. Wait for the `__ready__` message from the iframe.
3. postMessage `{"id": 12, "method": "openIntent", "params":["javascript:alert(document.domain)"]}` with targetOrigin `https://platform.twitter.com/`.
4. Popup opens and executes the javascript: payload on platform.twitter.com (requires popups allowed or user interaction).
**How found:** After prior FlashTransport fixes on platform.twitter.com, the researcher reviewed the surrounding JavaScript and noticed hub.html opened postMessage-supplied URLs without a javascript: prefix check.
**Exploitation:** Attacker page frames hub.html, waits for ready handshake, then sends an openIntent postMessage with a javascript: URL; the resulting popup executes script in the platform.twitter.com origin.
**Insight:** When a widget page has a postMessage 'open URL' API, check whether the scheme is validated—javascript:/data: in an openIntent-style handler yields XSS on the widget's origin even from a cross-origin frame.