To conclude the discussion about session management, here are some best practices to demonstrate that a robust scheme requires serious thinking:
• Create a session token upon first visit.
• When performing authentication, destroy the old session and create a new one.
• Limit session lifetime to a short period (a few hours).
• Destroy inactive sessions regularly.
• Destroy sessions after users log out.
• Ask users to re-authenticate before an important task is performed (e.g., an order is placed).
• Do not use the same session for a non-SSL part of the site as for the SSL part of the site because non-SSL traffic can be intercepted and the session token obtained from it. Treat them as two different servers.
• If cookies are used to transport session tokens in an SSL application, they should be marked “secure.” Secure cookies are never sent over a non-SSL connection.
• Regenerate session tokens from time to time.
• Monitor client parameters (IP address, the User-Agent request header) and send warnings to the error log when they change. Some information (e.g., the contents of the User-Agent header) should not change for the lifetime of a session. Invalidate the session if it does.
• If you know where your users are coming from, attach each session to a single IP address, and do not allow the address to change.
• If you can, do not accept users coming through web proxies. This will be difficult to do for most public sites but easier for internal applications.
• If you can, do not accept users coming through open web proxies. Open proxies are used when users want to stay anonymous or otherwise hide their tracks. You can detect which proxies are open by extracting the IP address of the proxy from each proxied request and having a script automatically test whether the proxy is open or not.
• If you do allow web proxies, consider using Java applets or Flash movies (probably a better choice since such movies can pretend to be regular animations) to detect the users’ real IP addresses. It’s a long shot but may work in some cases.
• Web users can upload only jpeg, gif, png files not php extension
• We can place a blank index page in each directory in question and users can not execute php etc scripts from the image folders or image/document upload folders.
• Upgrade apache current version (2.0) to newer version (2.2)
good article Manoj, keep it up