Session theft?

[Robert Tweed]

Does anyone know a good resource discussing the issues involved in session
theft? I've read a couple, but none that really address the problem apart
from acknowledging that it is a problem; you just don't seem to be able to
do much about it.

Does anyone have some tried-and-tested measures for preventing session
theft, that aren't already built into PHP? For that matter, what measures
_are_ already built into PHP? Are there significant differences between PHP4
and PHP5?

Damage-limiting exercises, such as re-authenticating before performing an
"important" action, aren't really my concern here. I've got admin systems
where virtually every action is sufficiently critical that ideally I would
re-authenticate on every page request, but that just wouldn't be practical.

Instead, I need to ensure that it is virtually impossible to steal a session
key in the first place. It doesn't have to be 100% secure, since nothing is,
but I need it to be very close, and know exactly where the risks are.

Also, what are the arguments for/against cookies versus querystring for
storing the session key? The obvious risk of putting it in the querystring
is that someone can read it off the screen, but I suppose I can block that
with frames and a bit of scripting. I can demand specific requirements like
JavaScript and cookies on the client side, since security is a greater
concern than compatibility.

- Robert

[Chris Hope]

Re: Session theft?

Robert Tweed wrote:
[color=blue]
> Does anyone know a good resource discussing the issues involved in
> session theft? I've read a couple, but none that really address the
> problem apart from acknowledging that it is a problem; you just don't
> seem to be able to do much about it.
>
> Does anyone have some tried-and-tested measures for preventing session
> theft, that aren't already built into PHP? For that matter, what
> measures _are_ already built into PHP? Are there significant
> differences between PHP4 and PHP5?
>
> Damage-limiting exercises, such as re-authenticating before performing
> an "important" action, aren't really my concern here. I've got admin
> systems where virtually every action is sufficiently critical that
> ideally I would re-authenticate on every page request, but that just
> wouldn't be practical.
>
> Instead, I need to ensure that it is virtually impossible to steal a
> session key in the first place. It doesn't have to be 100% secure,
> since nothing is, but I need it to be very close, and know exactly
> where the risks are.
>
> Also, what are the arguments for/against cookies versus querystring
> for storing the session key? The obvious risk of putting it in the
> querystring is that someone can read it off the screen, but I suppose
> I can block that with frames and a bit of scripting. I can demand
> specific requirements like JavaScript and cookies on the client side,
> since security is a greater concern than compatibility.[/color]

If you use a sufficiently long enough session code that's used in the
query string there's no way someone will be able to remember it by
looking at the address bar but it is possible for that query string to
be found in other ways eg a network sniffer looking for urls, and
Googe/Yahoo/Alex/etc toolbars which report urls back to the server.

If you use cookies the toolbars won't be able to use them but someone
sniffing for them can still get them.

If you use a combination of cookie/querystring and IP address the user
may be accessing the site through a proxy or other method where their
IP address changes with each request, or the person sniffing the
session may be in a network using the same IP address and can still get
in. So that method is bound to fail as well.

The only 100% reliable way I can see is to run the session through SSL.
That way any cookies or sessions passed in the query string are
encrypted between the client and browser.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

[Robert Tweed]

Re: Session theft?

"Chris Hope" <blackhole@elec trictoolbox.com > wrote in message
news:cptqqp$t9k $1@lust.ihug.co .nz...[color=blue]
>
> If you use a sufficiently long enough session code that's used in the
> query string there's no way someone will be able to remember it by
> looking at the address bar[/color]

Hardly something you can rely on. Someone could simply walk up to a PC that
had been left unattended and write it down. Or they could use a webcam. It's
very simple to copy something you can see.
[color=blue]
> but it is possible for that query string to
> be found in other ways eg a network sniffer looking for urls, and
> Googe/Yahoo/Alex/etc toolbars which report urls back to the server.[/color]

I also agree that is a more serious concern. These could also access cookies
too, although I have no idea what any of them actually _does_ store. Another
concern is cross-site scripting attacks, but this is not something I know a
great deal about. I'm not sure if it is something that is only possible
where the JavaScript sandbox is broken in a particular browser, or if it is
something that can be possible in a fully bug-free browser also.
[color=blue]
> If you use a combination of cookie/querystring and IP address the user
> may be accessing the site through a proxy or other method where their
> IP address changes with each request, or the person sniffing the
> session may be in a network using the same IP address and can still get
> in. So that method is bound to fail as well.[/color]

That is true, which is why I had not intended to rely solely on IP checking.
It's definitely still a good measure where it will work, so it's something
I'm going to make optional as part of my libraries and turn on for all
high-security sites. In those cases there would be no good reason for anyone
acccessing the site to have their IP address change between requests.

Doesn't solve the problem of people on the same network sharing an apparent
IP address, but at least it's one extra step of difficulty; it restricts
session thefts to within the same organisation. If there is some additional
way to tackle that problem, then that would cover all the bases.
[color=blue]
> The only 100% reliable way I can see is to run the session through SSL.
> That way any cookies or sessions passed in the query string are
> encrypted between the client and browser.[/color]

Doesn't stop people stealing them at the browser end, which is generally the
problem with session theft. All of the aforementioned theft techniques would
work whether the transport is secure or not. Obviously, for systems that
actually require this security, the connection will be over SSL anyway
because of the potential sensitivity of the data. There are still these
other attacks that need to be prevented. There are probably even a few more
attacks that I haven't thought of yet.

- Robert

[Chris Hope]

Re: Session theft?

Robert Tweed wrote:
[color=blue]
> "Chris Hope" <blackhole@elec trictoolbox.com > wrote in message
> news:cptqqp$t9k $1@lust.ihug.co .nz...[color=green]
>>
>> If you use a sufficiently long enough session code that's used in the
>> query string there's no way someone will be able to remember it by
>> looking at the address bar[/color]
>
> Hardly something you can rely on. Someone could simply walk up to a PC
> that had been left unattended and write it down. Or they could use a
> webcam. It's very simple to copy something you can see.
>[color=green]
>> but it is possible for that query string to
>> be found in other ways eg a network sniffer looking for urls, and
>> Googe/Yahoo/Alex/etc toolbars which report urls back to the server.[/color]
>
> I also agree that is a more serious concern. These could also access
> cookies too, although I have no idea what any of them actually _does_
> store. Another concern is cross-site scripting attacks, but this is
> not something I know a great deal about. I'm not sure if it is
> something that is only possible where the JavaScript sandbox is broken
> in a particular browser, or if it is something that can be possible in
> a fully bug-free browser also.
>[color=green]
>> If you use a combination of cookie/querystring and IP address the
>> user may be accessing the site through a proxy or other method where
>> their IP address changes with each request, or the person sniffing
>> the session may be in a network using the same IP address and can
>> still get in. So that method is bound to fail as well.[/color]
>
> That is true, which is why I had not intended to rely solely on IP
> checking. It's definitely still a good measure where it will work, so
> it's something I'm going to make optional as part of my libraries and
> turn on for all high-security sites. In those cases there would be no
> good reason for anyone acccessing the site to have their IP address
> change between requests.
>
> Doesn't solve the problem of people on the same network sharing an
> apparent IP address, but at least it's one extra step of difficulty;
> it restricts session thefts to within the same organisation. If there
> is some additional way to tackle that problem, then that would cover
> all the bases.
>[color=green]
>> The only 100% reliable way I can see is to run the session through
>> SSL. That way any cookies or sessions passed in the query string are
>> encrypted between the client and browser.[/color]
>
> Doesn't stop people stealing them at the browser end, which is
> generally the problem with session theft. All of the aforementioned
> theft techniques would work whether the transport is secure or not.
> Obviously, for systems that actually require this security, the
> connection will be over SSL anyway because of the potential
> sensitivity of the data. There are still these other attacks that need
> to be prevented. There are probably even a few more attacks that I
> haven't thought of yet.[/color]

If you use cookies rather than the querystring to pass sessions then it
at least makes it a little trickier to get the session code. I'm not
even sure in IE or Mozilla you can get the current value of a session
cookie (but I *do* know you can in Konqueror).

I have personally used the secure session with cookie and IP address
restriction trick myself before, using the same reaasoning as you that
the people accessing the system will always be coming through the same
IP address, and anyone coming from that IP address is going to be a
valid user.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

[Robert Tweed]

Re: Session theft?

"Chris Hope" <blackhole@elec trictoolbox.com > wrote in message
news:cpu0sq$78b $1@lust.ihug.co .nz...[color=blue]
>
> I have personally used the secure session with cookie and IP address
> restriction trick myself before, using the same reaasoning as you that
> the people accessing the system will always be coming through the same
> IP address, and anyone coming from that IP address is going to be a
> valid user.[/color]

Actually, that is not exactly my reasoning. The one big hole in IP checking
is where a company has a network setup such that all their users appear,
from the outside, to be coming from the same IP address. Since most
corporate crime occurs within the same organisation, that could be a problem
that needs to be addressed.

For example, say I have a system where the accounts dept have access to
credit card details, but the packing department does not have that access.
Each department would seem to be from the same IP address, so if Joe Packer
manages to aquire a session key from Jane in accounts then he will be able
to steal credit card details from the system without anyone knowing who it
was: any audit trail would point to Jane being the only person to have
accessed those details.

If there is no "one size fits all" solution to this particular problem, then
I suppose the only thing to do is force companies with a setup like this to
put their secure systems on an intranet, where internal IP addresses can be
used, but that could be quite limiting for most clients. The problem in
requiring a specific hardware setup to ensure that the system is secure is
that it may conflict with any large organisation's existing network security
policies and thus any requested changes would be unlikely to happen (e.g.,
ensuring that proxies include the true forwarded IP address in the headers).

Clearly at this point we're down to a "low risk" threat anyway, since the
attack is now quite difficult, but it would be nice if there were an
altogether better solution to this problem.

- Robert

[Chris Hope]

Re: Session theft?

Robert Tweed wrote:
[color=blue]
> "Chris Hope" <blackhole@elec trictoolbox.com > wrote in message
> news:cpu0sq$78b $1@lust.ihug.co .nz...[color=green]
>>
>> I have personally used the secure session with cookie and IP address
>> restriction trick myself before, using the same reaasoning as you
>> that the people accessing the system will always be coming through
>> the same IP address, and anyone coming from that IP address is going
>> to be a valid user.[/color]
>
> Actually, that is not exactly my reasoning. The one big hole in IP
> checking is where a compan has a network setup such that all their
> users appear, from the outside, to be coming from the same IP address.
> Since most corporate crime occurs within the same organisation, that
> could be a problem that needs to be addressed.[/color]

I realised that. In my situation it was OK because there were only a
limited number of people in the company accessing the site and they
were all valid users of the system and there wasn't anything like CC
numbers involved.

[snip]

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

[cyberhorse]

Re: Session theft?

What about throwing in the browser/screen configuration checking as
well as the IP when tracking a session. I know that especially in
working environments the workstation configurations are largely the
same, but it will still add one more step that could help.

A possible sollution could be to provide a separate program, which can
generate a unique machine ID, and ask for that ID as well, when asking
for their username/password. If security is a major issue, this could
be helpful.

[Robert Tweed]

Re: Session theft?

"cyberhorse " <cyberhorse@gma il.com> wrote in message
news:1103274364 .462754.210970@ f14g2000cwb.goo glegroups.com.. .[color=blue]
> What about throwing in the browser/screen configuration checking as
> well as the IP when tracking a session. I know that especially in
> working environments the workstation configurations are largely the
> same, but it will still add one more step that could help.[/color]

Might be worth saving the user-agent along with the IP address, but I agree
that it's hardly going to make a big difference compared to just checking
the IP address.
[color=blue]
> A possible sollution could be to provide a separate program, which can
> generate a unique machine ID, and ask for that ID as well, when asking
> for their username/password. If security is a major issue, this could
> be helpful.[/color]

Sounds very easy to forge. Why couldn't you just copy that ID, the same way
as the session key?

- Robert

[Dani CS]

Re: Session theft?

Robert Tweed wrote:[color=blue]
> Does anyone know a good resource discussing the issues involved in session
> theft? I've read a couple, but none that really address the problem apart
> from acknowledging that it is a problem; you just don't seem to be able to
> do much about it.[/color]

Session theft can be avoided with some scripting both in the client and
the server, at the expense of making the 'back' button unusable on the
client's side. Let me explain before you think I'm mad :-)

The trick is not to use one _fixed_ session id during the wholesession,
but rather a _different_ session id for every client->server interaction
(i.e. every time a new page is fetched from the server). In other words,
multiple single-use session-ids for each session.

A (single use) session id can be calculated from previos session ids and
a secret shared between client and server (e.g. the password used for
authentication of the user). This means that client and server must be
in sync. Along with each request, the client must send the next session
id that the server expects. This is why the 'back' button must not be
used: the session id of the previous page would be sent to the server,
but the server expects to get the session id for a new page. (I haven't
worked at fixing this at the moment.)

The generated session ids must be difficult to guess just by looking at
previous session ids, so a one-way hash can be very useful (my
implementation uses MD5).

To summarise, the steps are:

1.
- The (still anonymous) client requests the login page.
- The server sends back a login page, along with a random session id.

2.
- The user fills in a login/password (or similar).
- The client generates a new session id by mixing the received session
id and the password given by the user (i.e. new_sid =
hash(old_sid+pa ssword)). The username and the new session id are sent to
the server.
- The server gets the username, generates its own new session id by
mixing the (previously sent) old session id with the local copy of the
password. If both client and server agree on the same new session id,
the user is logged in. The server sends back to the client a welcome
page. The generated new session id is stored on the server.

3.
- When the (already authenticated) client requests another page, it uses
a new session id built from the previous session id and the shared
secret: new_sid = hash(previous_s id+password).
- The server works out its own new session id (same process of mixing
the previous sid and the shared secret). If both client and server agree
on the same new_sid, then the client is allowed to see the next page
requested.

4. Repeat #3 above until finished.


This method effectively prevents session theft when the thief has not
access to the computer. Each session id sniffed on the net is useless,
because the server will accept it exactly one time. The session thief
will find it very difficult to guess the next session id, because it
depends on the secret shared by the legitimate user and the server.

The main concern (appart from breaking the 'back' button) is hiding the
password on the client to prevent cross-site scripting attacks that
could retrieve it. This is caused by the need to keep the shared secret
in the client's memory to generate each one of the new session ids.


A working implementation (sorry, no demo) can be seen at
<http://mipagina.ath.cx/diario/adm/>. You can poke at the client-side
javascript to see the details. If enough people are interested I will
set up a demo site with multiple users and make the full source code
available (probably GPL'ed).

Any (constructive) comments will be welcome.


<snip rest of interesting OP>

[Robert Tweed]

Re: Session theft?

"Dani CS" <contusiones.me rluza@yahoo.es. quita-la-merluza> wrote in message
news:cpuaqq$khj $1@news.ya.com. ..[color=blue]
>
> The trick is not to use one _fixed_ session id during the wholesession,
> but rather a _different_ session id for every client->server interaction
> (i.e. every time a new page is fetched from the server). In other words,
> multiple single-use session-ids for each session.[/color]

Interesting. I've been thinking more about the problem myself, and what you
are talking about is very similar to what I've been considering. I haven't
really thought the idea through very far, so I'll have to read-over your
post properly and then get back with some comments when I've had a chance to
digest it properly. In fact, I was kinda hoping someone would have already
ironed out the problems in a system like this, so I wouldn't have to put so
much thought into it ;-)

- Robert

[Daniel Tryba]

Re: Session theft?

Dani CS <contusiones.me rluza@yahoo.es. quita-la-merluza> wrote:
[one time sessionids]

Pretty simple and yet effective. But if one depends on clientside
scripting one might use a public/private encryption (there are RSA
scripts for both javascript and php), only problem is remembering the
public key on the client. Alternatively one time keys could be generated
serverside kinda like your scheme.

[Norman Peelman]

Re: Session theft?

"Dani CS" <contusiones.me rluza@yahoo.es. quita-la-merluza> wrote in message
news:cpuaqq$khj $1@news.ya.com. ..[color=blue]
> Robert Tweed wrote:[color=green]
> > Does anyone know a good resource discussing the issues involved in[/color][/color]
session[color=blue][color=green]
> > theft? I've read a couple, but none that really address the problem[/color][/color]
apart[color=blue][color=green]
> > from acknowledging that it is a problem; you just don't seem to be able[/color][/color]
to[color=blue][color=green]
> > do much about it.[/color]
>
> Session theft can be avoided with some scripting both in the client and
> the server, at the expense of making the 'back' button unusable on the
> client's side. Let me explain before you think I'm mad :-)
>
> The trick is not to use one _fixed_ session id during the wholesession,
> but rather a _different_ session id for every client->server interaction
> (i.e. every time a new page is fetched from the server). In other words,
> multiple single-use session-ids for each session.
>
> A (single use) session id can be calculated from previos session ids and
> a secret shared between client and server (e.g. the password used for
> authentication of the user). This means that client and server must be
> in sync. Along with each request, the client must send the next session
> id that the server expects. This is why the 'back' button must not be
> used: the session id of the previous page would be sent to the server,
> but the server expects to get the session id for a new page. (I haven't
> worked at fixing this at the moment.)
>
> The generated session ids must be difficult to guess just by looking at
> previous session ids, so a one-way hash can be very useful (my
> implementation uses MD5).
>
> To summarise, the steps are:
>
> 1.
> - The (still anonymous) client requests the login page.
> - The server sends back a login page, along with a random session id.
>
> 2.
> - The user fills in a login/password (or similar).
> - The client generates a new session id by mixing the received session
> id and the password given by the user (i.e. new_sid =
> hash(old_sid+pa ssword)). The username and the new session id are sent to
> the server.
> - The server gets the username, generates its own new session id by
> mixing the (previously sent) old session id with the local copy of the
> password. If both client and server agree on the same new session id,
> the user is logged in. The server sends back to the client a welcome
> page. The generated new session id is stored on the server.
>
> 3.
> - When the (already authenticated) client requests another page, it uses
> a new session id built from the previous session id and the shared
> secret: new_sid = hash(previous_s id+password).
> - The server works out its own new session id (same process of mixing
> the previous sid and the shared secret). If both client and server agree
> on the same new_sid, then the client is allowed to see the next page
> requested.
>
> 4. Repeat #3 above until finished.
>
>
> This method effectively prevents session theft when the thief has not
> access to the computer. Each session id sniffed on the net is useless,
> because the server will accept it exactly one time. The session thief
> will find it very difficult to guess the next session id, because it
> depends on the secret shared by the legitimate user and the server.
>
> The main concern (appart from breaking the 'back' button) is hiding the
> password on the client to prevent cross-site scripting attacks that
> could retrieve it. This is caused by the need to keep the shared secret
> in the client's memory to generate each one of the new session ids.
>
>
> A working implementation (sorry, no demo) can be seen at
> <http://mipagina.ath.cx/diario/adm/>. You can poke at the client-side
> javascript to see the details. If enough people are interested I will
> set up a demo site with multiple users and make the full source code
> available (probably GPL'ed).
>
> Any (constructive) comments will be welcome.
>
>
> <snip rest of interesting OP>[/color]

I too have given this idea some thought over the past couple years. I
would add to this with making sure that the first time the SID's don't match
that the user is immediatelty logged out. Unless the hacker is on wireless
w/laptop or sitting right in front of the computer and managed to figure out
the next SID and then managed to jump in before the real user reloads a
page, it should be a very secure system. Second, set the sessions to
time-out after a few minutes (or whatever you deem fit for normal usage.
Then you prevent a hacker from waiting too long before attempting access.

Norm
---
FREE Avatar Hosting at

https://www.easyavatar.com

[Michael Fesser]

Re: Session theft?

.oO(Dani CS)
[color=blue]
>- When the (already authenticated) client requests another page, it uses
>a new session id built from the previous session id and the shared
>secret: new_sid = hash(previous_s id+password).[/color]

How is the password stored on the client, so that it will be accessible
on every page to calculate the next ID, but not send to the server along
with each request?

Micha

[Johnny Elvers]

Re: Session theft?

Dani CS wrote:
[color=blue]
> The trick is not to use one _fixed_ session id during the wholesession,
> but rather a _different_ session id for every client->server interaction
> (i.e. every time a new page is fetched from the server). In other words,
> multiple single-use session-ids for each session.
>
> A (single use) session id can be calculated from previos session ids and
> a secret shared between client and server (e.g. the password used for
> authentication of the user). This means that client and server must be
> in sync. Along with each request, the client must send the next session
> id that the server expects. This is why the 'back' button must not be
> used: the session id of the previous page would be sent to the server,
> but the server expects to get the session id for a new page. (I haven't
> worked at fixing this at the moment.)
>
> The generated session ids must be difficult to guess just by looking at
> previous session ids, so a one-way hash can be very useful (my
> implementation uses MD5).
>[/color]

Why the clientside calculations really ? Why not just have the server
generate a new UID that the client must use for the next page view ?

And if you store the generated session history you'll have some extra
options.

- Let's say a UID was stolen or sniffed. When the user tries to access
the next page he will be asked to login, sending along the invalid UID.
If login succeed it will take precedence over the latest used UID's and
you'll have a track from the real users, former, invalid UID up to the
latest.

- If you want to relax security a bit, you could allow the last or the
last n sessions to be valid within a time span, allowing for Back button
functionality.

/Johnny

[Dani CS]

Re: Session theft?

Michael Fesser wrote:[color=blue]
> .oO(Dani CS)
>
>[color=green]
>>- When the (already authenticated) client requests another page, it uses
>>a new session id built from the previous session id and the shared
>>secret: new_sid = hash(previous_s id+password).[/color]
>
>
> How is the password stored on the client, so that it will be accessible
> on every page to calculate the next ID, but not send to the server along
> with each request?[/color]

You can check the working code to see that the password is MD5-hashed
when entered and then stored in a global javascript variable on the top
of a frameset. This frameset provides a getNextSid() function that makes
the calculations, and functions to output links and forms in the child
document so that they use the correct next_sid.
[color=blue]
>
> Micha[/color]