# Account takeover via postMessage

postMessage origin check used filter()[0] compared with !== null, so undefined passed; attacker page sent window-redirect with javascript: URL to hijack victim session and change password.

- Payout: $1,500
- Severity: high
- Program: -
- Credited: socket
- Disclosed: 2020-06-05
- Write-up quality: 7/10
- Original: https://yxw21.github.io/2020/06/05/Account-Takeover-Via-PostMessage/
- Library page: https://bugbountylibrary.com/r/blog%3Ayxw21-github-io-2020-06-05-account-takeover-via-postmessage
- Tags: domain:web impact:ato kind:bounty platform:blog sev:high technique:source-review vuln:access-control vuln:account-takeover vuln:xss

**Target:** Inline webchat widget postMessage handler
**Root cause:** Origin allowlist check used Array.prototype.filter(...)[0] which returns undefined on no match, then compared with `null !== e`, so undefined passed the check and any origin was accepted.
**Steps:**
1. Read handleMessages: it filters chatInstancesDetail by t.origin and checks `if (null !== e)`.
2. Note filter()[0] returns undefined when no match; `null !== undefined` is true, so check always passes.
3. Host attacker page that opens victim site in a window (`window.open`).
4. Repeatedly `ctx.postMessage({'command':'window-redirect','completionRedirectUrl':'javascript:eval(atob(payload))'},'*')` every 500ms.
5. Payload reads `#currentCustomerEmail`, fills newPassword fields, enables them, submits `#updatePasswordForm`, and posts 'attackSuccess' back to stop the interval.
**How found:** Routine review of postMessage handlers; noticed origin check existed but used filter()[0] with a `null !==` comparison, realized undefined bypasses it, then built a PoC to confirm arbitrary-origin messaging and javascript: redirect execution.
**Exploitation:** Attacker lures victim to malicious page; page opens the target site in a popup and spams postMessage with window-redirect command carrying a javascript: URL. The widget's redirectTo sets document.location.href to the javascript: URI, executing attacker JS in the target origin, which reads the victim's email and submits the password-change form to take over the account.
**Insight:** When auditing postMessage origin checks, watch for `filter(...)[0]` or `find`-like patterns compared against `null` with `!==`; undefined slips through. Also flag any handler that passes attacker-controlled data into `location.href`, enabling javascript: URI XSS.