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!! > >
