Recently I worked with a PHP framework and saw that it was putting html in a cookie to read it from javascript (don't ask me why).
I tried to alter the html in the cookie by putting an alert('bingo') instruction and it worked. Can this behaviour be used as main channel for XSS assuming no other server side vulnerabilities are present?
In other words: how can an attacker use this behaviour given this is the only known vector?
Assuming there are no other vulnerabilities in the website I don't believe this is exploitable, as in order to exploit this the attacker would first need to be able to control the contents of that particular cookie. (Which would almost certainly require the use of some other vulnerability.)
However, if there are other vulnerabilities (whether they be client or server-side) in the site this unusual feature could be used to make the impact of those vulnerabilities significantly worse.
For example, if any page on the site is ever loaded over HTTP, a MITM attacker would be able to create a semi-persistent XSS attack by setting the value of this cookie, possibly using the attack to steal data that would normally only be accessible from a more secure HTTPS page (such as cookies with the secure flag set).
Or if the site is vulnerable to a Cookie Tossing attack, that same attack (which would normally only be useful for session fixation and the like) would also open you up to a full-blown XSS attack against affected users.
All-in-all, while this practice may not be terrible I still wouldn't advise it, especially since there are much better ways of getting HTML content from the server onto a page that don't expose you to any new threats.
I'm not defending the practice, but it's unlikely to be an XSS vector. In order for it to be, an attacker would have to be able to control the contents of the victim's cookie. In reflected XSS, this is usually done by putting malicious code in a URL parameter and having the victim click on it. There isn't a similar way to set the victim's cookies without already running code in the target context. Similarly, for this to be a vector for persisted XSS, the attacker would need to be able to set some state in the server that would end up in the victim's cookie. This is not impossible but it would be an unusual use of a cookie.
