473,895 Members | 2,419 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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
Jul 17 '05 #1
30 4015
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
"Chris Hope" <bl*******@elec trictoolbox.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
Robert Tweed wrote:
"Chris Hope" <bl*******@elec trictoolbox.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
"Chris Hope" <bl*******@elec trictoolbox.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
Robert Tweed wrote:
"Chris Hope" <bl*******@elec trictoolbox.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
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
"cyberhorse " <cy********@gma il.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.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
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+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>
Jul 17 '05 #9
"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

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

9
2097
by: Marcus | last post by:
Hello, Currently all of my php pages use SSL, not just my initial login. Originally I thought this would be more secure, but after thinking about things and looking at sites like Amazon and Gmail, they all SSL the login scripts and then use regular http for everything else, which I'm sure speeds things up without the encrypt/decrypt process. I was going to change my scripts to reflect this model, but I saw in the php manual the...
24
1705
by: E. Robert Tisdale | last post by:
In article <1109278095.279964.320810@g14g2000cwa.googlegroups.com>, E. Robert Tisdale <e.robert.tisdale@gmail.com> wrote: Note that this is *not* <E.Robert.Tisdale@jpl.nasa.gov>.
0
3246
by: joseph conrad | last post by:
Hi, I tried to implement my own session handler in order to keep control on the process the drawback I foun it is not creating and storing in my cookie the PHPSESSID variable anymore. reading te documentation it seems it should do it anyway any advice?
14
2390
by: aroraamit81 | last post by:
Hi, I am facing a trouble. I have some Session variables in my code and somehow my session variables are getting mixed up with other users. For example User A has access to 10 companies and User B has access to 5, now when both of us hits to the server at the same time then their session variables gets mixedup means either User A and USer B will have now 5 companies or both have 10 companies. Now again when User A hits to the server...
7
3975
by: aroraamit81 | last post by:
Well Guys, Here is a very strange trouble. When more than one users request tto same page at the same time then our session gets conflicted. Moreover I printed my SessionID, strangely but true I got the exact same SessionID as of other users's. Well I guess nothing wrong with my code, do I need to set any property in Web.Config file??
1
2608
by: Santosh | last post by:
Dear All i am writting a code sending mail with attachement. i am writting code for sending mail in one page and code for attaching a file in the next page. aftet attaching a file i am taking name of that file from attaching file page to email page through in session file .i am giving a facility of attaching five files to user . and i am taking names of both files in session variables but user attach less than five five
5
2446
by: lyealain | last post by:
<% If Session("username") = "" Then Response.Redirect("/CLS/Login.asp") End If Dim conn Dim connectstr Dim db_name, db_username, db_userpassword Dim db_server Dim res
0
9836
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11249
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10847
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10473
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
8028
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7179
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
6070
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4693
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
3298
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.