| Security and Privacy Proposal | Last Update: 7th April, 2005
Article ID: 4 |
- Introduction
- Force Cookie Usage
- Verifying SSL_SESSION_ID
- Search Spider Engine Session Prevention
- Session Regeneration
- Implementation Progress
- Development Issues
Introduction
As communication between the client (browser) and server is made in a stateless mode, it is not possible to know who the client is and where they currently are on the website.
The cookie protocol is an implementation used on websites that allow client tracking to occur. This allows for greater interactivity between client and server as the server is able to tell who the client is and where they currently are on the website.
Without this form of implementation, shopping online or banking online would not be possible.
The cookie protocol works by allowing the website to store a file on the clients computer which the client sends on every subsequent request made to the website. The website can store any text information required in the cookie file but must remain within a 4 kilobyte size limit.
For privacy reasons, the cookie file stored by the website on the clients computer can only be read by the website that stored it. This is controlled by the url domain of the website. www.domain-one.com can only access cookie files which www.domain-one.com stored, not the cookie files which www.domain-two.com stored.
For the website to be able to track the client, a session ID is uniquely created and stored as a cookie on the clients computer.
This allows the website to track the client via the uniquely created session ID and to know if the client is in an authenticated state with the web application or not.
As it is possible for the client to disable the use of cookies on their browser, a fall back mode is usually implemented on the web application to still be able to keep intact of the session between client and server.
The fall back method involves appending the uniquely created session ID to all links on the website such as:
http://www.domain-one.com/index.php?session_id=defw452r43tWEFw34352
Depending on the web application, having the session ID on the url can pose security and privacy related issues.
If the client copies the complete url to share with a friend, that friend will share the session due to the session ID existing in the url. If the original client is authenticated with the web application, their friend will have access to the account information of the original client.
Another example is if the clients requests goes through a proxy server - the proxy server logs all requests including the parameters of the url which will contain the session ID. It is possible for the proxy site administrator, or hacker, to gain access to the logs and to hijack the clients session with the web application simply by taking the logged session ID.
The Security and Privacy Proposal was made to address these issues as they can be serious for an online shop web application where the customers privacy is top priority to secure.
As security and privacy related issues vary from solution to solution, the realization of this proposal is made to be configurable in the following key issues:
- Force Cookie Usage
- Verifying SSL_SESSION_ID
- Search Spider Engine Session Prevention
- Session Regeneration
Force Cookie Usage
The only common method that exists to prevent the session ID from appearing on the url at all is to force the usage of cookies for the web application.
The parameter for this key issue is titled SESSION_FORCE_COOKIE_USE.
Clients that have cookies enabled will be able to perform secure transactions with the web application, whereas the clients that have cookies disabled will not be able to perform such actions.
Such actions for osCommerce include:
- Adding a product to the shopping cart
- Logging on or creating an account
- Viewing or modifying personal account information, including orders made previously
- Proceeding through the checkout procedure
When SESSION_FORCE_COOKIE_USE is enabled and the client has cookies disabled, a page will be displayed in place of the above actions describing to the client in friendly terms that they should enable cookies on their browser in order to proceed.
This method of notifying the client will still give them the chance to look around the site - instead of blocking them out entirely as is common on various online stores and websites.
When the SESSION_FORCE_COOKIE_USE parameter is enabled, a cookie will always be set on the clients browser and will always be read on every page request made. This allows osCommerce to check for the cookie and to take appropriate action of allowing the transaction to occur, or to forward the client to the friendly enable cookie page.
As the cookie is set on the top level domain of the web server, the secured https server must also exist on the same domain.
For example, the force cookie usage implementation will work for the following servers:
http://www.domain-one.com
https://www.domain-one.com, or https://ssl.domain-one.com
but not for the following servers:
http://www.domain-one.com
https://ssl.hosting_provider.com/domain-one/
The ssl.hosting_provider.com example is using a shared SSL certificate used for secure transactions. This can easily be fixed to work with the force cookie usage implementation by purchasing and installing a dedicated SSL certificate for the domain-one.com domain.
It is possible to bypass the cookie check by appending the session ID to the url when the client moves from HTTP to HTTPS state, or from HTTPS to HTTP state; however the main goal this implementation is trying to achieve is to not place the session ID on the url at all which would occur if the clients browser had cookies disabled.
A simple case of this implementation failing where different HTTP and HTTPS domains are used is when the client first visits the online store (cookie is set for HTTP domain) and clicks on the secure Login link (cookie is set for the HTTPS domain).
As cookies cannot be read on the same request made when they are set for the first time, the Login page cannot access the HTTPS domain cookie as it has just been set, and it can also not read the HTTP domain cookie as it is another domain.
Even if the clients browser has cookies enabled, the cookie cannot be read and the client will be directed to the friendly cookies-must-be-enabled page.
The SESSION_FORCE_COOKIE_USE parameter was originally set to be enabled by default, but with the problems that will occur on shared servers using shared SSL certificates it has been decided that the parameter should be set to be disabled by default.
The cookie set is titled cookie_test and will exist on the clients computer for 30 days.
Verifying SSL_SESSION_ID
When the client requests a secure https page, the clients browser automatically generates an ID titled SSL_SESSION_ID, which is used by the server to authenticate the client during secure page transmissions.
This value can be stored as part of the clients session to verify on each https page request made. The parameter to enable this verification is titled SESSION_CHECK_SSL_SESSION_ID and is disabled by default.
If enabled, when osCommerce detects that another SSL_SESSION_ID value has been generated, the client is redirected to a friendly page stating that another value has been detected and that they must relogon to the store again to continue their action.
This assures that no other person has hijacked the clients session which would automatically generate a new SSL_SESSION_ID when making secure https requests to the server.
This is disabled by default as a SSL certificate is needed for the secure domain, and because not all webservers or browsers support or generate SSL_SESSION_ID values.
It is known to work with the Apache server with mod_ssl, and with Microsoft Internet Explorer, Netscape, and Mozilla browsers.
Konqueror 3.1, available for KDE on Linux, does not generate SSL_SESSION_ID values which would show the friendly SSL_SESSION_ID information page to the client on each secure https request made.
Search Spider Engine Session Prevention
When the search spider engine session prevention implementation is enabled, the browser of the client is retrieved and if it matches a list of search engine spiders, the session is bypassed and no session IDs will be indexed with the urls the search engine spiders collect.
This is because search engine spiders do not accept cookies. If the force cookie usage implementation is disabled, session IDs would have been added to the urls to maintain a session state.
It is considered to be dangerous when search engine spiders index urls which contain session IDs, as the urls will appear as links on the search engine result sets which, when clicked on by multiple clients, will generate shared sessions.
The difference between the force cookie use implementation and the search spider engine session prevention implementation, is that the force cookie use implementation works on a global scale whereas the search engine spider session prevention implementation works only against a list of known search spider engines.
The parameter to enable search spider engine session prevention is titled SESSION_BLOCK_SPIDERS, and when enabled, is only active when SESSION_FORCE_COOKIE_USE is disabled.
Session Regeneration
To further secure the clients session, their session ID generated upon entering the online store will be regenerated when they either log on with their username and password or when a new user account is created.
The parameter to control the session ID regeneration is titled SESSION_RECREATE, and only works for servers with PHP 4.1 or greater installed and when both HTTP and HTTPS top level domains are the same.
This is due to the current session cookie having to be reset for a new session cookie to be generated.
Implementation Progress
All key issues have been realized in 2.2-MS2-CVS, and will appear in versions 2.2-MS2 onwards.
The realization will be further extended to add the possibility of verifying the client through their IP address and/or browser user agent.
Work is also in progress to allow the force cookie usage implementation to work on servers with shared SSL certificates.
Development Issues
The cookie_test cookie set for 30 days can cause development hiccups when testing if urls contain the session ID.
When development for this proposal realization occurs with SESSION_FORCE_COOKIE_USE enabled, the site related cookies on the browser must be manually deleted, and the cookie_test cookie should be set for only 0 days, which sets the cookie for the browser-session only (for however long the browser is open).
Simply closing all browser instances (including Mozillas Quick Launch feature) will delete the cookie from the browsers memory.
The cookie_test cookie is set in catalog/includes/application_top.php via the tep_setcookie() function.
