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(); greets Zoltán Németh > > -Stut > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
