Bug 35802 - Gadget embed blocked by XSSAuditor due to URL in content
Summary: Gadget embed blocked by XSSAuditor due to URL in content
Status: RESOLVED DUPLICATE of bug 230499
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://sites.google.com/a/1stnepean.c...
Keywords: XSSAuditor
Depends on:
Reported: 2010-03-05 11:57 PST by Moses Gunesch
Modified: 2021-09-21 14:01 PDT (History)
3 users (show)

See Also:

Web archive of page (428.12 KB, application/x-webarchive)
2010-03-06 19:10 PST, Daniel Bates
no flags Details
HTML source for page (18.97 KB, text/html)
2010-03-06 19:12 PST, Daniel Bates
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Moses Gunesch 2010-03-05 11:57:01 PST
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: 

(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)
Comment 1 Daniel Bates 2010-03-06 19:10:45 PST
Created attachment 50164 [details]
Web archive of page

For preservation of page.
Comment 2 Daniel Bates 2010-03-06 19:12:20 PST
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".
Comment 3 Daniel Bates 2010-03-06 20:10:55 PST
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.
Comment 4 Daniel Bates 2010-03-06 20:18:11 PST
(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.
Comment 5 Adam Barth 2010-03-06 20:32:21 PST
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>.)
Comment 6 Brent Fulgham 2021-09-21 14:01:27 PDT
This should be resolved by Bug 230499.
Comment 7 Brent Fulgham 2021-09-21 14:01:42 PDT

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