Page 1 of 1
any secure php authetication model?
Posted: Tue Jun 10, 2008 9:05 am
by rami
Well we were in search of secure php session model could some body provide us secure php session models which takes care of
session hijacking
sesssion fixation
(the storage of the session may not be in database as we are using didicated server)
we worry
Regenerating session_id on each page request to get rid of hijacking may put extra burden in our server as there may be more 500 page request per second...
we dont use GET to pass any session variable or id
our current model
when ever user logins
on correct
session is created with a random hash value
on subsequent page session is checked with that hashvalue,if it exist
new hash value is generated (or we can generate session_regenerate_id)
if not log out user
and so on...
for different level of users we user variable in session
SESSION['level']="simple'
SESSION['level']="2ndlevel'
and so on
we dont want any problems with the different level of users or any session inpersonization
please somebody give us working model or example or code snipplet which address these all issues
thanks
Re: any secure php authetication model?
Posted: Tue Jun 10, 2008 9:06 am
by rami
one reason why we soughtfor the experts for help
after reading all general solution
we happen to read this from one book pro php security
which says the generally used techiques as ineffective
1. One-time keys: It would seem that you could make a hijacked session ID unusable by
changing the validation requirement for each individual request. We know of proposals
for three seemingly different ways to accomplish this; unfortunately, each is faulty in its
own way.
1. You could generate a one-time random key (using any of a whole variety of possible
random values, including time, referrer IP address, and user agent), and merge that
(by addition or concatenation) with the existing session ID. You could hash the
result and pass that digest back and forth to be used instead of the session ID for
validation. All this technique does, however, is substitute one eavesdropping target
(the digest) for another (the session ID).
2. You could generate a new one-time key each time a request comes in, and add that
as a second requirement for validating a request (so that the returning user must
provide not only the original session ID but also that one-time key). However, this
technique simply substitutes two eavesdropping targets for the original one.
3. You could set a new session ID with each request, using the ession_regenerate_id()function,
which preserves existing data in the $_SESSION superglobal, generates a
new session ID, and sends a new session cookie to the user. This technique does
nothing more than change the content of the eavesdropping target each time.
which says the generally used techiques as ineffective
in checking reffer id and user agent is said to be of no use...
SO IT SAYS USING SSL is only solution ...
so is SSL only solution remaining...
our session variable are not any credit cards and so..but still we dont want user data to be compromised
thanks
Re: any secure php authetication model?
Posted: Tue Jun 10, 2008 10:28 am
by superdezign
How often do you think session hijacking occurs...? The only way to do so is to know the session ID of a logged in user. Sessions can't really get any more secure than they already are without losing usability / accessibility.
Re: any secure php authetication model?
Posted: Tue Jun 10, 2008 11:25 am
by rami
superdezign wrote:How often do you think session hijacking occurs...? The only way to do so is to know the session ID of a logged in user. Sessions can't really get any more secure than they already are without losing usability / accessibility.
thanks but saying that we cannot turn blind folded towards the problem ....at least we should have some mechanism to protect ourself
any way any codes,examples thanks
Re: any secure php authetication model?
Posted: Tue Jun 10, 2008 11:56 am
by Mordred
1. Against session fixation: regenerate_session_id() whenever the authorization level changes (basically - on login)
2. Against session hijacking: don't have XSS vulnerabilities. SSL will not help, neither will regenerate_session_id(), they concern different attacks. Some mitigation may be done by checking the user IP, but it should be a security option per user, as some users' ISPs may change their IPs between requests (most notoriably AOL). Don't generate your own SID, use PHP's own method. You're 99.99% guaranteed to get it wrong (and if not, at most you'll have equally good random)
What book are you reading and what solution does it propose?
SSL is not sufficient to prevent session hijacking (in fact its purpose - preventing traffic sniffing - is only marginally close), so either you misunderstand what the book advises, or you should throw it away.
3. Mitigate all authorization issues by reauthenticating the user when important things need to be done - password changes, payments, etc.
Re: any secure php authetication model?
Posted: Tue Jun 10, 2008 10:19 pm
by rami
i use to think session regenerate would solve the problem
but whats about this
1. One-time keys: It would seem that you could make a hijacked session ID unusable by
changing the validation requirement for each individual request. We know of proposals
for three seemingly different ways to accomplish this; unfortunately, each is faulty in its
own way.
1. You could generate a one-time random key (using any of a whole variety of possible
random values, including time, referrer IP address, and user agent), and merge that
(by addition or concatenation) with the existing session ID. You could hash the
result and pass that digest back and forth to be used instead of the session ID for
validation. All this technique does, however, is substitute one eavesdropping target
(the digest) for another (the session ID).
2. You could generate a new one-time key each time a request comes in, and add that
as a second requirement for validating a request (so that the returning user must
provide not only the original session ID but also that one-time key). However, this
technique simply substitutes two eavesdropping targets for the original one.
3. You could set a new session ID with each request, using the ession_regenerate_id()function,
which preserves existing data in the $_SESSION superglobal, generates a
new session ID, and sends a new session cookie to the user. This technique does
nothing more than change the content of the eavesdropping target each time.
These techniques, then, don’t even make hijacking more difficult, and at the same time
the constant regeneration of keys and IDs could easily place an unacceptable burden
on the server. In complex systems, where browsers are making concurrent requests (out
of a Co ntent Management System in which PHP handles images, for example), or where
JavaScript requests are being made in the background, they can break completely.
Furthermore, they require even more work than implementing SSL (which uses built-in
Message Authentication Codes to prevent replay attacks; see Chapter 7 for additional
information). So as a practical matter, any of these one-time key techniques is useless.
This is from the book Pro php security by Chris Snyder and Michae South well of Apress
ok this might be wrong but any logic..or arguement to prove it wrong...a writer might not just write to write...
My own problem generating session_id on each request
but these line seems quite logical about regenerating sesssion id
"These techniques, then, don’t even make hijacking more difficult, and at the same time
the constant regeneration of keys and IDs could easily place an unacceptable burden
on the server. In complex systems, where browsers are making concurrent requests (out
of a Co ntent Management System in which PHP handles images, for example), or where
JavaScript requests are being made in the background, they can break completely. "
so as i say with the around 500 page request each second wont it bring the server down to its knee....
and i dont know why he has said
"These techniques, then, don’t even make hijacking more difficult"
so it is wrong...
if it does no thing then why to bother generating session and putting burden on server
thanks
Re: any secure php authetication model?
Posted: Wed Jun 11, 2008 5:34 am
by Mordred
So, the book you quote even says it in plaintext that these methods don't protect agains hijacking. Why are you discussing them?
Ah, you want to know why they don't work? It is explained in the quote. Maybe you should research how the session hijacking attack works - set a test site and try it yourself.
I'll repeat: regenerate_session_id() on every request is unnecessary, as it won't help against hijacking. It helps against fixation, and you only have to do it once on login.
It looks like you are missing some details on how these attacks work, so I can advise you to try them yourself - there are tons of articles on the web, you can set up a vulnerable script and just try what can be done and what can't be done.
Re: any secure php authetication model?
Posted: Thu Jun 12, 2008 4:09 am
by VladSun
Mordred wrote:I'll repeat: regenerate_session_id() on every request is unnecessary, as it won't help against hijacking. It helps against fixation, and you only have to do it once on login.
In general, isn't it going to minimize the time window for successful session hijacking?
Re: any secure php authetication model?
Posted: Thu Jun 12, 2008 5:10 am
by superdezign
VladSun wrote:In general, isn't it going to minimize the time window for successful session hijacking?
Yes, but most users spend more than 1 second per page. During that time if the session was somehow hijacked, it would be an even worse situation, since the second that the hijacker visits another page, the original user has an incorrect session id and they will lose all access to their own session.
Re: any secure php authetication model?
Posted: Thu Jun 12, 2008 5:53 am
by VladSun
Yes, it's true, especially when session hijacking is performed by bots

What about using COOKIES HTTP ONLY header?
Re: any secure php authetication model?
Posted: Thu Jun 12, 2008 6:01 am
by superdezign
VladSun wrote:What about using COOKIES HTTP ONLY header?
I've no idea what that does, so I'll take a guess. As in, using cookies for the session ID only, and not accepting from the 'PHPSESSID' GET variable?
Re: any secure php authetication model?
Posted: Thu Jun 12, 2008 6:07 am
by VladSun
http://msdn.microsoft.com/en-us/library/ms533046.aspx
http://blogs.securiteam.com/index.php/archives/849
It should deny read/write access of server-side set cookies (i.e. HTTP cookies) to client-side (i.e. JavaScript, VBScript, etc.).
This way, protecting against some XSS attacks - e.g. stealing SID stored in a cookie by using script injection.
Re: any secure php authetication model?
Posted: Thu Jun 12, 2008 6:18 am
by Mordred
Stops javascript from being able to read the cookie.
Doesn't stop the XSS hole from CSRF-ing the client with the original cookie from doing what the attacker wanted the cookie for.
So it helps, but only a bit, not a panacea.