Home Security display:none; doesn’t protect – Livestream Site Admin Menu

display:none; doesn’t protect – Livestream Site Admin Menu


Everyone is a fan of great music – I love electronic music. Some days ago a friend of mine sent me a link to a 24/7 “Monstercat” live channel. As I’m working for a livestreaming production company as well, I wanted to see how they’re doing stuff. Being highly curious I started checking out the source of the HTML code. I am mostly interested on how stuff like the chat is embedded etc. But quickly this caught my attention:

Monstercat: display: none; protected!
<div class=”admin”> securely… “protected”with display: none; attribute. [/sarcasm]
 At this point, 99 % of people interested in the source code will think: “Haha, cool. But the server won’t take my commands, because I’d need to authenticate”. But as a security ninja, I know how frontend developers think. (Okay, I must admit: I am the button smashing person – I like clicking buttons I am not supposed to click). I confirmed at least two functions to be functional without authentication – those are displaying ads (not so bad – but useless and disturbs viewer experience) and full-screen image or video (very bad):



I could have went further and try if it allows XSS, but as I mentioned before I did not want to disturb the viewers. I think that they should just protect the individual functions by the same authentication method they’re using for the poll and other functions already. Someone probably missed it for these features. And I can just suggest that they work together with a security firm to make an application audit.

Of course, I want to deliver proof as well:


On a side note: Stuff like this does make your company cool! I wish lessthan3 the best employees and hope that they’ll focus on security in the future as well.
Lessthan3 is hiring. If you're security expert, consider applying.


Disclosure Timeline

Sat, 7th February 2015: Notified LessThan3 via [email protected], [email protected], [email protected] The vendor was notified that this post will be released 21st Februrary 2015 or once it’s fixed.

Wed, 18th February 2015: The vendor confirmed the issue and fixed it quickly. We can confirm that this issue is fixed and the vulnerability reported here is no longer exploitable. We thank the vendor for the quick fix and prompt reaction.

Sat, 21th February 2015: The disclosure was automatically released.