This is most importantly used by the proxy service. Without this handler, it would be trivial to hack content on another domain by an attacking context opening an IFRAME to a URL like: http://locked-domain.mygadgetdomain.com/gadgets/proxy?url=http://www.evil.com/read-data.html
The content would come back as Content-Type: text/html (per the proxy). Without Content-Disposition: attachment; the browser executes the contained code in the context of the locked domain (or any other domain on which the proxy is installed). The "p.txt" popup doesn't occur when a resource is being loaded as a child of a page, eg. <img src=" http://locked-domain.mygadgetdomain.com/gadgets/proxy?url=http://www.foo.com/image.gif "></img> RpcServlet and MakeRequestHandler are of course also proxies. They emit more controlled content, eg. application/json for mR, but we keep the Content-Disposition: header as an additional safeguard. We've seen esoteric IE-related attacks that this could help prevent, for instance (though I can't remember the details at this point :\). The "throw 1; < don't be evil' >" preamble is yet another mechanism we add to prevent remote code execution via this proxy. For the use case you're describing, I can think of two solutions using the existing setup: 1. For parent/child interaction, use the gadgets.rpc library. 2. If you need same-domain access, add another view to the gadget and have the gadget embed a copy of itself with &view=<the new one>. Note one caveat here: http://codesearch.google.com/#vLqwaqKFhb8/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ProxyHandler.java&q=isFlash%20file:shindig&l=166 For Content-Type="application/x-shockwave-flash" the Content-Disposition header is not added, due to a Flash 10 bug causing content emitted w/ it to appear as a big white box. --j On Wed, Sep 21, 2011 at 2:22 PM, Craig McClanahan <[email protected]>wrote: > In several places in Shindig (RpcServlet, MakeRequestHandler, > ConcatProxyServlet, ProxyHandler) Shindig sets this HTTP header in the > response, which (depending on what kind of call it is) triggers the browser > to attempt to download a file named "p.txt" instead of processing the > content. In one or two of these places, there is a comment stating that > this is being done to prevent XSS attacks. Could someone explain more > about > what kind of attacks this is designed to prevent? > > The reason I ask is that it disables some interesting use cases, including > one that came up recently -- we're using our (Jive's) implementation of > locked domains to prevent different gadgets from interfering with each > other > (or with the parent page). However, a need has come up for a gadget to be > able to render part of its UI from a remote server (inside an iframe inside > the gadget), but still interact with the client side gadget Javascript -- > which would normally be prevented by the locked domains. So, the gadget > author tried to use gadgets.io.getProxyUrl() around the URL in the "src" > attribute of the iframe, hoping that the inner iframe would now be from the > same domain as the gadget iframe. But the Content-Disposition header > causes > the browser to offer a file download instead of displaying the inner iframe > content. > > This particular use case would probably be better served ultimately by > leveraging a type="url" view, but I'm still curious what kinds of XSS > attacks this header was designed to prevent. > > Craig >
