shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ciancetta, Jesse E." <>
Subject RE: makeRequest content-disposition header to prevent XSS
Date Tue, 31 Jan 2012 20:44:47 GMT
>-----Original Message-----
>From: Dan Dumont []
>Sent: Tuesday, January 31, 2012 11:28 AM
>Subject: Re: makeRequest content-disposition header to prevent XSS
>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:

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
>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?
>From:   Dan Dumont/Westford/IBM@Lotus
>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.

View raw message