On 02/01/2012 03:41 PM, Cory Spencer wrote:
Hi Dannon  and thanks for the response!

I can see the need to sanitize incoming HTTP request parameters that may have 
malicious content.  However, I'm unclear as to why this also needs to happen 
for HTML pages outputted by the Galaxy tools?  If they have been generated with 
sanitized HTTP request parameters, is there still a risk of an XSS 
attack?toolbox
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

Another one with:
>
alert('oh no!');
</

And finally one with:
script>

Taken individually they're meaningless, but run the concatenate datasets tool to reassemble that into:

<script
>
alert('oh no!');
</
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.

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.


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?


-Dannon

Thanks!

Cory

On 2012-02-01, at 12:01 PM, Dannon Baker wrote:

Hi Cory,

The new call to sanitize_html was introduced to more effectively prevent 
malicious content and possible XSS attacks, though I can't think off the top of 
my head why we couldn't allow style content.  I'll see what I can do about 
relaxing the filter a little.

Thanks!

-Dannon

On 01/30/2012 10:33 PM, Cory Spencer wrote:
Hello all -

One of the Galaxy tools I've been developing generates HTML output which I'd styled using a<style>...</style> 
  tag in the HTML header.  After updating to the latest Galaxy release earlier today, 
the<html>,<head>...</head>,<style>   and<body>   tags started to get stripped from the 
output, rendering previously CSS styled output rather unstylish.

Delving into things, I noticed a change committed in December that sanitizes the output 
for HTML files via a call to "sanitize_html":

     
https://bitbucket.org/galaxy/galaxy-central/changeset/35fee32991ce#chg-lib/galaxy/web/controllers/dataset.py

The added lines 381 ->   383 in the new file appear to be causing this new 
behaviour.

Is there any option for making this optional?  What was the rational behind 
stripping out these tags on outputted HTML files?

Thanks for any help!

Cory Spencer
___________________________________________________________
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:

   http://lists.bx.psu.edu/
___________________________________________________________
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:

http://lists.bx.psu.edu/

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

   http://lists.bx.psu.edu/
___________________________________________________________
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:

 http://lists.bx.psu.edu/

Reply via email to