RE: [web2py] Re: Potential site trust abuse with default web2py setting?
I think I'd prefer to see the checking for external redirects in the redirect()
function itself.
Perhaps on a redirect() to an external page the user should be taken to a
warning page that they are about to exit the web2py site, and ask them if
they're sure they want to continue.
This could be made bypassable via an extra parameter to redirect, or a site
wide safe list of external redirects.
From: web2py@googlegroups.com [mailto:web...@googlegroups.com] On Behalf Of
Bruno Rocha
Sent: Tuesday, November 23, 2010 1:00 PM
To: web2py@googlegroups.com
Subject: Re: [web2py] Re: Potential site trust abuse with default web2py
setting?
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 mdipie...@cs.depaul.edumailto:mdipie...@cs.depaul.edu
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
richard.ga...@gmail.commailto:richard.ga...@gmail.com 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
mdipie...@cs.depaul.edumailto:mdipie...@cs.depaul.edu 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
richard.ga...@gmail.commailto:richard.ga...@gmail.com 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.idhttp://form.vars.id)))
redirect(next)
Methods:
AUTH: login , register, retieve_username
Re: [web2py] Re: Potential site trust abuse with default web2py setting?
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 mdipie...@cs.depaul.edu
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 richard.ga...@gmail.com 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 mdipie...@cs.depaul.edu 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 richard.ga...@gmail.com 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
Re: [web2py] Re: Potential site trust abuse with default web2py setting?
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 mdipie...@cs.depaul.edu 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 mdipie...@cs.depaul.edu 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 richard.ga...@gmail.com 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 mdipie...@cs.depaul.edu 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 richard.ga...@gmail.com 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
