[PHP] You to prevent site hacking by 'pirates' ?
Baroiller Pierre-Emmanuel
If the user try to change de sessionId, I check with the current sessionId
stored into my own cookie..
But.. It may not to be usefull... :)
The cookie is basically a crypted copy of the session content (with a
different encryption method).
I'm looking for a good way to protect a private part of a site and...
I was thinking this method would be more efficient than only the session
cookie..
But ... perhaps I'm on the bad way...
"John W. Holmes" <holmes...@charter.net> a écrit dans le message de news:
002501c27e08$40567040$7c02a8c0@coconut...
> > I would know what did you think of my method to prevent 'piracy'..
> >
> > I do like this :
> >
> > - A Session is made for each user
> > In the session, put 2 value : a flag "userlogged" and the userId
> > - In a cookie, I put the session Id and an unique crypted value.
>
> If you're using sessions, there is already a cookie with the session id
> in it. Why are you storing crypted values in a cookie? Why not just add
> the values to the session and not worry about encrypting it?
>
> ---John Holmes....
>
> >
> > When user go on private parts of the site,
> > I check the session, the cookie and database fields for the user..
> > The crypted data contains some user values (the encryption is done
> with
> > mcrypt lib).
> >
> > Is it a good way or is there a better way (without SSL)... ?
> >
> > Regards,
> > P.E. Baroiller
>
>
John W. Holmes
Chris Shiflett
>I work with double cookie to add a "security"...
>
This is a common technique and does strengthen security somewhat.
>If the user try to change de sessionId, I check with the current sessionId
>stored into my own cookie..
>But.. It may not to be usefull... :)
>The cookie is basically a crypted copy of the session content (with a
>different encryption method).
>
You might want to consider using only one piece of session data rather
than the whole thing. For example, many people who use this type of
approach will have an extra validation key stored in the session that is
used to create the second cookie (or URL variable or whatever).
If you focus too much on strengthening security, or make your extra
steps too complex, you risk making your session mechanism very
inefficient, and this can open you up to the risk of denial of service
attacks.
>I'm looking for a good way to protect a private part of a site and...
>I was thinking this method would be more efficient than only the session
>cookie..
>
Not more efficient, but definitely a bit more secure.
Here is a suggestion, however. Your method here is focused on preventing
a "guess" attack, right? Well, the unique IDs generated by PHP are
already extremely difficult to guess, and this is probably not the
weakest point in your mechanism. What you might want to do is let your
validation token be passed in the URL on each page. This way, for those
with cookies enabled, the PHPSESSID will be in a cookie, and your
validation token will be in the URL.
Why use two different methods? Well, there are more dangers than someone
trying to guess a valid cookie. Browsers have been known to have
vulnerabilities that allow people to read cookies from any domain (IE
4.0 - 6.0 has this problem). Thus, a bad guy could get a good guy's
cookies and then visit your site. Passing a validation token on the URL
certainly doesn't make everything safe, but it makes the bad guy have to
work harder, and that's what we want to do. Also, with a combination of
methods, you almost force the bad guy to have to intercept the HTTP
request itself. If someone can intercept the HTTP transactions, then
your only real protection is something like SSL, so if you're not using
SSL, you can feel pretty good knowing that you've made things about as
difficult for the bad guy as you can.
Happy hacking.
Chris