A tool whitelist is an interesting idea that deserves more thought, but for now I'm going to add an option to the galaxy configuration to easily enable or disable the extended html filtering entirely. It'll be enabled by default, but this should make it easier for the administrators of local Galaxy instances in the case where you have custom tools that need to do fancy things and have other security and access controls in place. -Dannon On Mar 2, 2012, at 4:05 AM, Ayton Meintjes wrote:
This breaks some of the tools we're developing, although in our case it's harder to fix because it's Javascript we're inserting.
I understand the security concerns though. Any advice on a more secure way to allow particular content? Perhaps a whitelist of allowed scripts?
On Wed, Feb 1, 2012 at 23:58, Cory Spencer <cspencer@sprocket.org> wrote:
On 2012-02-01, at 1:33 PM, Dannon Baker wrote:
With Galaxy's toolbox at hand you could generate invalid HTML from plain text components. A simple example, but consider the following:
Upload one plain text file with the content: <script
....
Change the type of this dataset to html and there's your attack. If you tried to upload this, we'd interpret it as malicious HTML and discard it. As separate datasets, it's impossible to tell. Given Galaxy's powerful text manipulation tools you could write just about whatever you wanted using Galaxy itself and get it in the system as a (seemingly) valid tool-generated dataset. Now, with the outbound sanitation on any dataset served as "text/html" it doesn't matter and it gets handled prior to serving.
Okay, I follow you there. That's a good example, thank you!
Another option we discussed would be to trust all tool generated HTML, disallow changing the datatype of anything *to* html, and so on, but that approach comes with its own problems.
In the case of the tool we're working on, this option is probably what would have worked best.
If anything, would it be possible to make this sort of sanitization controllable via a configuration file option?
I'm rather hesitant to put in a disable option for a security feature, though you're more than welcome to pop those two lines out of your instance. I think the best path forward is probably relaxing the filter a bit, the initial pass was somewhat draconian. Would relaxing the filter to allow style content to pass through work for your needs?
Yes, we've already commented it out for the time being. :) Relaxing the filter would be a good improvement so far as we're concerned. I'd be happy to keep in contact with you during the process so that we can find the happy middle ground between security and usability.
Thanks again!
Cory ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:
-- Computational Biology Group University of Cape Town South Africa