Gabe,

I think an easier way to think about this issue
is to condense the attack catagories you
mentioned. Let's first define some terms:

Session Hijacking - involves an attacker using
captured, brute forced, or reverse-engineered
authentication tokens to seize control of a
legitimate user's web application session while
that user is logged into the application. This
usually results in the legitimate user losing
access or functionality to the current web
session, while the attacker is able to perform
all normal application functions with the same
privileges of the legitimate user. This class of
attacks usually relies on a combination of other
simpler Session Management attacks (Brute Force,
Session Replay)
(http://www.owasp.org/projects/asac/sm-
sessionhijacking.shtml)

Session Replay - A web application is vulnerable
to a replay attack if a user's authentication
tokens are captured or intercepted by an
attacker. A replay attack involving a web
application means that an attacker directly uses
these authentication tokens (e.g., session ID in
URL, cookie, etc.) to obtain or create service
to the user's account while bypassing normal
user authentication (logging in with the
appropriate username or password).
(http://www.owasp.org/projects/asac/sm-
sessionreplay.shtml)

Session Brute Force - Brute-Forcing involves
performing an exhaustive key search of a web
application authentication token's key space in
order to find a legitimate token that can be
used to gain access. This usually takes the form
of grinding through a list of usernames and
passwords, looking for a particular response
that indicates a valid session was found.
(http://www.owasp.org/projects/asac/sm-
bruteforce.shtml)

So in using these terms, I think your
definitions 1 and 4 fall into Session Replay,
and 2 and 4 fall into Brute Force. In terms of
how to steal (not brute force) the actual
session cookie/session ID, there are numerous
ways besides CSS and network interception
including trojan horses, DNS cache poisoning,
breaking into proxy server logs, etc.

So if you agree with the above terms, automated
grinding to find the session token is brute
force. Using it to obtain service is Session
Replay. And using it (with session replay) to
seize control, privilege, or degrade another
user's session is hijacking. Of course if the
session token is one-time use, then you would
have to use statistical prediction and go for a
"preemptive replay" attack. Granted, there are
many derivations on the methods for performing
each of these types of attacks.

Does anyone think "preemptive replay" needs to
be it's own OWASP attack catagory? Or perhaps
just altering the current ASAC would do.

-dave

-----Original Message-----
From: Gabriel Lawrence
[mailto:gabebutterflysecurity.com]
Sent: Monday, February 11, 2002 1:53 PM
To: webappsecsecurityfocus.com; owaspowasp.org
Subject: Attackers Perspective...

I've been thinking about a bunch of the
strategies for session cookies
that have been proposed and one thing still
leaves me uncomfortable with
a bunch of them. I'd like to see some more
thought focused on how people
attack web applications - because based on my
thinking about attacking a
lot of these strategies appear to not add any
value...

So, here's what I'm thinking. How do you go
about stealing a session on
a web application? I've identified a few ways,
I'd like to hear other
peoples thoughts. Then maybe we can look at
these attacks and come up
with ways to deal with them.

1. Upgrade my account:
        In this attack I already have some kind of an
account in the web
application. I just slip some JavaScript in
using a Cross Site Scripting
vulnerability that will secretly post your
session cookie to a web
server I control. This allows me to steal the
session simply by setting
a cookie in my attackers browser.

2. Brute force:
        Cookies are a limited size. I just start
marching through all the
possible values hoping to find one.

3. Statistical prediction:
        I'm able to look at a large set of session
cookies and I can identify
some patterns, this allows me to come up with a
smaller set of possible
values, then I brute force those.

4. Watching the network:
        I find some way to view the http traffic
running between a valid user
and the application. From this I'm able to slurp
up valid session
cookies and then I can just set them in my
browser and I'm in...

Ignoring attacks outside of session cookies,
does anyone have other
session cookie attack ideas? Got better names
for the attacks I've
outlined?

-gabe

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]