Re: Session ID Abuse

["Paul" <paul () mnwebhost net>]

On Thursday, February 12, 2004 at 4:21 PM "Johnny GoLightly" wrote:

> Hi all,
>
> I have some quesitons regarding session id's.
>
> Consider the following scenario:
>
> User requires access to a web application for a long period of time with
inactivity. Therefore assume that sessionID never expires.
> Session information stored on web server (or application server) says that
this user has read-only access to the information shown on the page which is
extracted from a database.
> The application auto refreshes the page on the browser every 15 minutes
with updated info that other users may have entered in the preceding period.
> Is it possible for:
>
> 1.  Another user to change the session information on the server and
change access from read only to write (by knowing the session id)?
> 2.  Knowing the session id (perhaps from info on the URL) can one create
another session from another browser using the same session ID?
> 3.  How can you effectively limit concurrent access to only 1 session?
>
> 4.  If client side certificates were to be used, could you create another
session from another browser once the first session was authenticated?  ie,
how do you restrict the access to only one browser?
> 5.  If you are using server side validation for all user invoked queries,
is it still possible to force data into the application to elevate your
role?  Assume that user roles are clearly defined in the db.
> 6.  If a user with high privileges (such as write to db) leaves a
workstation unattended with no session timeout, are there any controls that
one could put in place to still validate the user is the privilged user
after a period of time?  for example keep session active, but to make any
changes application must validate information on a usb key?
> 7.  How do you choose between session ID's tagged in URL, and Session IDs
in cookies?  How do you restrict the information in either URL or cookie so
that users can't use this info to abuse the application?
> Thanks
>
> Johnny

First let me state that I do not claim to be a security expect, and I always
seek professional advice when in doubt.  That said I am a developer (both
desktop and web), and I code in most common languages and I always keep
security in mind when coding.

Anyways, the answers are going to vary slightly depending on the operating
system, the web server and the server-side language being used.  Even the
database is being used will have implications on security.  Some are more
prone to attack than others.

The quick answer to all your questions is yes, those are all possible means
to try and hijack sessions and otherwise compromise an application.   There
are tools out there to aid hackers in exploiting webapps, like changing
http-headers on the fly and other means of trying to figure out how this are
working.

Your #7 question, that really depends on the web-server your using, or more
specify the parser (like ASP, PHP, Perl).  Neither one is more secure really
than the other.  The server-side session tracking using cookies is a little
cleaner to the end-user and adds a step for the hacker to overcome, but it
is only a step.  Generally you'll want to add your own authentication
methods and not rely solely on checking a session variables to see if they
are still authenticated.  This can be done by simply taking a hash of their
IP address and browser agent (both available in the HTTP headers) and save
that in a session variable, then each time they request a page you create a
new hash based upon the same two (or more) things and you can compare that
against the hash in the session variable.  If they match then it's probably
the same user coming back.  Just make sure you only store that hash in a
session variable or in a database, don't store it in a cookie or it's
worthless.

And your #5 question.  Depending on how well you scrub the user input, there
still could still be ways to manipulate the query.  Some systems are more
vulnerable that others.   For example, PHP automatically strips semi-colons
from SQL statements.  Again not knowing what backend your going to be using,
you can scrub and validate the users input all you want, but what if I
connect directly to your database?  Either by brute-force or by sniffing
packets someone could pull a credential from somewhere and start their
exploit.

Your #6 question is interesting, are you talking about a USB device (kind of
like the old HASP keys)?  Obviously that would require more control over the
client computer (which I assume you have) because you'd probably have to
write a browser plug-in to get that information from the client PC and
verify it and get it to the server.

If you can, please provide more detailed information about what OS,
web-server, db, language you'll be building this out of and maybe we can
provide more insight.  Thanks for your great questions.

Regards,

-Paul

PS.  If you haven't already, check out http://www.owasp.org/ and their
infamous list of the top ten vulnerabilities.