# OK.ru: stored XSS in song name via payment gate

Stored XSS in a song name on OK.ru's music purchase flow, triggered via a crafted track id in the gift/payment redirect chain, hitting any user.

- Payout: hidden
- Severity: high
- Program: ok.ru
- Found by: 4lemon
- Disclosed: 2017-03-20
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/78260
- Library page: https://bugbountylibrary.com/r/h1%3A78260
- Tags: area:web domain:web impact:ato impact:integrity kind:bounty platform:hackerone sev:high tech:payment technique:param-pollution vuln:xss

**Target:** Music purchase/gift flow and paymentnew.ok.ru redirect
**Root cause:** Song names are stored with dangerous HTML tags and rendered unsanitized in the music purchase/payment redirect flow; the track id in the add-song request is attacker-controllable and not bound to the session.
**Steps:**
1. Open `http://ok.ru/gifts` and click any gift
2. Choose a recipient (self is fine)
3. On next screen click "add song"; under "my music" system says no songs available
4. Select any song, enable Burp interception, click "add"
5. In intercepted request change track id to the charged track `122884868317642`
6. Forward request; cascade of redirects fires the XSS
7. Extract the `paymentnew.ok.ru` request from proxy; opening that link in another browser triggers XSS without the creator's session
**How found:** Prior report established how to create a song with dangerous tags; researcher then looked for other places the charged track could be injected, found the gift/add-song flow and noticed the track id was freely changeable and the payment URL not session-bound.
**Exploitation:** Attacker crafts a song with malicious tags, then via the gift flow substitutes the track id in the add-song request to their charged track. The resulting paymentnew.ok.ru URL contains all needed data and is not session-bound, so it can be sent to any victim; opening it triggers the stored XSS.
**Escalation:** Session-independent payment URL allows targeting arbitrary users rather than only the attacker.
**Insight:** When a stored-XSS payload is already known, hunt for other endpoints that accept the same object id (gift, purchase, share flows) and check whether the resulting render URL is session-bound; unbound payment/redirect URLs turn self-XSS into mass stored XSS.