zope.pluggableauth and "camefrom" information in login form not an absolute URL
Hi, The SessionCredentialsPlugin will redirect to a login form whenever a user needs to be authenticated. The URL to this login form will have a "camefrom" query string, where the "camefrom" is the path-information to the originally requested view. When the credentials provided by the user are correct, the login form will use the camefrom information to redirect back to that original view. Ideally (a.k.a. according to the HTTP spec.), the camefrom should be an absolute URL, not just a path like the SessionCredentialsPlugin now does. I'd like to fix and release zope.pluggableauth with the following patch applied - unless of course there's compelling reasons not to do this: --- trunk/src/zope/pluggableauth/plugins/session.py 2011-02-07 10:33:25.643791415 +0100 +++ branches/janjaapdriessen-camefrom-fix/src/zope/pluggableauth/plugins/session.py 2011-02-07 10:40:12.301790203 +0100 @@ -308,7 +308,7 @@ # Better to add the query string, if present query = request.get('QUERY_STRING') - camefrom = '/'.join([request.getURL(path_only=True)] + stack) + camefrom = '/'.join([request.getURL()] + stack) if query: camefrom = camefrom + '?' + query url = '%s/@@%s?%s' % (absoluteURL(site, request), regards, jw
Hello, I'm not sure whether you open up a security hole there. Imagine that someone does a http://yoursite.com/@@loginform.html?camefrom=http://mysite.com We ended up with storing the camefrom URL in a session variable. On Mon, 07 Feb 2011 10:42:33 +0100 you wrote:
Hi,
The SessionCredentialsPlugin will redirect to a login form whenever a user needs to be authenticated. The URL to this login form will have a "camefrom" query string, where the "camefrom" is the path-information to the originally requested view.
When the credentials provided by the user are correct, the login form will use the camefrom information to redirect back to that original view.
Ideally (a.k.a. according to the HTTP spec.), the camefrom should be an absolute URL, not just a path like the SessionCredentialsPlugin now does.
I'd like to fix and release zope.pluggableauth with the following patch applied - unless of course there's compelling reasons not to do this:
--- trunk/src/zope/pluggableauth/plugins/session.py 2011-02-07 10:33:25.643791415 +0100 +++ branches/janjaapdriessen-camefrom-fix/src/zope/pluggableauth/plugins/session.py 2011-02-07 10:40:12.301790203 +0100 @@ -308,7 +308,7 @@ # Better to add the query string, if present query = request.get('QUERY_STRING')
- camefrom = '/'.join([request.getURL(path_only=True)] + stack) + camefrom = '/'.join([request.getURL()] + stack) if query: camefrom = camefrom + '?' + query url = '%s/@@%s?%s' % (absoluteURL(site, request),
regards, jw
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
-- Best regards, Adam GROSZER -- Quote of the day: Man who falls in vat of molten optical glass makes spectacle of self.
On 2/7/11 12:04 PM, Adam GROSZER wrote:
Hello,
I'm not sure whether you open up a security hole there. Imagine that someone does a http://yoursite.com/@@loginform.html?camefrom=http://mysite.com We ended up with storing the camefrom URL in a session variable.
The redirect method in the zope publisher checks whether the redirect is "trusted" to go to a different host. The trusted arguments is "False" by default. I think will catch this situation just fine. Or doesn't it? regards, jw
Hello, On Mon, 07 Feb 2011 12:15:40 +0100 you wrote:
On 2/7/11 12:04 PM, Adam GROSZER wrote:
Hello,
I'm not sure whether you open up a security hole there. Imagine that someone does a http://yoursite.com/@@loginform.html?camefrom=http://mysite.com We ended up with storing the camefrom URL in a session variable.
The redirect method in the zope publisher checks whether the redirect is "trusted" to go to a different host. The trusted arguments is "False" by default. I think will catch this situation just fine. Or doesn't it?
Well on the second look, it should. Then it might have been because Roger was just unsure about the zope.publisher version? He is on holiday this week... See r105125. Let's wait what the other say.
On 7 February 2011 12:29, Adam GROSZER <agroszer@gmail.com> wrote:
Hello,
On Mon, 07 Feb 2011 12:15:40 +0100 you wrote:
On 2/7/11 12:04 PM, Adam GROSZER wrote:
Hello,
I'm not sure whether you open up a security hole there. Imagine that someone does a http://yoursite.com/@@loginform.html?camefrom=http://mysite.com We ended up with storing the camefrom URL in a session variable.
The redirect method in the zope publisher checks whether the redirect is "trusted" to go to a different host. The trusted arguments is "False" by default. I think will catch this situation just fine. Or doesn't it?
Well on the second look, it should. Then it might have been because Roger was just unsure about the zope.publisher version? He is on holiday this week... See r105125.
Let's wait what the other say.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
I can confirm that a redirect to an injected camefrom URL yields a ValueError: Untrusted redirect to host 'www.example.com:80' not allowed. -- Jan-Jaap Driessen
Hi all
information in login form not an absolute URL
Hello,
On Mon, 07 Feb 2011 12:15:40 +0100 you wrote:
On 2/7/11 12:04 PM, Adam GROSZER wrote:
Hello,
I'm not sure whether you open up a security hole there. Imagine that someone does a http://yoursite.com/@@loginform.html?camefrom=http://mysite.com We ended up with storing the camefrom URL in a session variable.
The redirect method in the zope publisher checks whether
the redirect
is "trusted" to go to a different host. The trusted arguments is "False" by default. I think will catch this situation just fine. Or doesn't it?
Well on the second look, it should. Then it might have been because Roger was just unsure about the zope.publisher version? He is on holiday this week... See r105125.
Adam, I have nothing to do with zope.pluggableauth. You probably mean z3c.authenticator and friends. Jan, why not use the same pattern like I changed to in z3c.authenticator. There the camefrom request part was replaced by session handling. On the other side, I think your changes are fine since, I guess someone from gocept, a long time ago, fixed and protected the redirect method. btw, there was also a proposal about improvments on old zope3 website. I don't konw if this proposals are still there and accessible. Regards Roger Ineichen
Let's wait what the other say.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
On 2/7/11 18:03 PM, Roger wrote:
why not use the same pattern like I changed to in z3c.authenticator. There the camefrom request part was replaced by session handling.
On the other side, I think your changes are fine since, I guess someone from gocept, a long time ago, fixed and protected the redirect method.
Ok, thanks for your feedback! I applied the patch, added a test just to show a redirect to a suspicious URL will by default not work and released zope.pluggableauth 1.3 regards, jw
participants (4)
-
Adam GROSZER -
Jan-Jaap Driessen -
Jan-Wijbrand Kolman -
Roger