On Wed, Feb 19, 2014 at 3:45 PM, Christoph Becker <cmbecker69@xxxxxx> wrote:
> 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
>
That is one of the reasons why I never encourage people to use URL based
sessions instead of cookies. Cookies on a different TLDs are harder to
read/write.
Additionally, the session fixer, will still need access to that random
cookie value from your website - even thou they have the session fixed, ip,
useragent, it won't be enough. I am not saying it is not possible to steal
cookies, but that makes it even more harder for someone to do.
Moreover, if someone is stupid enough to not check URLs for phishing, there
are much more smarter ways to get the account login/password, let alone get
their session/ip/browser. Why eat a slice when you can have the entire cake.
