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