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:
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
> 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
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