——-
So what happens when the visitor is finished logging in, or has even completed a purchase at the HTTPS website and is pushed back to the HTTP website? Their browser no longer sends the same cookie data to the server because their browsing an entirely different domain. So how is the HTTP website suppose to know which items were just purchased, or that the user is logged in, or what items are in the visitors cart since they might have just completed a purchase? It can’t, that means you have to take session handling to a whole new level and synchronize the data that both the HTTP and HTTPS sessions contain. If you use simple TSID, then you could potentially pass the session id from the HTTP website to the HTTPS website the first time the visitor is pushed there. There is just one MAJOR problem with that, and that’s called session hijacking.
Session hijacking can be a major problem, and can lead to unauthorized disclosure of personal or financial data. By using self-made software or even publicly available HTTP Request Tampering tools that plug right into your browser, you can modify the HTTP Headers to specify another visitor’s session id – this allows them to take over that persons session, perhaps even becoming “logged in” with out having had known any username or password.
To get around this issue you can create a “smart” session synchronizing and authenticity mechanism so that the server manages two different sessions for each visitor – every session data changing operation that occurs while the visitor is browsing the HTTPS website updates both the insecure, and secure session data, but not with the exact same data. In addition, each time the user hits an HTTPS page, the secure session data is infused with any extra data that has been created while the user was browsing the HTTP website. This means that the HTTP website and the HTTPS website can both be aware that the visitor is logged in, and even display their username or cart information right in the layout which is a definite plus for any descent e-commerce layout.
To be continued in Part 3






[...] Managing Sessions accross multiple domains, securely – Part 3 Back to Part 2 [...]