I think this can to be default (security matters), but needs to be
configurable.
def avoid_external_next():
if request.controller=='default' and request.function=='user':
if request.vars._next and request.vars._next.startswith('http'):
del request.vars._next
at the models level:
if some_setup_storage.avoid_external_next: avoid_external_next()
than, this will always be default, and executed until the user sets
some_setup_storage.avoid_external_next = False
Or something like this.
2010/11/23 mdipierro <[email protected]>
> 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!!
> >
> >
>
--
Bruno Rocha
http://about.me/rochacbruno/bio
