Scrubbing external links should work fine. Just make sure that none of
your website is vulnerable to XSS. Users could leverage that to steal
each other's account info - and the fact that the session info is in
the URL doesn't help you out there -- maybe even makes you a little
bit more vulnerable.
If you were using cookies for session tracking and an XSS problem was
left unchecked you could at least raise the bar a bit by with the
'HttpOnly' attribute.
On Sun, 10 Oct 2004 09:55:14 -0400, Matt Fisher <mattfisher@comcast.net> wrote:
I think alot of sites are already wrapping their off-site links through an
exit page of some sorts, mostly so they can track click-throughs. You could
just strip it there ... call the exit page without the session ID, then the
exit page redirects to the other site.
Of, if you need the session info even on the exit page, simply script the
links into posted form submissions to the exit page instead.
Any forseeable issues with either ?
----- Original Message -----
From: "Antonio Varni" <antonio.varni@gmail.com>
To: "tie" <tie@ankh.morp.org>
Cc: <webappsec@securityfocus.com>
Sent: Friday, October 08, 2004 2:35 PM
Subject: Re: Auditing user session activity
As long as you are ok with your session information leaking out
through the referrer field after the user clicks off site.
On Wed, 06 Oct 2004 13:04:46 +0300, tie <tie@ankh.morp.org> wrote:
Hi Jeffrey,
The easiest way for you to go would be to start using URL (i.e. not
cookie based) sessions. In this way, you will have the Session ID track
inside your web server log file.
Then, in your login script you will just have to record username and
SID, upon successful login.
In this way, you can match the lines from the web server log against the
usernames recorded by your login script.
Regards,
tie
Koniszewski, Jeffrey wrote:
We are being asked by our customers to audit session activity so that
customers can answer the question, "Who is doing what?". Our current
implementation for this is to write audit records to the database. However,
I am having some second thoughts about this. This requires a database hit
for every non static URL access to the system. I'm not sure of the overall
runtime performance impact. Further, for enterprise class customers the
audit records are likely to exceed 2G per month. This creates a lot of data
cleanup to manage. In addition, reporting on this data may require a lot of
overhead from the system. Any thoughts on likely retention policies for such
audit data?
Users must log in to our application and we maintain session state. We
do integrate with Single Sign On products like Netegrity.
I am rolling around a couple of ideas:
One is that session audit is not a primary application problem and not
application data. Can this capability (session audit) be delivered by an
external application (IDS?, SSO product?) that is dedicated to do this type
of work. Then the customers that want the capability install it, probably
get a more professional implementation, and use it for other applications as
well. What security applications can provide this type of audit? Web server
logs can provide URL access information but don't know users. It seems that
whatever writes the audit would need to manage user logon as well to be able
to associate the user with the activity.
The second idea is, would I be better off using a file for the audit
information? This introduces a bunch of file management headaches in a
multiserver system but takes a load off the database, which is already our
bottleneck.
