Re: Re: a question on session ID and security

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jared Farrish wrote:
1. script for login process is located on a SSL-enabled server, so
usernames and passwords are encrypted.
https:// is an envelope encryption, so POST data, which is a part of the
packet data, not packet headers, is encrypted. As long as you POST or COOKIE
data that needs encryption, you're fine. GET is not secure.

What utter crud. An SSL connection encrypts the whole HTTP conversation, including headers and even the URL you are requesting. The response is also encrypted. It doesn't matter whether you're doing a POST or a GET request, it's all encrypted.

2. upon successful login, user is relocated to a non-SSL-enabled server
which hosts the scripts that contain the authenticated-user-only features.
If this is what you're doing (header() or a meta-refresh html tag).

So, while usernames and passwords are protected by SSL, the PHPSESSID is
not. In other words, anyone who captures that HTTP GET packet can get
the session ID. Is that true?
There are a few different attack vectors with SESSION data. Needless to say, never store or authenticate by a PHP SESSION id only; use cookies or encrypt
a page with script and include() the content per page, and force users to
login every page change.

Cookies are no more secure than the session ID. The general conclusion from many years of discussion in the web community is that the user experience is diminished so much by not trusting a session ID that the security improvements are not justified.

If you're really concerned then your best bet is to reduce the session lifetime to 5-10 minutes. Another 'trick' people sometimes use is to store the user agent in the session and expire it if a request tries to use an existing session with a different user agent. Unfortunately you cannot rely on the IP address remaining the same throughout a session, so don't build that into your session validation.

Another question is while that session ID is valid only before an
unset() and a session_destroy(). So the attacker who has the session ID
must fake the session before the real user logout. Is that true?
Before the session is destroyed and the temp file where it is stored is
deleted from the harddrive. Do not store sensitive information or use a
SESSION id to authenticate a user.

The session ID should be used for exactly what it says on the tin - identifying a session. PHP takes care of this for you by looking at the sessions it is maintaining for one matching the ID it's given. You can and should authenticate the continuation of a session based on the session ID (otherwise there's not much point having the session because the user will need to login for each page request), but you should not be storing the session ID anywhere because it's not a permanent value.

To invalidate a session ID you just need to call session_destroy. There are people who do the following just to be sure that the data in a session is destroyed, but AFAIK it's not necessary...

foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]);

-Stut

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux