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.
Thanks,
Vinay
On Thu, Apr 22, 2010 at 11:19 AM, Jason Gerfen <jason.gerfen@xxxxxxxxxxxx>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
is
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
is
the best way ?
What do you guys use for sessions, and which is the best possible way ?
Thanks,
Vinay
--
Jas
--
Jas
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
