How Galaxy prevents security attacks?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

How Galaxy prevents security attacks?

burdettn
Hi,
   we'd like to host a version of Galaxy, but our security team have identified some potential areas that could be subjected to attack. I was wondering if Galaxy had mechanism in place to avoid the following issues:


Cross site scripting

Description

Cross site scripting (also referred to as XSS) is a vulnerability that allows an attacker to send malicious code (usually in the form of Javascript) to another user. Because a browser cannot know if the script should be trusted or not, it will execute the script in the user context allowing the attacker to access any cookies or session tokens retained by the browser

Impact

Malicious users may inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable application to fool a user in order to gather data from them. An attacker can steal the session cookie and take over the account, impersonating the user. It is also possible to modify the content of the page presented to the user

Affected URLS and parameters:

·         /capaibl/visualization/list

o   update_time param

·         /capaibl/history/delete_current

o   purge

·         /capaibl/history/list

o   F-deleted

o   F-name

·         /capaibl/user/edit_address

o    Address_id

o    User_id

·         /capaibl/edit_info

o    Username

o    User_id

·         Capaibl/user/logout

o    Referrer

·         /capaibl/user/manage_user_info

o    Change_password_button

o    Cntrller

o    Current

o    Email

o    Id

o    Message

o    Status

o    Username

o    User_id

·         /capaibl/user/reset_password

o    Message

·         /caibl/user/set_default_permissions

o    cntrller


Denial of Service

Description of attack

During security testing we used two different types of crawlers and both caused the system to crash. Without access to the backend it is hard to document the reason, however, an educated guess would be that there is limited memory available to sessions. When crawlers ask for multiple sessions, this could cause the webserver to allocate all its memory and crash.

Attack scenario

1.  Open burpsuite and start the proxy function

2.  Open a browser and set burpsuite as the proxy

3.  Navigate to the milxcloud homepage

4.  Turn on the spider function within burpsuite

The website will crash within seconds.


There is an entry in universe_wsgi.ini 

# Galaxy encodes various internal values when these values will be output in
# some format (for example, in a URL or cookie).  You should set a key to be
# used by the algorithm that encodes and decodes these values.  It can be any
# string.  If left unchanged, anyone could construct a cookie that would grant
# them access to others' sessions.
#id_secret = USING THE DEFAULT IS NOT SECURE!

Would this help address the XSS issue?


Thanks for any information
Neil

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

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/
Reply | Threaded
Open this post in threaded view
|

Re: How Galaxy prevents security attacks?

Dannon Baker-2
Hi Neil,

Galaxy definitely takes this sort of thing very seriously.  I'll take a look at the possible XSS locations identified in the report and verify whether or not they're actually vulnerable.

For Denial of Service attacks, I'd suggest that this should be handled by the upstream proxy.

You should *always* change id_secret in your universe_wsgi.ini, but it wouldn't be affecting your XSS tests.


On Wed, Jun 18, 2014 at 8:48 AM, <[hidden email]> wrote:
Hi,
   we'd like to host a version of Galaxy, but our security team have identified some potential areas that could be subjected to attack. I was wondering if Galaxy had mechanism in place to avoid the following issues:


Cross site scripting

Description

Cross site scripting (also referred to as XSS) is a vulnerability that allows an attacker to send malicious code (usually in the form of Javascript) to another user. Because a browser cannot know if the script should be trusted or not, it will execute the script in the user context allowing the attacker to access any cookies or session tokens retained by the browser

Impact

Malicious users may inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable application to fool a user in order to gather data from them. An attacker can steal the session cookie and take over the account, impersonating the user. It is also possible to modify the content of the page presented to the user

Affected URLS and parameters:

·         /capaibl/visualization/list

o   update_time param

·         /capaibl/history/delete_current

o   purge

·         /capaibl/history/list

o   F-deleted

o   F-name

·         /capaibl/user/edit_address

o    Address_id

o    User_id

·         /capaibl/edit_info

o    Username

o    User_id

·         Capaibl/user/logout

o    Referrer

·         /capaibl/user/manage_user_info

o    Change_password_button

o    Cntrller

o    Current

o    Email

o    Id

o    Message

o    Status

o    Username

o    User_id

·         /capaibl/user/reset_password

o    Message

·         /caibl/user/set_default_permissions

o    cntrller


Denial of Service

Description of attack

During security testing we used two different types of crawlers and both caused the system to crash. Without access to the backend it is hard to document the reason, however, an educated guess would be that there is limited memory available to sessions. When crawlers ask for multiple sessions, this could cause the webserver to allocate all its memory and crash.

Attack scenario

1.  Open burpsuite and start the proxy function

2.  Open a browser and set burpsuite as the proxy

3.  Navigate to the milxcloud homepage

4.  Turn on the spider function within burpsuite

The website will crash within seconds.


There is an entry in universe_wsgi.ini 

# Galaxy encodes various internal values when these values will be output in
# some format (for example, in a URL or cookie).  You should set a key to be
# used by the algorithm that encodes and decodes these values.  It can be any
# string.  If left unchanged, anyone could construct a cookie that would grant
# them access to others' sessions.
#id_secret = USING THE DEFAULT IS NOT SECURE!

Would this help address the XSS issue?


Thanks for any information
Neil

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

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/


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

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/
Reply | Threaded
Open this post in threaded view
|

Re: How Galaxy prevents security attacks?

burdettn

Thanks Dannon,

                                The team gave this example (regarding XSS), Hope it helps

 

Example: open firefox, log into galaxy and paste the following URL:

152.83.54.10/capaibl/visualization/list?async=false&f-free-text-search=e&f-sharing=All&f-tags=All&f-title=All&page=1&show_item_checkboxes=false&sort=-update_time_</script><script>alert("you have been powned, right now an attacker would be stealing your cookie information")</script><img src="http://i.imgur.com/2ZTC4gh.jpg "/>

 

 

Neil

From: Dannon Baker [mailto:[hidden email]]
Sent: Wednesday, 18 June 2014 10:55 PM
To: Burdett, Neil (CCI, Herston - RBWH)
Cc: Galaxy Dev
Subject: Re: [galaxy-dev] How Galaxy prevents security attacks?

 

Hi Neil,

 

Galaxy definitely takes this sort of thing very seriously.  I'll take a look at the possible XSS locations identified in the report and verify whether or not they're actually vulnerable.

 

For Denial of Service attacks, I'd suggest that this should be handled by the upstream proxy.

 

You should *always* change id_secret in your universe_wsgi.ini, but it wouldn't be affecting your XSS tests.

 

On Wed, Jun 18, 2014 at 8:48 AM, <[hidden email]> wrote:

Hi,

   we'd like to host a version of Galaxy, but our security team have identified some potential areas that could be subjected to attack. I was wondering if Galaxy had mechanism in place to avoid the following issues:

 

 

Cross site scripting

Description

Cross site scripting (also referred to as XSS) is a vulnerability that allows an attacker to send malicious code (usually in the form of Javascript) to another user. Because a browser cannot know if the script should be trusted or not, it will execute the script in the user context allowing the attacker to access any cookies or session tokens retained by the browser

Impact

Malicious users may inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable application to fool a user in order to gather data from them. An attacker can steal the session cookie and take over the account, impersonating the user. It is also possible to modify the content of the page presented to the user

Affected URLS and parameters:

·         /capaibl/visualization/list

o   update_time param

·         /capaibl/history/delete_current

o   purge

·         /capaibl/history/list

o   F-deleted

o   F-name

·         /capaibl/user/edit_address

o    Address_id

o    User_id

·         /capaibl/edit_info

o    Username

o    User_id

·         Capaibl/user/logout

o    Referrer

·         /capaibl/user/manage_user_info

o    Change_password_button

o    Cntrller

o    Current

o    Email

o    Id

o    Message

o    Status

o    Username

o    User_id

·         /capaibl/user/reset_password

o    Message

·         /caibl/user/set_default_permissions

o    cntrller

 

Denial of Service

Description of attack

During security testing we used two different types of crawlers and both caused the system to crash. Without access to the backend it is hard to document the reason, however, an educated guess would be that there is limited memory available to sessions. When crawlers ask for multiple sessions, this could cause the webserver to allocate all its memory and crash.

Attack scenario

1.  Open burpsuite and start the proxy function

2.  Open a browser and set burpsuite as the proxy

3.  Navigate to the milxcloud homepage

4.  Turn on the spider function within burpsuite

The website will crash within seconds.

 

 

There is an entry in universe_wsgi.ini 

 

# Galaxy encodes various internal values when these values will be output in

# some format (for example, in a URL or cookie).  You should set a key to be

# used by the algorithm that encodes and decodes these values.  It can be any

# string.  If left unchanged, anyone could construct a cookie that would grant

# them access to others' sessions.

#id_secret = USING THE DEFAULT IS NOT SECURE!

 

Would this help address the XSS issue?

 

 

Thanks for any information

Neil


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

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

 


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

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/
Reply | Threaded
Open this post in threaded view
|

Re: How Galaxy prevents security attacks?

Dannon Baker-2
One more detail I need -- which version of galaxy was your test suite run against?


On Wed, Jun 18, 2014 at 8:59 AM, <[hidden email]> wrote:

Thanks Dannon,

                                The team gave this example (regarding XSS), Hope it helps

 

Example: open firefox, log into galaxy and paste the following URL:

152.83.54.10/capaibl/visualization/list?async=false&f-free-text-search=e&f-sharing=All&f-tags=All&f-title=All&page=1&show_item_checkboxes=false&sort=-update_time_</script><script>alert("you have been powned, right now an attacker would be stealing your cookie information")</script><img src="http://i.imgur.com/2ZTC4gh.jpg "/>

 

 

Neil

From: Dannon Baker [mailto:[hidden email]]
Sent: Wednesday, 18 June 2014 10:55 PM
To: Burdett, Neil (CCI, Herston - RBWH)
Cc: Galaxy Dev
Subject: Re: [galaxy-dev] How Galaxy prevents security attacks?

 

Hi Neil,

 

Galaxy definitely takes this sort of thing very seriously.  I'll take a look at the possible XSS locations identified in the report and verify whether or not they're actually vulnerable.

 

For Denial of Service attacks, I'd suggest that this should be handled by the upstream proxy.

 

You should *always* change id_secret in your universe_wsgi.ini, but it wouldn't be affecting your XSS tests.

 

On Wed, Jun 18, 2014 at 8:48 AM, <[hidden email]> wrote:

Hi,

   we'd like to host a version of Galaxy, but our security team have identified some potential areas that could be subjected to attack. I was wondering if Galaxy had mechanism in place to avoid the following issues:

 

 

Cross site scripting

Description

Cross site scripting (also referred to as XSS) is a vulnerability that allows an attacker to send malicious code (usually in the form of Javascript) to another user. Because a browser cannot know if the script should be trusted or not, it will execute the script in the user context allowing the attacker to access any cookies or session tokens retained by the browser

Impact

Malicious users may inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable application to fool a user in order to gather data from them. An attacker can steal the session cookie and take over the account, impersonating the user. It is also possible to modify the content of the page presented to the user

Affected URLS and parameters:

·         /capaibl/visualization/list

o   update_time param

·         /capaibl/history/delete_current

o   purge

·         /capaibl/history/list

o   F-deleted

o   F-name

·         /capaibl/user/edit_address

o    Address_id

o    User_id

·         /capaibl/edit_info

o    Username

o    User_id

·         Capaibl/user/logout

o    Referrer

·         /capaibl/user/manage_user_info

o    Change_password_button

o    Cntrller

o    Current

o    Email

o    Id

o    Message

o    Status

o    Username

o    User_id

·         /capaibl/user/reset_password

o    Message

·         /caibl/user/set_default_permissions

o    cntrller

 

Denial of Service

Description of attack

During security testing we used two different types of crawlers and both caused the system to crash. Without access to the backend it is hard to document the reason, however, an educated guess would be that there is limited memory available to sessions. When crawlers ask for multiple sessions, this could cause the webserver to allocate all its memory and crash.

Attack scenario

1.  Open burpsuite and start the proxy function

2.  Open a browser and set burpsuite as the proxy

3.  Navigate to the milxcloud homepage

4.  Turn on the spider function within burpsuite

The website will crash within seconds.

 

 

There is an entry in universe_wsgi.ini 

 

# Galaxy encodes various internal values when these values will be output in

# some format (for example, in a URL or cookie).  You should set a key to be

# used by the algorithm that encodes and decodes these values.  It can be any

# string.  If left unchanged, anyone could construct a cookie that would grant

# them access to others' sessions.

#id_secret = USING THE DEFAULT IS NOT SECURE!

 

Would this help address the XSS issue?

 

 

Thanks for any information

Neil


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

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

 



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

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/