No it will break other stuff too , which already use redirection inplace. Just Let developer know that doing so will cause minor trust issue , and there is way to prevent it.
On Wed, Nov 24, 2010 at 1:40 AM, mdipierro <[email protected]> wrote: > checked the code and I do not see any counter-indication in adding > this check but one: > > If a user were to implement something like OpenID or CAS on top of > Auth, it would not work. What an OpenID provider does (redirect to > another side after login) is exactly what you are trying to prevent. > > So there is a tradeoff: is this security measure worth the > restriction? > > Massimo > > > On Nov 23, 12:38 pm, mdipierro <[email protected]> wrote: > > Actually I appreciate you raising this issue and this is a healthy > > discussion. > > Security issues are very important for everybody here so thank you for > > bringing this up. > > > > Although I do not think this is a major issue I agree that it should > > be avoided. > > One way to void is by adding this in one of your models: > > > > if request.controller=='default' and request.function=='user': > > if request.vars._next and request.vars._next.startswith('http'): > > del request.vars._next > > > > This will guarantee that only internal URLs can be passed via _next. > > Such mechanism could be made default behavior but I need to check that > > does not break anything. > > > > What do you think? What do other people think? > > > > Massimo > > > > On Nov 23, 11:45 am, Richard G <[email protected]> wrote: > > > > > Sorry, I am not saying that a web2py site is susceptible to CSRF. I > > > meant that a web2py site could be used 'in the process' to perform a > > > request that match these criteria on another site. > > > > > I find it weird to click on a link that is going to a legitimate > > > web2py site, and loads this legitimate web2py site, but then redirects > > > to an external site, only after I authenticate. (Based on using > > > authentication). > > > > > Again, a simple example scenario: > > > ie: I receive a fraudulent email, asking me to update password.. click > > > on it (yes.. first mistake), it redirects me to a legitimate web2py > > > site (I think, maybe the email was not fraudulent?), which on this > > > web2py site after I perform an action, redirects me to another site. > > > > > I agree that a few items have to fall in place for this abuse to > > > occur. But it still seems that at one point in the process, the user > > > has placed trust in our site, and then our site redirects them > > > elsewhere. > > > > > If the community believes form submission redirection based on the > > > forms variables is not a threat to our environment (It doesn't present > > > a tangible risk to our site, but I see it as posing a risk to our > > > site's trust, and thus our user's trust) then I'll stop arguing :) > > > > > Again, thanks! > > > > > On Nov 23, 10:57 am, mdipierro <[email protected]> wrote: > > > > > > What you suggest is indeed possible but... > > > > > > This is not an example of CRSF. CRSF is when a malicous site > redirects > > > > the user to a site where the user is already authenticated (a web2py > > > > site) and forces the user to perform action (for example submit a > > > > form). web2py prevents this by hiding a formkey in forms. > > > > > > When you suggest is an example of phishing. For the scam to work the > > > > victim would have to: > > > > 1) start from the malicious web site > > > > 2) login with a url provided by the malicious web site > > > > 3) provide credentials to a clone of the original web site. > > > > > > If a user falls for 1,2,3 there are much easier ways to implement > this > > > > scam even if web2py did not provide the next functionality and > without > > > > redirecting at all to the web2py site. > > > > I do not do believe this kind of phishing can be avoided. > > > > > > We can have a flag that checks whether _next is on a different domain > > > > but it would not prevent this type of scam, just this particular > > > > implementation. > > > > > > Massimo > > > > > > On Nov 23, 10:42 am, Richard G <[email protected]> wrote: > > > > > > > Howdy all, > > > > > > > In web2py I've noticed a number of methods in gluon/tools.py that > > > > > utilize client input to determine site flow: > > > > > if next == DEFAULT: > > > > > next = request.get_vars._next \ > > > > > or request.post_vars._next \ > > > > > or self.settings.login_next > > > > > > > and subsequent > > > > > if next and not next[0] == '/' and next[:4] != 'http': > > > > > next = self.url(next.replace('[id]', str(form.vars.id))) > > > > > redirect(next) > > > > > > > Methods: > > > > > AUTH: login , register, retieve_username, > > > > > reset_password_deprecated, reset_password, > > > > > request_reset_password(retrieve_password), change_password, > profile, > > > > > > > CRUD: update, delete > > > > > > > Too me this seems that a malicious individual can abuse the trust > of > > > > > our site to: > > > > > a) trick users into instantiating a CSRF from our site > > > > > b) providing information (credentials?) to a phishing site. > > > > > > > I'm sure we can all come up with some simple examples to provide > users > > > > > links that will redirect to a malicious site upon authentication. > > > > > Simple ex: ( > http://web2py-site/login?_next=http://web2py_site/login) > > > > > where the secondary site mimics original and identifies that the > > > > > authentication failed, and to reenter id/pw (even though we only > get > > > > > here after original site auth was success). > > > > > > > Unless I am missing something, the _next flow seems a strange > > > > > 'default' behaviour for a secure framework. > > > > > > > I'm wondering if the community has input / thoughts on my > (perceived?) > > > > > _next issue. > > > > > > > Thanks all!! > > > > >
