Zoltán Németh wrote:
2007. 05. 29, kedd keltezéssel 10.09-kor Stut ezt írta:
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]);
or just simply
$_SESSION = array();
I consider this is very bad practice, but I've just checked the manual
page for session_destory and it recommends the following to completely
destroy a session...
<?php
// Initialize the session.
// If you are using session_name("something"), don't forget it now!
session_start();
// Unset all of the session variables.
$_SESSION = array();
// If it's desired to kill the session, also delete the session cookie.
// Note: This will destroy the session, and not just the session data!
if (isset($_COOKIE[session_name()])) {
setcookie(session_name(), '', time()-42000, '/');
}
// Finally, destroy the session.
session_destroy();
?>
-Stut
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
