Thanks Dan! I am not sure about the dataset redirecting places other than ucsc and wormbase genome browser. By now, this can be done through Trackster right? Then I will probably disable the external redirecting.
any comments/suggestions. thanks, --/Vipin 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<http://galaxy.raetschlab.org/>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/
