Passive stored XSS at broadcast room

Summary

The hacker found that a specially crafted app names could insert a small amount of data into an A tag's href in the "Broadcaster is running these apps: " chat text. Because of the character limit this required multiple successive clicks on different app names, and in the example utilised the room subject. Due to this and that the broadcaster would be required to use specially crafted apps, the scope of attack is limited. We quickly resolved this issue.

Summary##

Hey team,

I have discovered the passive stored XSS at broadcast room page. The vulnerable component is the running application link at the chat header.

JS function start_defchat contains object with many different parameters and the interesting one is app_info_json. This parameter contains information about applications running in the following format:

APP1_NAME|APP1_DETAILS_LINK,APP2_NAME|APP2_DETAILS_LINK

This parameter is used to construct the chat header part containing the information about broadcaster's running applications. Please look at the screenshot below: {F360611}. When the parameter is injected into the page source, the | symbol is unfiltered so an attacker can craft application with malicious name containing this symbol to forge the app link to the javascript protocol one. So crafting the app with name something|javascript:alert(), the following app_info_json parameter modification becomes possible:

something|javascript:alert()|APP1_DETAILS_LINK,APP2_NAME|APP2_DETAILS_LINK

In the case above, the chat header is modified to contain the following DOM element:

<p>You are running these apps: <a href="javascript:alert()" target="_blank">1</a></p>

The problem is that the app name length is limited to 32 symbols, that is not enough to craft real world evil XSS-payload. It can be bypassed if the attacker puts the JS-code in some other HTML-element under his control and then just reads and executes it from the evil link. Nevertheless, I could not construct so small payload to even read and execute text of some element. So I have split the payload into two and used two applications to execute it. In this case, the victim should click two links one after another, that decreases the vulnerability risk a little. Though I have add the notification code in my app that writes every 10 seconds that you can earn free tokens if click at both links :)

Steps To Reproduce:

1. Change your room title to alert('XSS by skavans at ' + document.domain)
2. Create and run some dummy app/bot with name 1|javascript:b='#roomtitle';0
3. Create and run second bot with name 2|javascript:eval($(b).text())
4. Start broadcasting and open the room using another account (victim)
5. Click at link 1, then at link 2. The xss will fire after that.

{F360624}

P.S.: The XSS fires at latest Chrome and Safari under Mac OS and does not work at the latest Firefox because of target="_blank" link's attribute. The Firefox opens new page after user clicks at such link so it is impossible to click at the second link.

The payload is now injected into the following password-protected room: https://chaturbate.com/b/h1tester1/ (password is hackerone).

Impact

Get full control under victim's account.