|
|
Posted by Gordon Burditt on 10/22/77 11:28
>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
Navigation:
[Reply to this message]
|