NYCPHP Meetup

[Jonathan]

I agree that is difficult to find a silver bullet solution. The internet 
itself has its limits with identity management, and perhaps that's good.
Because of those limitations, security is as much about policy as 
technology.

Generally combining cookies (that can't be hijacked with cross-site 
scripting js), a server side script to create unique and user aware 
hashes, and SSL the network is  secure works well. There is a cost 
/benefit for a hijacking - if hijacking becomes increasingly complex, 
you have to be hiding something good to motivate anyone to come in. For 
example, if someone hijacked a users session in your system, what's the 
worst they could do? Could they get credit card information and pictures 
of the user naked? Or would the user only be able to post to NYPHP in 
their name? If the second is true you can always logging activity and 
communicating with the user, say sending an email confirmation like "You 
posted this" when you are really saying "Did you really post this?" I 
mean, security is really just a /sense/ of security.

It's easier to write code that works with sessions because it is a 
simple policy: once you log in, you're in. But, if there is something 
particularly sensitive you may want to verify identity again, like 
asking for the password again, or a captcha, or sending an email.

Sorry - I know I'm not giving code examples and you are in an 
implementation phase, but generally these steps have worked for me.

- Jonathan


Dan Cech wrote:

>Joseph,
>
>Your function would work the same way if it was:
>
>$this->_key = $_SERVER['HTTP_USER_AGENT'];
>
>If the attacker spoofs the client's HTTP_USER_AGENT string as well as 
>the session id they will pass the test.
>
>Thus it doesn't actually provide any real added protection against 
>session hijacking, because any attacker who can get hold of the session 
>id will also be able to determine and spoof the user agent string.
>
>I wish I had a 'silver bullet' solution to the problem that I could 
>recommend to you, but I don't.
>
>Dan
>
>Joseph Crawford wrote:
>  
>
>>guys is this a bit better way to check session validity?
>>
>>define('SES_KEY', 
>>md5('custom_string'.$_ENV['PROCESSOR_REVISION'].$_ENV['PROCESSOR_ARCHITECTURE'].$_ENV['PROCESSOR_LEVEL'].'custon_string'));
>>
>>$this->_key = md5($_SERVER['HTTP_USER_AGENT'].SES_KEY.$ses_id);
>>
>>that value is created and stored in the db on session start, then in my 
>>CheckSession function i am doing this
>>
>>if( $key !== $data['identifier'] )
>>
>>this ends up creating an identifier similar to this
>>
>>733f97f78f00cd6d2f0d7955698ebac4a2aad2e4fb76d0a5862838e087a20251
>>
>>this is based on the users agent, the initial session key, and some server 
>>stuff with some custom strings that i put in there.
>>
>>This works just fine i just wanted to know if it would be easy for someone 
>>to hijack a session with this added security. I am also wondering if i 
>>should set a cookie, i am not yet sure that i want the user to be able to 
>>log back in after they close thier browser, i mean atleast not without going 
>>through the login form
>>
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>New York PHP Talk Mailing List
>>AMP Technology
>>Supporting Apache, MySQL and PHP
>>http://lists.nyphp.org/mailman/listinfo/talk
>>http://www.nyphp.org
>>    
>>
>
>_______________________________________________
>New York PHP Talk Mailing List
>AMP Technology
>Supporting Apache, MySQL and PHP
>http://lists.nyphp.org/mailman/listinfo/talk
>http://www.nyphp.org
>  
>