Posted by Marcus on 11/16/37 11:28

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.

[Back to original message]