Session theft?

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

Robert Tweed wrote:

> 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.

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/

"Chris Hope" <blackhole@electrictoolbox.com> wrote in message
news:cptqqp$t9k$1@lust.ihug.co.nz...
>
> 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

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.

> 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.

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.

> 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.

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.

> 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.

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

Robert Tweed wrote:

> "Chris Hope" <blackhole@electrictoolbox.com> wrote in message
> news:cptqqp$t9k$1@lust.ihug.co.nz...
>>
>> 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
>
> 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.
>
>> 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.
>
> 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.
>
>> 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.
>
> 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.
>
>> 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.
>
> 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.

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/

"Chris Hope" <blackhole@electrictoolbox.com> wrote in message
news:cpu0sq$78b$1@lust.ihug.co.nz...
>
> 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.

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

Robert Tweed wrote:

> "Chris Hope" <blackhole@electrictoolbox.com> wrote in message
> news:cpu0sq$78b$1@lust.ihug.co.nz...
>>
>> 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.
>
> 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.

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/

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.

"cyberhorse" <cyberhorse@gmail.com> wrote in message
news:1103274364.462754.210970@f14g2000cwb.googlegr oups.com...
> 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.

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.

> 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.

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

- Robert

Robert Tweed wrote:
> 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.

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+password)). 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_sid+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>

"Dani CS" <contusiones.merluza@yahoo.es.quita-la-merluza> wrote in message
news:cpuaqq$khj$1@news.ya.com...
>
> 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.

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