Well... i developed a system that I find that can be useful to you... it
consists
in a little php file that is automatically included by the auto_prepend_file
php.ini
diretive. it checks for the existence of a unique session key in a cookie,
like
$_COOKIES['SID']. if it not exists, its generated and is SetCookie'd.
In every query, that script logs the requested URL, the user id (stored in
the
session), and the SID (generally an unique MD5 that identifies the current
client
session) and stores an array describing the session steps. Its like
php.ini
-------
auto_prepend_file = /foo/session_control.php
/foo/session_control.php
------------------------
if (isset($_SESSION['authed_client']))
{
if (!isset($_SESSION['steps']['sid']))
{
$_SESSION['steps']['sid'] = random_md5();
$_SESSION['steps']['user_id'] = $_SESSION['authed_client']['user_id'];
}
$session_step = &$_SESSION['steps']['data'][];
$session_step[time'] = date('U');
$session_step['url'] = $_SERVER['SCRIPT_FILENAME'];
$session_step['request'] = array_merge($_REQUEST, $_FILES);
}
here you can do 2 things:
1) make an "daemon" that will parse the php's session directory, open each
file and
look for session data, and write it to BD, and clean the session file and
rewrite it
(taking care of flock() session files). That saves the cost of make one DB
hit for
each http query that your site receives, and makes everything in one time,
what
is better.
2) create an "timeout" in the session_control.php based on last hit access.
[]'ss
Daniel
----- Original Message -----
From: "Leigh Morresi" <dgtlmoon@gmail.com>
To: <webappsec@securityfocus.com>
Sent: Friday, October 08, 2004 11:34 AM
Subject: Re: Auditing user session activity
i am just inserting a record into a mysql table at my work, the site
has been up for a couple of years and is still under 2gig, hard drive
space is cheap and mysql insert's dont cost very many cpu cycles :)
give it a go, if youre abstraction layer in your code for recording
the user activity is good enough you can always change it later
(presuming you have a good relationship with your client).
plus, if its already in a sql table you can do various lookups with it.
one thing i do is record the userid, datetime, page requested, cookie,
genseconds
where genseconds is how long it took to build that page with the PHP
code, this helps to profile the system later and detect any slow spots
(it has been VERY handy)
further to this, the people that use my site at work do a LOT of
data-entry, this data entry information is totally crucial, and while
i trust my code to handle it, should there ever be a problem all
HTTP_POST is also dumped to a file before the page is rendered, this
is done by serialising your http_post array
hope it helps, my work site is http://www.ttigroup.com.au
cheers
leigh
On Wed, 6 Oct 2004 08:07:34 -0400, Paul Berube <pberube@riskmetrics.com>
wrote:
We have a similar requirement for a product offering we support. To
address
this, the apache logs have been modified to include a user id obtained
from
the authentication system (Netegrity - Siteminder). The formats of the
logs
have also been adjusted so that they can be queried directly by a
relational
database server (in this case, Oracle).
By mapping the URLs to more meaningful page names, we are able to
exlcude
requests for things like images and style sheets and focus the reports
on
items that are meaningful to the consumers of the information. The
reports
also become more usable. We get some added benefits from this such as
historical page performance relative to request size and browser
utilization.
-----Original Message-----
From: Koniszewski, Jeffrey [mailto:JKoniszewski@Kronos.com]
Sent: Tuesday, October 05, 2004 4:10 PM
To: webappsec@securityfocus.com
Subject: Auditing user session activity
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.
