On Mar 11, 2009, at 5:16 PM, Bilgin Ibryam wrote:
Quoting David E Jones <david.jo...@hotwaxmedia.com>:
You may be describing a well known issue, and one that is part of the
way the externalLoginKey works (so it is not likely to change). The
externalLoginKey allows you to automatically login to another webapp
without a username/password. In order to do this a new login key is
generated with EVERY request to the server in order to keep it's life
cycle pretty short. As long as it is on a secure/https page when it
goes to the browser it is pretty safe, but it generally comes back to
the server in a URL and so needs to be invalidated immediately so
that
it cannot be used again, as that is pretty easy to snoop.
So, to make it not work is easy: just have a page open in your
browser
that has a stale externalLoginKey in its URLS.
1. load a page where you are authenticated in tab/window A
2. right click on a link within the webapp and open it in tab/
window B
3. go back to tab/window A and click on any link that goes to a
webapp
that you are not already logged into and that has an externalLoginKey
parameter
The externalLoginKey will be stale, so that auto-login will fail and
you will be presented with the login form.
I was wondering why externalLoginKey is not a cookie? Probably
because of security reasons, but if it was a cookie, it would have a
short life cycle as JSESSIONID cookie (the cookie value will be
updated on every request) and working on many browser tabs at the
same time wouldn't require multiple logins.
That's a good idea. In theory even if the externalLoginKey were
updated with every request the cookie in the browser (if there is only
one cookie) then it would be updated and even other tabs and windows
should use that with their request. There is a still a chance that 2
requests could end up in a race condition where one gets in and causes
the server-side key to update even though the other request is on its
way out and gets there after the server key is updated, but still
using the old key from the client cookie.
Anyway, this is a good idea and the only reason I can think of to not
do it is the one you mentioned, ie the security of cookies. It is very
easy to spoof cookie domain names and get cookies from other sites...
it's a "feature" of cookies that causes problems.
There may be ways to protect a cookie better, like encrypting it, but
even if the key is secret on the server a fast attacker, or one that
finds a session that has been idle for a while, then it can still get
the encrypted value and the server wouldn't know if it came from a
valid client or a forged one.
Sorry, was thinking out loud... I'm not sure if there is a good enough
way to protect the cookie... and considering that this would be
substitution for the username and password, I'm not sure I like it (I
even have reservations about the current externalLoginKey... but a
better alternative is tricky...).
-David
