Gadget embed blocked by XSSAuditor due to URL in content

• Component: WebCore Misc.
• Status: RESOLVED DUPLICATE

[Moses Gunesch]

This bug might be more for the Sites team, but there's definitely a WebKit error being thrown that seems a bit suspect so I figured I'd start here.

I work for Animoto.com, a video generation service, which publishes a lot of video to the web via a Flash video player. We include a URL in our flashvars for our Pro users to be able to provide a linkback to their websites. While Chrome loads our player just fine with standard embeds, when embedded via a Gadget embed in Sites WebKit is choking on:

  "Refused to load an object. URL found within request"

Perhaps via XSSAuditor::canLoadObject().

Example -- if you hit this link soon you may see the problem, although the user will probably try to fix it: 
http://sites.google.com/a/1stnepean.ca/scout-troop/photos/2009-year-in-review.

(For comparison, a non-gadgets embed with URL in Flashvars that loads fine: http://www.davidmartschinske.com/)

I'm sure there are valid security reasons for calling XSSAuditor::canLoadObject to try and weed out risky content. However, passing a url into a swf's flashvars does not constitute a security risk in and of itself, as evidenced by Animoto's vanilla use case. Perhaps there's some way WebKit and the Sites team can improve this filtering a little, so that low-threat use cases aren't unnecessarily blocked.

Thanks for you time -- If this needs to be passed to the Sites team please let me know if there's a way to bypass their forum as an entry point. 

(OK to contact me offlist regarding this specific issue)

[Daniel Bates]

Created attachment 50164 [details]
Web archive of page

For preservation of page.

[Daniel Bates]

Created attachment 50165 [details]
HTML source for page

For preservation and convenience, just the HTML source for the page.

For completeness, the error message is:

Refused to load an object. URL found within request: "http://static.animoto.com/swf/w.swf?w=swf/vp1&e=1267732564&f=kbTH10UL1werpQ1xttXQow&d=206&m=a&r=w+s&i=m&ct=1st%20Nepean%20Scouts&cu=http://sites.google.com/site/1stnepeanscouts/parents&options=autostart/start_hq".

[Daniel Bates]

From briefly looking at the HTML source, this is an XSS attack since the page <http://jujo00obo2o234ungd3t8qjfcjrs3o6k-a-sites-opensocial.googleusercontent.com/gadgets/ifr> calls document.innerHTML with the contents of the anchor #up_embed_snippet. Moreover, among the <object>/<embed> parameters passed is allowscriptaccess="always", which would allow the flash content to execute arbitrary JavaScript scripts. In this case, such scripts would execute with respect to the domain for the iframe, http://jujo00obo2o234ungd3t8qjfcjrs3o6k-a-sites-opensocial.googleusercontent.com.

I am not too familiar with Google Gadgets or its workings. Adam may have more insight into this.

[Daniel Bates]

(In reply to comment #3)
> calls document.innerHTML with the contents of the anchor #up_embed_snippet.
I meant to say that it sets the innerHTML of the element whose id is "dest" to the contents of the anchor #up_embed_snippet.

[Adam Barth]

I think googleusercontent.com is meant to be a "throw away" domain that hosts untrusted content.  From your description it sounds like the gadget itself has an XSS vulnerability.  The gadget author should probably either fix their security vulnerability or opt out of XSS protection by sending the X-XSS-Protection: 0 header.  (Note that this control header is still under review at <https://bugs.webkit.org/show_bug.cgi?id=34436>.)

[Brent Fulgham]

This should be resolved by Bug 230499.

[Brent Fulgham]

*** This bug has been marked as a duplicate of bug 230499 ***