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