|
After digging deeper, this doesn’t seem to be an issue related to any flaw in Magento’s code. User’s visiting your site sometimes surf on proxies. Any non-secure pages are served from your site, to the proxy, then to the user. Your server is going to initiate the session data based on the IP address of the proxy. Secure pages however, by-pass the proxy server entirely and the user is requesting pages straight from your server.
The Magento settings “Validate REMOTE_ADDR”, etc are intended to prevent one user hijacking another’s cart/login session by putting ?SID=<session_id> in the browser. To be successful, an attacker would have to know the session ID of another user currently surfing your site. Magento’s security-check compares the user IP stored in the session and to the current surfer’s IP making the secure request. Since the user visited your non-secure pages via a proxy, the session data contains the proxy’s IP address and it is being compared to the user’s (now-changed) IP address. The comparison fails and Magento kicks the user out to the front page as an invalid session.
IP validation as a means of session security is not presently considered reliable, especially when dealing with proxies:
Session Security/Validation in a Proxy Environment
Recommended fix:
1. Disable all Session Validation Settings except for HTTP_USER_AGENT. *Even this one, really isn’t necessary*
2. If you’re concerned about users blind-guessing session id’s, you can increase your server’s session security by implementing the following in php.ini.
; poll /dev/urandom or /dev/random for better session entropy (available on most Unix systems)
session.entropy_file = /dev/urandom
; read 16 bytes from /dev/urandom
session.entropy_length = 16
;use SHA-1 as the session hash (usually MD5)
session.hash_function = 1
;session ids contain 6 bits: 0-9, a-z, A-Z, "-", ","
session.hash_bits_per_character = 6
Mind you, these PHP ini changes decrease the likelihood of someone hijacking an active session id, which already is extremely difficult. Your web server would likely crash due to the thousands of incoming page requests, before a session was guessed. These changes probably aren’t necessary unless you’re getting a LOT of concurrent users (giving a hacker more valid session guesses).
Here are the .htaccess settings, which *should* work, depending on server configuration (we run Lighttpd so I can’t test)
php_value session.entropy_file /dev/urandom
php_value session.entropy_length 16
php_value session.hash_function 1
php_value session.hash_bits_per_character 6
Of minor concern is webpages indexed in search engines or cached copies of your site that contain session id’s in the URL. Disable SERPs caching of your site if you’re absolutely paranoid, by adding the following to the top of your HTML pages:
<meta name="robots" content="index,follow,noarchive">
<meta name="googlebot" content="noarchive">
|
