any secure php authetication model?

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
rami
Forum Contributor
Posts: 217
Joined: Thu Sep 15, 2005 8:55 am

any secure php authetication model?

Post 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
rami
Forum Contributor
Posts: 217
Joined: Thu Sep 15, 2005 8:55 am

Re: any secure php authetication model?

Post 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
User avatar
superdezign
DevNet Master
Posts: 4135
Joined: Sat Jan 20, 2007 11:06 pm

Re: any secure php authetication model?

Post 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.
rami
Forum Contributor
Posts: 217
Joined: Thu Sep 15, 2005 8:55 am

Re: any secure php authetication model?

Post 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
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: any secure php authetication model?

Post 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.
rami
Forum Contributor
Posts: 217
Joined: Thu Sep 15, 2005 8:55 am

Re: any secure php authetication model?

Post 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
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: any secure php authetication model?

Post 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.
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: any secure php authetication model?

Post 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?
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
superdezign
DevNet Master
Posts: 4135
Joined: Sat Jan 20, 2007 11:06 pm

Re: any secure php authetication model?

Post 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.
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: any secure php authetication model?

Post by VladSun »

Yes, it's true, especially when session hijacking is performed by bots :)
What about using COOKIES HTTP ONLY header?
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
superdezign
DevNet Master
Posts: 4135
Joined: Sat Jan 20, 2007 11:06 pm

Re: any secure php authetication model?

Post 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?
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: any secure php authetication model?

Post 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.
Last edited by VladSun on Thu Jun 12, 2008 7:14 am, edited 1 time in total.
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: any secure php authetication model?

Post 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.
Post Reply