Hi Vipin,

Thank you for reporting this issue. 

This has to do with the way that the old-style (hard-coded) display 
applications were modified after introduction of roles to authorize access to 
an user's datasets that might be permission protected.

Ideally, with these old-style applications, much of the work that is being done 
upfront on history load would be backended to happen after the user clicks to 
view a dataset -- e.g. the viewport is being generated for all datasets in a 
history, example link: 
http://localhost:8080/datasets/190/display_at/ucsc_main?redirect_url=http%3A%2F%2Fgenome.ucsc.edu%2Fcgi-bin%2FhgTracks%3Fdb%3Dhg18%26position%3Dchr21%3A0-536870912%26hgt.customText%3D%25s&display_url=http%3A%2F%2Flocalhost%3A8080%2Froot%2Fdisplay_as%3Fid%3D190%26display_app%3Ducsc%26authz_method%3Ddisplay_at
 

If redesigned so that everything happens after the user clicks the link, I see 
no reason why the redirect_url functionality could not be removed. As it stands 
now, the redirect url is %s substituted with the URL-encoded value that will 
contain the authorized URL to access the dataset (e.g. 
http://localhost:8080/root/display_as?id=190&display_app=ucsc&authz_method=display_at),
 and then the user is redirected there.


I've added a Trello card (https://trello.com/c/uIctksud) for this issue.



In the mean time, however, I have committed a patch to the stable branch that 
will allow administrators to disable the use of the old-style display 
applications.


Thanks for using Galaxy,

Dan


On Mar 12, 2013, at 12:08 PM, Vipin TS wrote:

> Hello dev-members, 
> 
> We are trying to place our public Galaxy instance in a more secured manner, 
> Currently I am playing with few test cases about the redirection 
> vulnerabilities. 
> 
> The following link uses a URL variable called “redirect_url” to redirect a 
> user to a given page. While this variable is intended to only direct a user 
> to a trusted page, it fails to validate the provided value and therefore can 
> be used to redirect to any page.
> 
> http://localhost:8080/datasets/332056/display_at/ucsc_test?redirect_url=http://www.google.com&display_url=http://localhost:8080/root
> 
> This example redirects a user to Google, but it could just as easily be used 
> to direct a user to a page that contains any malware. 
> 
> To resolve the issue, may be validate all user controlled input, including 
> the GET request variables. If the input is intended to redirect a user, it 
> must be validated to ensure it only presents them with a page on the trusted 
> site. 
> 
> any comments or suggestions to work around this. 
> 
> thanks
> --/Vipin
> 
> Rätschlab, Computational biology dept. 
> Memorial Sloan-Kettering Cancer Center
> 
> ___________________________________________________________
> 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/

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

Reply via email to