By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,949 Members | 921 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,949 IT Pros & Developers. It's quick & easy.

Session theft?

P: n/a
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
Jul 17 '05 #1
Share this Question
Share on Google+
30 Replies


P: n/a
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/
Jul 17 '05 #2

P: n/a
"Chris Hope" <bl*******@electrictoolbox.com> wrote in message
news:cp**********@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
Jul 17 '05 #3

P: n/a
Robert Tweed wrote:
"Chris Hope" <bl*******@electrictoolbox.com> wrote in message
news:cp**********@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/
Jul 17 '05 #4

P: n/a
"Chris Hope" <bl*******@electrictoolbox.com> wrote in message
news:cp**********@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
Jul 17 '05 #5

P: n/a
Robert Tweed wrote:
"Chris Hope" <bl*******@electrictoolbox.com> wrote in message
news:cp**********@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/
Jul 17 '05 #6

P: n/a
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.

Jul 17 '05 #7

P: n/a
"cyberhorse" <cy********@gmail.com> wrote in message
news:11**********************@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
Jul 17 '05 #8

P: n/a
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>
Jul 17 '05 #9

P: n/a
"Dani CS" <co*****************@yahoo.es.quita-la-merluza> wrote in message
news:cp**********@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
Jul 17 '05 #10

P: n/a
Dani CS <co*****************@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.

Jul 17 '05 #11

P: n/a
"Dani CS" <co*****************@yahoo.es.quita-la-merluza> wrote in message
news:cp**********@news.ya.com...
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>


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
www.easyavatar.com
Jul 17 '05 #12

P: n/a
.oO(Dani CS)
- 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).


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
Jul 17 '05 #13

P: n/a
Dani CS wrote:
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).


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
Jul 17 '05 #14

P: n/a
Michael Fesser wrote:
.oO(Dani CS)

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

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?


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.

Micha

Jul 17 '05 #15

P: n/a
Johnny Elvers wrote:
Dani CS wrote:
> 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).
>
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 ?


A session thief could retrieve the UID when it travels down to the
cliend, and use it right before the legitimate client uses it.

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.
I don't keep a history because I didn't see the need when I developed
this experiment, but the idea sounds good to me. Apart from that,
anytime that a user sends a wrong UID, they are presented the login
window again, just like you say.

- 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.
This could work, but I'll keep searching for a while on ways to make the
'back' button usable. Maybe the onunload() javascript event can help.

/Johnny

Jul 17 '05 #16

P: n/a
"Dani CS" <co*****************@yahoo.es.quita-la-merluza> wrote in message
news:cp**********@news.ya.com...

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.


I _think_ (not 100% certain about this) that you can avoid XSS attacks as
follows:

- When user goes to admin URL, open a new window to begin the session in.
- Ensure that the name of the new window is _blank; or, if using
window.open, create a totally random name based on the time - the more
entropy the better.
- Try to ensure that users only enter the admin system via this "window with
no name".

This should prevent any script from accessing values on your admin system
pages, as they are entirely contained in a window with no known target name.
It would not stop a specially written trojan, but then if you've got trojans
on your system then you've got more to worry about than session theft.

- Robert
Jul 17 '05 #17

P: n/a
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 ?

A session thief could retrieve the UID when it travels down to the
cliend, and use it right before the legitimate client uses it.


Right, but the same applies to the client side algorithms.
For measurements against generic theft your point is taken though.
This could work, but I'll keep searching for a while on ways to make the
'back' button usable. Maybe the onunload() javascript event can help.


Could be. Take a look at the XMLHttpRequest object.

/Johnny
Jul 17 '05 #18

P: n/a
Johnny Elvers wrote:
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 ?


A session thief could retrieve the UID when it travels down to the
cliend, and use it right before the legitimate client uses it.


Right, but the same applies to the client side algorithms.
For measurements against generic theft your point is taken though.


I was assuming that the thief can see the data, but not touch it. In
this case, even if the thief gets the new_sid that travels from the
client to the server, it will be worthless, because that new_sid has
already arrived to the server and is no longer valid.

If there is someone in the middle who can manipulate the data, only SSL
or similar would be good.

Jul 17 '05 #19

P: n/a

A session thief could retrieve the UID when it travels down to the
cliend, and use it right before the legitimate client uses it.


Right, but the same applies to the client side algorithms.
For measurements against generic theft your point is taken though.

I was assuming that the thief can see the data, but not touch it. In
this case, even if the thief gets the new_sid that travels from the
client to the server, it will be worthless, because that new_sid has
already arrived to the server and is no longer valid.


But the thief can do the same calculations as the client.

But you are right of cause, as this is about session theft and not
hacking attempts :)

/Johnny
Jul 17 '05 #20

P: n/a
Johnny Elvers wrote:

A session thief could retrieve the UID when it travels down to the
cliend, and use it right before the legitimate client uses it.
Right, but the same applies to the client side algorithms.
For measurements against generic theft your point is taken though.
I was assuming that the thief can see the data, but not touch it. In
this case, even if the thief gets the new_sid that travels from the
client to the server, it will be worthless, because that new_sid has
already arrived to the server and is no longer valid.


But the thief can do the same calculations as the client.


He needs the password to get the nex_sid from the current_sid. Only the
legitimate client knows that password.

But you are right of cause, as this is about session theft and not
hacking attempts :)

/Johnny

Jul 17 '05 #21

P: n/a
Dani CS wrote:

He needs the password to get the nex_sid from the current_sid. Only the
legitimate client knows that password.


Yes, but the point is that whatever resides inside the client, in a non
ssl (or the like) encrypted setup, is public. So password, algorithm and
whatever is transmitted is copyable.
So whatever is sent, the actual password or an md5'ed password or
whatever doesn't really matter. All the thief has to do is intercept and
replicate the client functionality.

/Johnny
Jul 17 '05 #22

P: n/a
Johnny Elvers wrote:
Dani CS wrote:

He needs the password to get the nex_sid from the current_sid. Only
the legitimate client knows that password.

Yes, but the point is that whatever resides inside the client, in a non
ssl (or the like) encrypted setup, is public. So password, algorithm and
whatever is transmitted is copyable.
So whatever is sent, the actual password or an md5'ed password or
whatever doesn't really matter. All the thief has to do is intercept and
replicate the client functionality.


The password is never sent over the net. It is typed down by the user on
the client, and then stored in a javascript variable. The thief can't
see it.

/Johnny

Jul 17 '05 #23

P: n/a
Dani CS wrote:
Johnny Elvers wrote:
Dani CS wrote:

He needs the password to get the nex_sid from the current_sid. Only
the legitimate client knows that password.


Yes, but the point is that whatever resides inside the client, in a
non ssl (or the like) encrypted setup, is public. So password,
algorithm and whatever is transmitted is copyable.
So whatever is sent, the actual password or an md5'ed password or
whatever doesn't really matter. All the thief has to do is intercept
and replicate the client functionality.


The password is never sent over the net. It is typed down by the user
on the client, and then stored in a javascript variable. The thief
can't see it.


But what if they can work out what the javascript variable is called?
Then it's just a matter of typing javascript:window.alert(foo) into the
address bar in Internet Explorer or Mozilla to get the value,
subsituting "foo" for the variable name in my example.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/
Jul 17 '05 #24

P: n/a

The password is never sent over the net. It is typed down by the user on
the client, and then stored in a javascript variable. The thief can't
see it.


Yes he can. It is not simply a matter of traffic.
Sniffing is sometimes complicated. Parsing client content is, for most
parts, not.

/Johnny
Jul 17 '05 #25

P: n/a
"Robert Tweed" <ro**********@killingmoon.com> wrote in message
news:32*************@individual.net...
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?


Easy. Don't rely on session for authentication (that is, in pages
subsequent to the login page). Authenticate with the HTTP digest method
instead. Session hijacking is basically a form of playback attack. A
properly implemented digest authentication is resistant to that.
Jul 17 '05 #26

P: n/a
Johnny Elvers wrote:

The password is never sent over the net. It is typed down by the user
on the client, and then stored in a javascript variable. The thief
can't see it.

Yes he can. It is not simply a matter of traffic.
Sniffing is sometimes complicated. Parsing client content is, for most
parts, not.


If the only thing the thief can do is look at the data on the wire, but
never change it, how could him grab something that is _never_ sent over
the wire?

If he can change the data on the wire, this and any other method of
authentication/session-management (lacking proper encryption) is already
defeated.

Apart from that, someone has already suggested a way to avoid cross-site
scripting vulnerabilities, by assigning a random ("impossible" to guess)
name to the window where all the data are.

/Johnny

Jul 17 '05 #27

P: n/a
"Chung Leong" <ch***********@hotmail.com> wrote in message
news:sI********************@comcast.com...

Easy. Don't rely on session for authentication (that is, in pages
subsequent to the login page). Authenticate with the HTTP digest method
instead. Session hijacking is basically a form of playback attack. A
properly implemented digest authentication is resistant to that.


From what I've read about digest authentication it is no more secure than
plain HTTP authentication, except that an attacker won't actually get your
password in cleartext. They can still bypass your security using the hash.

OK, so you get rid of the problem of session theft, but you are just
shifting the issue: getting rid of one problem at the cost of another
problem.

Also, there appear to be some compatability problems with browsers and it is
not fully supported by Apache (although this last part may be out of date).

Am I correct about this, or have I got the facts wrong?

- Robert
Jul 17 '05 #28

P: n/a
Dani CS <co*****************@yahoo.es.quita-la-merluza> wrote:
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.)


I've never actually used UUCP, but one thing I've read about was the use
of "session counters".

The idea was for every dialup connection, a counter was advanced by 1 step
on both systems.

Next time the machine would connect, it would use this counter to authenticate,
if counters don't line up, neither could login again until someone corrected
the problem. (A nuisance if your visitor ever did use [Back] buttons)

Sounds a lot like what you're talking about.

Doesn't SSL have some kind of built in protection for this? I've never used it,
but it seems I'd heard about using SSL public key stuff for session management
in highly secure areas.

A challenge/answer is the only true way I can think of, browser sends public
key along with request. Server encrypts string using browsers public key and
sends it, next request, browser must answer previous question.

But it'd be really difficult to do w/out browser support.

Jamie
--
http://www.geniegate.com Custom web programming
gu******@lnubb.pbz (rot13) User Management Solutions
Jul 17 '05 #29

P: n/a
>I've never actually used UUCP, but one thing I've read about was the use
of "session counters".

The idea was for every dialup connection, a counter was advanced by 1 step
on both systems.
And one of the problems in practice of using it was that the counters
would get out of sync and require manual intervention to get the
connection working again.

There was supposed to be only a short timing window where one counter
but not the other was incremented, but it managed to hit that window
to drop modem carrier or whatever caused the out-of-sync problem
often enough that using session counters proved to be a real nuisance.
Next time the machine would connect, it would use this counter to authenticate,
if counters don't line up, neither could login again until someone corrected
the problem.


Gordon L. Burditt
Jul 17 '05 #30

P: n/a
"Gordon Burditt" <go***********@burditt.org> wrote in message
news:cq********@library2.airnews.net...

There was supposed to be only a short timing window where one counter
but not the other was incremented, but it managed to hit that window
to drop modem carrier or whatever caused the out-of-sync problem
often enough that using session counters proved to be a real nuisance.


I don't know about the specific system in question, but one way to avoid
that problem, if you have counters advancing in realtime (as opposed to
advancing per-request), is to allow the next or previous response as well as
the expected one. You would simply have to ensure that there is also a
requirement that the same response not be allowed twice, to avoid replay
attacks.

You can even allow a greater margin of error than this, and allow both
timers to resyncronise themselves should the client drift out of sync with
the server. That way the client would need to make no requests for a long
time before any clock syncronisation problems made the two so far out of
sync that the server would refuse to recognise a valid connection.

Given enough entropy in the system, reducing that entropy by say, 5-10 to
allow for this sort of dynamic re-syncronisation, should still be high
enough that the system is secure against attackers.

- Robert
Jul 17 '05 #31

This discussion thread is closed

Replies have been disabled for this discussion.