If you are worried about speed in regards to the server accessing session information then you will want to utilize the mcache service daemon as well as the php mcache libraries in your code.

Session hijacking attacks on web applications involve utilizing known attack vectors such as the static method of the PHP global session_id(). Essentially allowing an attacker to 'guess' a session id and attempt to create a local cookie matching that id in order to access a web application as the user whose session id is being spoofed. For more information -> http://en.wikipedia.org/wiki/Session_hijacking

Cross site request forgery is more involved and can be read about here -> http://en.wikipedia.org/wiki/Cross_site_request_forgery

One method of helping keep your application safe is to utilize common unique identifiers per user such as information per page request stored in the $_SERVER super global within PHP.

Remote_addr, user_agent, and referrer and three good unique identifiers in which to prevent attackers from hijacking users sessions.

You may also want to lookup information regarding regeneration of the session_id on each new page request an authenticated user visits. This will help prevent another attack vector known as session fixation.

I am no expert, but research and testing are key. Everyone does it different but my method involves the following steps:

1. Present login form for user
2. Require server side to process input using PHP
3. Check your authentication source (database, flat file, ldap, or directory server for user credentials) 4. Create public/private key pair along with encryption IV and associate private key and IV with user account as well as unique identifiers (do not send this information back to client as it is used to decrypt our authentication token later) 5. Gather unique identifiers of user (ip address, browser type, referring page), including the public key that was generated 6. Use private key to encrypt each variable and then encode as a utf-8 compatible string in order to register as a session variable on server (within mcache, mysql or default flat file) 7. On each page user requests ensure their token is valid by using the following steps:
- check token length
- decrypt token information
- re-authenticate user in database, flat file or other authentication source
- ensure unique variables are the same to protect against session hijacking
- ensure user requesting protected pages are coming from your site by checking decrypted value of the user referrer - if all checks pass simply regenerate the session id and allow for the user to access the page requested

I hope this makes sense to you and I am sure its a bit to digest but it should get you started and give you some things to think about.

Vinay Kannan wrote:
Hi Jason,

Yes this is going to be a public facing application with 3 level heirarchy,
and maybe around 100 tiny companies(3-4 employees) using it.

App is going to be on a Hosted Server.

DB session mgmt would be a bit slower, is it? I have thought about cross
site forgery and session hijacking, but the more I think about it, I realize
the lesser I know about it all :(

So thought this would be the best place to start.

On Thu, Apr 22, 2010 at 11:19 AM, Jason Gerfen <jason.ger...@scl.utah.edu>wrote:

How secure would you want it? Is this is a public facing web application?

Are you in a shared hosting environment vs. a dedicated hosting
environment? Do you require alternative session management such as database
or mcache vs. flat file session support?

Have you thought about cross site request forgery's? session hijacking etc?

There are tons of things to take into consideration but setting a flag per
user session is indeed one method of ensuring a user has authenticated.

Vinay Kannan wrote:

Hey Guys,

I need some help on an effficient session management, right now what I do
check if the user has loggedin using his username, and create a
SESSION['logged']=1, setting a login flag actually, I am not sure if this
the best way ?

What do you guys use for sessions, and which is the best possible way ?




PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to