Cross-Site Scripting Vulnerability

[catarak]

The widget is currently vulnerable to cross-site scripting and can access the parent document's cookies. I was trying to figure out how other editors like CodePen and JS Bin prevent this, and I stumbled across this helpful document.

[toolness]

Thanks for reporting this!

Sorry, I should have documented this... When creating the widget for Taeyoon's workshop I decided to punt on it because I thought that since the JS content is always provided by the page author rather than untrusted users, it should make XSS fairly hard to actually execute in practice. For instance, because there's currently no easy way to share one's "evil fork" of the original widget sketch, there isn't really a possibility of a stored or reflected XSS attack for most types of sketches. I could be mistaken, though...

That said, I should at least document this, so that folks who want to do unusual things with the code are aware of its limitations. I'd like to follow the "iframe hosted on a separate subdomain" approach eventually, and have designed the API between the widget and the child iframe to support that scenario. I'd also like to keep the current behavior optional so that folks who really want the widget to be 100% self-hosted can do so without needing to e.g. register their own separate subdomain or something like that. 😁

[catarak]

One scenario I thought of would be malicious intent on the author of the sketch: someone could embed a malicious sketch that autoplays on a blogging website like Wordpress or Tumblr, a person logged into one of these sites navigates to a blog post with the embedded sketch, and then the author of the sketch would have access to the person's cookies.

Or, a less complicated example, a beginner coder copying and pasting some code.

But yes, in practice, probably not a huge issue.