——-
The HTTPS session is the “authority” session, and due to authenticity tests will not accept the HTTP session data as being “valid” as it doesn’t contain the correct information that an HTTPS session data file contains. So while it may still be possible for a user to hi-jack the HTTP session, it’s not possible for them to gain access to another users account or personal information by tampering with the HTTP headers and sending someone’s session id, because once they hit a page or perform an operation which pushes them to the HTTPS website, they immediately become logged out, and any personal information is cleared from the session data. For a user to hi-jack another visitors HTTPS session they’d need to have the ability “sniff” the secure session id, which is sent over the network in an encrypted fashion and is very unlikely – which is just as safe as always using HTTPS.
The process (One-way session passing), roughly:
- Visitor hits the HTTP Website, and is assigned a session id of ‘abcdefg’
- Visitor continues to browse the HTTP Website, adding items to their cart.
- Visitor logs in and is pushed to the HTTPS website, their session id of ‘abcdefg’ is passed in the request.
- HTTPS Website scans the ‘abcdefg’ session, creates and assigns a new HTTPS session id of ‘abcdefg54321’ – This session contains data from ‘abcdefg’ as well as the session id it’s self
- Visitor is pushed back to the HTTP website, continues to browse, adding more items ot their cart
- Visitor tries to ‘check out’ and is pushed to the HTTPS website
- The HTTPS Website scans the HTTP session for changes, such as cart changes, and updates it’s self
- Visitor completes the checkout, the cart items are subsequently removed from the cart and moved to the order history
- HTTPS Website updates the HTTP session data (removes the cart items)
- Visitor is pushed back to the HTTP Website, and has zero items in their cart
