You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Dan Dumont <dd...@us.ibm.com> on 2012/01/31 00:28:35 UTC
makeRequest content-disposition header to prevent XSS
I'm looking at the response from makeRequest and was reminded that we do:
// Always set Content-Disposition header as XSS prevention mechanism.
response.setHeader("Content-Disposition", "attachment;filename=p.txt"
);
I'm wondering what people think about not doing this in a shindig config
that uses locked domains and secure tokens?
This detail is crucial to being able to support file upload through the
makeRequest proxy in IE without the aid of a flash plugin.
RE: makeRequest content-disposition header to prevent XSS
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>-----Original Message-----
>From: Dan Dumont [mailto:ddumont@us.ibm.com]
>Sent: Tuesday, January 31, 2012 11:28 AM
>To: dev@shindig.apache.org
>Subject: Re: makeRequest content-disposition header to prevent XSS
>
>Well...
>
>If the shindig server is locked down and properly secured, what
>vulnerability is the Content-Disposition protecting against?
There was a relevant discussion about this on the dev list a while back:
http://markmail.org/message/yfyuhl52idhvcycv
It sounds like its more precautionary for makeRequest but could still be important.
>And if the shindig server is not locked down and secured, does the server
>owner really care about security?
>
>Can we just remove this protection altogether and just rely on the
>security of locked domains and secure tokens?
I'm assuming that the unparseable cruft which gets added to the response would cause you issues as well -- so would you need to remove that too?
I think in order to safely remove the safeguards that are in place we'd need to replace them with something else, and the only thing that comes to mind immediately for me would be security tokens. So I think if all of the various proxies required a valid security token to be present for any requests they process you might be able to start relaxing some of these safeguards. But of course that would mean that all gadgets would need to be rendered with security tokens -- and given the fact that there is specific support in the codebase now for rendering without tokens I'm guessing people might not want to go that route...
>
>
>
>From: Ryan J Baxter/Westford/IBM@Lotus
>To: dev@shindig.apache.org,
>Date: 01/31/2012 08:44 AM
>Subject: Re: makeRequest content-disposition header to prevent XSS
>
>
>
>Would this mean that your changes would only work on IE if locked domains
>are enabled and "secure" security tokens are turned on?
>
>
>-Ryan
>
>
>
>
>From: Dan Dumont/Westford/IBM@Lotus
>To: dev@shindig.apache.org,
>Date: 01/30/2012 06:29 PM
>Subject: makeRequest content-disposition header to prevent XSS
>
>
>
>I'm looking at the response from makeRequest and was reminded that we do:
> // Always set Content-Disposition header as XSS prevention mechanism.
> response.setHeader("Content-Disposition", "attachment;filename=p.txt"
>);
>
>I'm wondering what people think about not doing this in a shindig config
>that uses locked domains and secure tokens?
>This detail is crucial to being able to support file upload through the
>makeRequest proxy in IE without the aid of a flash plugin.
Re: makeRequest content-disposition header to prevent XSS
Posted by Dan Dumont <dd...@us.ibm.com>.
Well...
If the shindig server is locked down and properly secured, what
vulnerability is the Content-Disposition protecting against?
And if the shindig server is not locked down and secured, does the server
owner really care about security?
Can we just remove this protection altogether and just rely on the
security of locked domains and secure tokens?
From: Ryan J Baxter/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Date: 01/31/2012 08:44 AM
Subject: Re: makeRequest content-disposition header to prevent XSS
Would this mean that your changes would only work on IE if locked domains
are enabled and "secure" security tokens are turned on?
-Ryan
From: Dan Dumont/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Date: 01/30/2012 06:29 PM
Subject: makeRequest content-disposition header to prevent XSS
I'm looking at the response from makeRequest and was reminded that we do:
// Always set Content-Disposition header as XSS prevention mechanism.
response.setHeader("Content-Disposition", "attachment;filename=p.txt"
);
I'm wondering what people think about not doing this in a shindig config
that uses locked domains and secure tokens?
This detail is crucial to being able to support file upload through the
makeRequest proxy in IE without the aid of a flash plugin.
Re: makeRequest content-disposition header to prevent XSS
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Would this mean that your changes would only work on IE if locked domains
are enabled and "secure" security tokens are turned on?
-Ryan
From: Dan Dumont/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Date: 01/30/2012 06:29 PM
Subject: makeRequest content-disposition header to prevent XSS
I'm looking at the response from makeRequest and was reminded that we do:
// Always set Content-Disposition header as XSS prevention mechanism.
response.setHeader("Content-Disposition", "attachment;filename=p.txt"
);
I'm wondering what people think about not doing this in a shindig config
that uses locked domains and secure tokens?
This detail is crucial to being able to support file upload through the
makeRequest proxy in IE without the aid of a flash plugin.