On Tuesday, October 7, 2003, at 02:11 PM, Scott Cadillac wrote:
Hi Roland,
This is certainly turning into an interesting thread.
So, just to be clear, you are assigning a separate "custom" session-cookie
with a successful logon?
It's a site registration cookie, yes. They have a long term one written when they initially register, and when they login, it's re-set and a session cookie of the same value is set. When they arrive at areas that need to be secure, These are checked to make sure they both exist and are equal.
And the absence of this additional custom session-cookie indicates a
possible instance of session hijacking/tailgating correct? So you force them
to logon.
yup. That's the idea.
Good idea.
But yes, if your findings are correct (and I'm following correctly what you
are describing) and you did manage to change the Witango_UserReference
cookie value, I suppose the Witango Server is just trying to be efficient
and re-use the previously allocated memory space on the Server with the
"new" Witango_UserReference key value you assigned - especially if all this
happens within a single execution of a TAF.
Well, I didn't really want to write over the witango_userreference, I wanted to kill it and cause witango to assign a new one.
I set it to expire in -1 days but when I called <@userreference> it was still there. So I went and overwrote it with gibberish, looked at the cookie to verify, and then called <@userreference> - like the energizer bunny, it was still ticking. So I looked in the witango.ini and removed the altuserkey value, which was IP address, restarted, and the darned userreference was still persisting. Something is keeping it in place more than the cookie, and it's surely stronger than a cookie.
In theory you should be able to "reset" the memory space for the User
Variables with the new key value - but my guess is just that nobody has
taken it this far before, so the Server design might not accommodate it.
Just a guess of course...
---
So, in the meantime (until we hear more suggestions and insight), here a
couple of thoughts:
~~ Suggestion one: Break up the Witango_UserReference re-assignment into two
TAF calls. The first TAF removes the Witango_UserReference cookie altogether
(and the _UserReference argument), then a redirect calls the second TAF that
will assign a new key value automatically. The Server, in theory, will act
like the second request is from a completely new User and will allocate new
memory space for their User Variables.
~~ Suggestion two: If you are already relying on a "custom" session-cookie
anyway, why bother with the <@USERREFERENCEARGUMENT> Meta Tag at all?
will be stripping userref arguments out, but the hole is still there, even if it's a bit more obscure. That eliminates accidental tailgating and session sharing.
Removing <@USERREFERENCEARGUMENT> from your pages is the best preventive
measure you can employ to prevent session hijack/tailgating to begin with.
It means the Server has to rely on session-cookies, but if you're using them
already, then you're not loosing anything.
Like I've mentioned in the past, I don't use <@USERREFERENCEARGUMENT> at all
and never have these issues. Having Users turn on session-cookies as a
requirement for logon is not much to ask - and so far has never been a
problem.
You're right, and I initially stripped out the userreference arguments, but put them back in on a request. (long story).
I'll use this discussion to make the case for stripping them back out, BUT
it says that if someone has a userreferenceargument somewhere, whether by sniffing headers or the odd application has one, then sessions can be popped open for sharing. Very improbable, but as they say about earthquakes here in California: improbable is inevitable.
I think we should be able to kill a session for security reasons, or at least to strip a browser of it's ability to step into a session.
corollary subject: the header thing was a bust. I was trying to limit caching by placing a header, but in this version of witango server/plug in, a header crashes the server. My next strategy to keep things from living too long is to put timestamps in the urls and to check for aged timestamps.
Just about security and privacy. I've seen a few cases of accidental sharing of sessions and it's a bit scary.
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
