session security

[Marcus]

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 following:

"There are several ways to leak an existing session id to third parties.
A leaked session id enables the third party to access all resources
which are associated with a specific id. [...] Second, a more active
attacker might listen to your network traffic. If it is not encrypted,
session ids will flow in plain text over the network. The solution here
is to implement SSL on your server and make it mandatory for users."

This seems to conflict with what the big sites do. I would really
appreciate any guidance as I have been reading all morning on packet
sniffing and session fixation etc etc, but the wealth of information out
there makes it all very confusing.

Lastly, I was also wondering if it matters that I use mysql_connect() on
every page in the event I do not SSL every page... please correct me if
I am wrong, but since it resides on the server, I don't *think* the
database password, which is stored in the php file in plain text, should
ever actually be transported across the network. I have not been able
to confirm this however.

Thanks so much in advance.

[Justin Koivisto]

Marcus wrote:

Lastly, I was also wondering if it matters that I use mysql_connect() on
every page in the event I do not SSL every page... please correct me if
I am wrong, but since it resides on the server, I don't *think* the
database password, which is stored in the php file in plain text, should
ever actually be transported across the network. I have not been able
to confirm this however.

The password is *never* sent through the network if you are connecting
to the localhost via a socket.

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com

[Gordon Burditt]

>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 following:

"There are several ways to leak an existing session id to third parties.
A leaked session id enables the third party to access all resources
which are associated with a specific id. [...] Second, a more active
attacker might listen to your network traffic. If it is not encrypted,
session ids will flow in plain text over the network. The solution here
is to implement SSL on your server and make it mandatory for users."
Another also-useful technique, with or without using SSL, is to
expire sessions quickly, but without making it too inconvenient for
genuine users. If you expire sessions an hour after the last hit,
it becomes useless at that point, even if the user posts the session
id to USENET, or walks away from the computer at an Internet cafe
and someone evil looks at the browser history. It also means that
packet sniffers have to act quickly to use the info.
This seems to conflict with what the big sites do.
There is a tradeoff between security and CPU horsepower. It may
be cheaper for the big sites to buy insurance to cover their losses
(which may not cover the *customer* losses from identity theft).

It also matters WHAT is being protected. If your credit card info
never goes into the session data, or more important, it can't be
gotten OUT of the session data, then session hijacking becomes less
of an issue. How much effort do you think thieves would exert to
get the contents of your shopping basket? If they hijack the
session, they can list the contents of your shopping basket. Big
Deal. Can they list your credit card? On sites I have seen, *NO*,
except on the page where you enter it, and that may be replaced
with ****'s. Can you tell it to use the card you used last time?
On sites I have seen, *NO*.
I would really
appreciate any guidance as I have been reading all morning on packet
sniffing and session fixation etc etc, but the wealth of information out
there makes it all very confusing. Lastly, I was also wondering if it matters that I use mysql_connect() on
every page in the event I do not SSL every page... please correct me if
I am wrong, but since it resides on the server, I don't *think* the
database password, which is stored in the php file in plain text, should
ever actually be transported across the network. I have not been able
to confirm this however.

The database password, hashed or encoded or something, will be
transported between the web server and the database server. If
they are on the same machine, that's not over the network at all.
If they are on the same LAN, it's still not over the global internet.
The database password is *NOT* sent to the user's browser.

Ideally you also set up the database so that access to the db is
allowed from a very small number of IP addresses (your web server(s)
and perhaps a machine you use for maintaining the database), so
even if the password *IS* leaked, it's useless. For a lot of hosting
setups, the only IP address you can access the db from is *localhost*.

If your database and web server talk to each other over the global
Internet, you should either not be sending credit card info and/or
medical information over that link, or you should be using SSL
between the database and the web server (which has *NOTHING* to do
with whether you use SSL between the web server and the customer's
browser). Connecting with SSL between PHP and MySQL requires setup
on both the PHP and MySQL side that many hosting companies won't have.

Gordon L. Burditt

[Colin McKinnon]

Marcus wrote:

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.

Keeping things constantly under SSL is a good idea.

You should also discard the current session and create a new one (perhaps
copying data from the old session) when presented with login information.
To avoid session fixation.

A few caveats is to make sure that you maintain the patches on your SSL
config, and preferably run the SSL remote from the webserver (even in a
chroot stunnel). Its also handy to run an assymetric encryption program
with only one of the key pair on the server to log information securely.

Lastly, I was also wondering if it matters that I use mysql_connect() on
every page in the event I do not SSL every page... please correct me if
I am wrong, but since it resides on the server, I don't *think* the
database password, which is stored in the php file in plain text, should
ever actually be transported across the network. I have not been able
to confirm this however.

If it is connecting locally, the password will not be visible from the
network (this connection is quite seperate from the connection between user
and webserver - so it makes no difference if that is encapsulated or not).

HTH

C.

[Marcus]

Gordon Burditt wrote:

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 following:

"There are several ways to leak an existing session id to third parties.
A leaked session id enables the third party to access all resources
which are associated with a specific id. [...] Second, a more active
attacker might listen to your network traffic. If it is not encrypted,
session ids will flow in plain text over the network. The solution here
is to implement SSL on your server and make it mandatory for users."

Another also-useful technique, with or without using SSL, is to
expire sessions quickly, but without making it too inconvenient for
genuine users. If you expire sessions an hour after the last hit,
it becomes useless at that point, even if the user posts the session
id to USENET, or walks away from the computer at an Internet cafe
and someone evil looks at the browser history. It also means that
packet sniffers have to act quickly to use the info.

This seems to conflict with what the big sites do.

There is a tradeoff between security and CPU horsepower. It may
be cheaper for the big sites to buy insurance to cover their losses
(which may not cover the *customer* losses from identity theft).

It also matters WHAT is being protected. If your credit card info
never goes into the session data, or more important, it can't be
gotten OUT of the session data, then session hijacking becomes less
of an issue. How much effort do you think thieves would exert to
get the contents of your shopping basket? If they hijack the
session, they can list the contents of your shopping basket. Big
Deal. Can they list your credit card? On sites I have seen, *NO*,
except on the page where you enter it, and that may be replaced
with ****'s. Can you tell it to use the card you used last time?
On sites I have seen, *NO*.

I would really
appreciate any guidance as I have been reading all morning on packet
sniffing and session fixation etc etc, but the wealth of information out
there makes it all very confusing.

Lastly, I was also wondering if it matters that I use mysql_connect() on
every page in the event I do not SSL every page... please correct me if
I am wrong, but since it resides on the server, I don't *think* the
database password, which is stored in the php file in plain text, should
ever actually be transported across the network. I have not been able
to confirm this however.

The database password, hashed or encoded or something, will be
transported between the web server and the database server. If
they are on the same machine, that's not over the network at all.
If they are on the same LAN, it's still not over the global internet.
The database password is *NOT* sent to the user's browser.

Ideally you also set up the database so that access to the db is
allowed from a very small number of IP addresses (your web server(s)
and perhaps a machine you use for maintaining the database), so
even if the password *IS* leaked, it's useless. For a lot of hosting
setups, the only IP address you can access the db from is *localhost*.

If your database and web server talk to each other over the global
Internet, you should either not be sending credit card info and/or
medical information over that link, or you should be using SSL
between the database and the web server (which has *NOTHING* to do
with whether you use SSL between the web server and the customer's
browser). Connecting with SSL between PHP and MySQL requires setup
on both the PHP and MySQL side that many hosting companies won't have.

Gordon L. Burditt

Gordon,

Thank you for the detailed response, it helps greatly. With regards to
the session handling and SSL, I am not concerned about my data really,
as I am not dealing with any financial data or anything that is very
personal info at all. The only sensitive info is passwords, and those
pages are SSL'd.

My concern is this - I am obviously not 100% sure about all the details
of session handling, but my concern is that if someone is able to hijack
a session via whatever method, perhaps packet sniffing and getting the
session id, wouldn't this person then be able to take over the user's
existing session and function as that user? In other words, the
attacker could function as if he/she were the user and potentially
delete important data that the user has authority to delete, but does
not want to delete. To me, someone gaining access to someone else's
session could wreak havoc, even if there is technically no sensitive
information at stake. Am I reading too much into this?

Thanks again.

[Gordon Burditt]

>Thank you for the detailed response, it helps greatly. With regards to

the session handling and SSL, I am not concerned about my data really,
as I am not dealing with any financial data or anything that is very
personal info at all. The only sensitive info is passwords, and those
pages are SSL'd.

My concern is this - I am obviously not 100% sure about all the details
of session handling, but my concern is that if someone is able to hijack
a session via whatever method, perhaps packet sniffing and getting the
session id, wouldn't this person then be able to take over the user's
existing session and function as that user?
Yes, assuming you don't ask for authentication information again
when doing sensitive changes. But remember that if someone is able
to guess the user's *password*, he can do that also, and he may be
able to continue doing that for years, as opposed to a session,
which hopefully doesn't last very long.

Which do you think is easier to guess, a user's session ID or a
user's password? Take a look at the session IDs generated on
your system and the length of typical user passwords actually
selected by real users.
In other words, the
attacker could function as if he/she were the user and potentially
delete important data that the user has authority to delete, but does
not want to delete. To me, someone gaining access to someone else's
session could wreak havoc, even if there is technically no sensitive
information at stake. Am I reading too much into this?

People won't bother trying to hijack sessions if they can guess
passwords. Users tend to choose lousy passwords. On the other
hand, session code tends to choose randomized session IDs.

What is the threat here? Would someone spend days trying to sniff
session data to delete user info which the user could re-type-in
in 10 minutes? Why? If this is a forum for something like IRC,
where just logging in can attract an attack, and in-person meetings
between people on the same IRC channel are likely to involve automatic
weapons and cluster bombs, if not suitcase nukes, I can see the
problem.

Gordon L. Burditt

[Dikkie Dik]

The login phase usually contains SSL and regular info. This means that
session data may be leaked out of the SSL part somehow, if an attacker
can reach it via the regular part. PHP has a session_regenerate_id
function to switch to a new session once a user is logged in.

Best regards

[Marcus]

Gordon Burditt wrote:

Thank you for the detailed response, it helps greatly. With regards to
the session handling and SSL, I am not concerned about my data really,
as I am not dealing with any financial data or anything that is very
personal info at all. The only sensitive info is passwords, and those
pages are SSL'd.

My concern is this - I am obviously not 100% sure about all the details
of session handling, but my concern is that if someone is able to hijack
a session via whatever method, perhaps packet sniffing and getting the
session id, wouldn't this person then be able to take over the user's
existing session and function as that user?

Yes, assuming you don't ask for authentication information again
when doing sensitive changes. But remember that if someone is able
to guess the user's *password*, he can do that also, and he may be
able to continue doing that for years, as opposed to a session,
which hopefully doesn't last very long.

Which do you think is easier to guess, a user's session ID or a
user's password? Take a look at the session IDs generated on
your system and the length of typical user passwords actually
selected by real users.

In other words, the
attacker could function as if he/she were the user and potentially
delete important data that the user has authority to delete, but does
not want to delete. To me, someone gaining access to someone else's
session could wreak havoc, even if there is technically no sensitive
information at stake. Am I reading too much into this?

People won't bother trying to hijack sessions if they can guess
passwords. Users tend to choose lousy passwords. On the other
hand, session code tends to choose randomized session IDs.

What is the threat here? Would someone spend days trying to sniff
session data to delete user info which the user could re-type-in
in 10 minutes? Why? If this is a forum for something like IRC,
where just logging in can attract an attack, and in-person meetings
between people on the same IRC channel are likely to involve automatic
weapons and cluster bombs, if not suitcase nukes, I can see the
problem.

Gordon L. Burditt

Gordon,

I see your point, I think I will just re-generate the session ID after
every user request so that the last session ID is no longer valid.
Hopefully that will provide enough security for the non-SSL'd pages.

My last question is this: I read online that you should never pass
session data between http and https servers. I have successfully
carried sessions between the two without passing any information in the
URL... since I know this can be done, is there a reason not to do so?
Does it expose any other security risks I am not aware of?

[Gordon Burditt]

>I see your point, I think I will just re-generate the session ID after

every user request so that the last session ID is no longer valid.
Are you *SURE* that re-generating the session ID cancels the validity
of the old one? If not, you're just generating piles more correct
answers. The delete_old_session parameter to session_regenerate_id()
seems to have been added in version 5.1.0.
Hopefully that will provide enough security for the non-SSL'd pages.

My last question is this: I read online that you should never pass
session data between http and https servers. I have successfully
carried sessions between the two without passing any information in the
URL... since I know this can be done, is there a reason not to do so?
Does it expose any other security risks I am not aware of?

If it's exposed in http it's exposed, period. And providing a lot
of "known plaintext" for a cracking attempt at the SSL ciphers isn't
a good idea even though it's thought they aren't vulnerable to such
an attack.
Gordon L. Burditt

[George Chapman]

In article <Ta**************@newssvr23.news.prodigy.net>, JumpMan222
@aol.com says...

Lastly, I was also wondering if it matters that I use mysql_connect() on
every page in the event I do not SSL every page... please correct me if
I am wrong, but since it resides on the server, I don't *think* the
database password, which is stored in the php file in plain text, should
ever actually be transported across the network. I have not been able
to confirm this however.

Normally, no, the password is inacessible to the web visitor. However,
if something were to go awry with your web server settings, and for some
reason it failed to recognize PHP as something that should be processed
rather than just served, the web browser may in this adittedly unlikely
event display the code or even offer the user the chance to download the
PHP file.

The way to protect against this: Put the mysql_connect in it's own PHP
file, residing in a folder that is OUTSIDE your web root but still
accessible to PHP. Then do require_once('db_connect.php') at the start
of every script that needs it.

Of course this STILL makes it vunerable to anyone that has access to the
physical file, including people with access to the physical machine, and
people who have the ability to FTP or Telnet to your files.

Just my 2 cents.

- GC