Aziz Saleh wrote:
> On Wed, Feb 19, 2014 at 11:22 AM, Vernon Nemitz <vnemitz@xxxxxxxx> wrote:
>
>> On Wed, 19 Feb 2014 10:04:53 -0500, Aziz Saleh wrote
>>> On Tue, Feb 18, 2014 at 9:07 PM, Vernon Nemitz <vnemitz@xxxxxxxx> wrote:
>>>>
>>>> By the way, one of the other messages I've received in response
>>>> to my original question concerned a php.ini file setting,
>>>> session.use_strict_mode
>>>> (available PHP 5.5.2+) which appears to at least do the ignoring
>>>> thing, if a browser sends session data to the Server which does
>>>> not happen to match an existing session-data-file. Good show!
>>>
>>> Glad you sorted it out. However, I don't think you understood
>>> what I meant. My original thought is that you were worried
>>> about session hijacking (someone finding out the session id
>>> a user uses, example and admin) and going into your site and
>>> plugin that ID into the URL (or cookie by default) to take
>>> control over that session, basically login in by the session
>>> id. What I do prevents that from happening by associating the
>>> session id to not just any user, but to that specific user
>>> that logged in.
>>
>> I do understand the idea, but not the implementation as you
>> have so far described it. If the user has to keep identifying
>> self to the web server, then that is data that the bad guy
>> could obtain as easily as the session ID. However, it occurs
>> to me that the IP address of the user, and that of the bad
>> guy, should always be different. So, if the IP address was
>> saved in association with the session ID, the server could
>> check for a matching IP address each time a request reached
>> it, that began identifying itself with a session ID.
>
> Think about the implementation this way:
>
> function getUserSalt(){ return isset(COOKIE[salt]) ? COOKIE[salt] :
> makeSalt()}
This makes it possible for everybody to determine the salt, what might
not be the best idea.
> function getUniqueKey(){ return ip + user agent + salt + (other unique
> factors, add as many as you want)}
>
> function getUserSession(){
> set key = getUniqueKey(), set session id = SESSION_ID (from url or
> cookie)
> check DB for corresponding row with those two params, if user exists,
> use the corresponding user id with that session, else destroy the session
> }
>
> The only way a user can hijack someone's session is if they have the cookie
> value salt + cookie/url value session_id + ip + user agent, which I
> personally think is far fetched.
No, this is not the only way somebody can hijack a session. Consider
session fixation attacks[1], where the attacker tricks someone into
using their prepared session ID. Checking additionally the IP address
and the UserAgent string makes such attacks harder, but doesn't
absolutely prevent them, as the attacker could use some indirection
(say, a PHP script on their domain, which recognizes IP address and
UserAgent string of the victim, and redirects to the appropriate URL for
the user to login).
[1] <https://www.owasp.org/index.php/Session_fixation>
--
Christoph M. Becker
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
