Content-Disposition: attachment;filename=p.txt

[Craig McClanahan <cr...@gmail.com>]

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

Re: Content-Disposition: attachment;filename=p.txt

[John Hjelmstad <fa...@google.com>]

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 <cr...@gmail.com>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
>