NYCPHP Meetup

[felix zaslavskiy]

I like to only pose only my opinion on this subject.

I agree it is imposible to have 100% secure HTTP session mechanism
because the server application does not control the client side.

I think ssl should be used to increase security as a starting point.
Then use session cookie with secure attribute to carry the session id.

The session id should not be used solely for actions that have lasting
side effects such as POST that causes money to be transfered. In that
case each POST like that should have additional token that can be used
only once, and that token should have a expiration time just in case.

As far as using tokens in URL I dont think its a good idea because of
the potential risks and lack of benefits. Like someone said url's can be
placed in Referer header or loged in server logs. And in general they
will make application more complex. I had an idea recently of having url
variables calculated by javascript which a token taken from hidden tag
in html. This mechanism was supposed to help prevent csrf where a user
can only create an url if the user has already received an html page
from a session.  Even if an attacker got a users session id from a
cookie he would still not be able to request an html page without
already having a valid html page. Now this may work but it still assumes
too much. Attacker can still combine a xss with csrf or steal the url
token and session id to get around this, in addition it would make
application logic more complex.

So my conclusion is to get a good mix of ssl , session cookie and hidden
tokens in POST to get a pretty good level of security and make sure it
all works correctly.

As last resort educate users not to do stupid stuff like click on links
from email and entering passwords thereafter. That seems to be a popular
attack lately.



-- 
felix[at]bebinary.com
http://www.zaslavskiy.net/