1018683 - Stored XSS

Status: RESOLVED FIXED

(Webmaker Graveyard :: Thimble, defect)

Description

[panchocosil]

Attachment: Screen Shot 2014-06-01 at 3.59.57 AM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

Attacker:
1. Go to https://thimble.webmaker.org/ and login.
2. Add "payload" to main html "EDITOR" and click on "Save"

Payload:"><img src="x" onerror="prompt(document.domain)">

3. Then click on "Grab the link to edit your published page" and send Vulnerable URL to the victim.

Victim:
1. Victim open vulnerable link and if the victim was already login at thimble.webmaker.org attacker can grap the victims cookies.

My Vulnerable Link Proof: (this link can't be found with search)
https://thimble.webmaker.org/en-US/project/58133/edit

PD: See how this XSS is trigger at famozillathimblelivepreview.net(no cookies) and thimble.webmaker.org(with cookies) at the same time.


Actual results:

Attacker can grap users Cookies by sending the vulnerable link.


Expected results:

Add the moment of running a javascript this will load under famozillathimblelivepreview.net and not thimble.webmaker.org.

Comment 1

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

The idea behind the mozillathimblelivepreview.net and makes.org domains is that you can run any arbitrary javascript you want, but it doesn't matter because there's no user data stored on either domain.

As such I think this is a duplicate of bug 765340 but I'd like pomax to take a look at this and confirm my thinking.

Comment 2

[Pomax]

Curtis is correct. The code inside the preview is allowed to run any and all JS, as it runs on a different domain from webmaker.org - no user session information is available to it.

Comment 3

[Pomax]

rescind that. Looking at where the code gets triggered, it looks like the slowparse.js library that we use for verifying valid HTML5 is creating an active node that lets a prompt get executed. Let me look into this some more before calling this one.

Comment 4

[Pomax]

after some tests this seems to be very specifically caused by the <img> element's onerror property (I can't get it to trigger for a <script> element with an onerror, for instance) but it does appear that the slowparse library is creating active nodes in webmaker.org context, and despite being made inside loose DOM fragments, that onerror is causing a problem.

Comment 5

[Pomax]

The code that allows this to work is in Slowparse, a library for validating HTML5 markup. It was originally written for lovebomb.me, and got reused and maintained for Thimble. Slowparse runs through an HTML string and builds-and-discards nodes as it walks through the markup to see whether any build attempts throw errors. If they do, there were errors in the markup.

The code that lets this execution through is https://github.com/mozilla/thimble.webmaker.org/blob/master/public/friendlycode/vendor/slowparse/slowparse.js#L1639, which creates a new attribute map for attributes found in HTML tags. In this case, an image element is created, and its "src" attribute is set to a nonsense value, after which its "onerror" is added. As the src element was a nonsensical value, the browser calls onerror immediately, and code is executed in webmaker.org context.

Trying this with other elements shows similar behaviour (<audio> and <video> exhibit the same behaviour; <script> oddly enough does not).

Comment 6

[panchocosil]

Hello Pomax. Yes this XSS was a bit tricky but still easy to guess for an attacker. I'm happy to help.
this is a duplicate or not?
Francisco.

Comment 7

[Pomax]

I don't think it is, it looks like a usecase that slowparse was never designed to cope with. We'll be patching it today by turning off full attribute node instantiation for on[...] attributes during the linting pass in Thimble (since we don't lint JS, only HTML, so it doesn't really matter what's in an onerror, or an onchanged etc for that matter) so that should prevent this XSS from kicking in, even for already stored ones (should someone have already used this =). And while I'm sure someone would eventually try this exploit, it's still nicely found.

Comment 8

[panchocosil]

Thanks Mike :) and nice work on finding a solution quick. Let me know when this is fix to have a look.

Comment 9

[Pomax]

We patched https://thimble.mofostaging.net, and I can't reproduce the XSS on that anymore, so at least on the dev side unless you can find an opening still, this particular XSS-vector looks shut down.

Comment 10

[panchocosil]

I try different payloads and it look fix :) well done Mike. 

This bug was a "Store XSS" so that mean this was "sec-critical bug. 
According to https://wiki.mozilla.org/WebAppSec/Web_App_Severity_Ratings

Regards.

Comment 11

[Daniel Veditz [:dveditz]]

Webmaker sites are not part of the bounty program. We try to sandbox what we can but these are educational sites that intentionally host user-generated content. For a list of the eligible bounty sites please see http://www.mozilla.org/security/bug-bounty-faq-webapp.html#eligible-bugs

Lowering rating to sec-moderate because there are no particular sensitive assets on this site. Stored XSS can be up to critical, but that's envisioning sites with sensitive data.

Comment 13

[Jon Buckley [:jbuck]]

I think we can mark this resolved now, as the POC URL only shows the mozillathimblelivepreview.net URL now.