Giorgio Maone wrote:... secure cookie forcing/management forces only cookies which have been set through an HTTPS connection to be "secure".
Please ensure that *.wachovia.com is in HTTPS Behavior and Cookies, then visit the *secure* login site, https://onlineservices.wachovia.com/auth/AuthService?action=presentLogin&url=https%3a//onlineservices.wachovia.com/NASApp/NavApp/Titanium%3faction=returnHome
*not* the insecure home page, http://www.wachovia.com
Note that you still receive one insecure cookie from wachovia.com, s_sess.
I am hoping that the secure cookie, TLTSID, is the one that a thief would need to hijack the session, and that the insecure one is only generic information, such as OS, browser, etc. In which case, there is no cause for concern. But it is still the case (F2, reminder) that an insecure cookie made it through an HTTPS connection, even with Force Secure in place.
Of course cookies which have been set through plain HTTP, if sensitive, are already compromised downstream and there's nothing you can do about it aside forcing HTTPS for the site.
After clearing the above cookies, etc. with HTTPS Force in place, please visit the home page, http://www.wachovia.com
. It correctly sets an HTTPS connection, as forced. Yet this time, three insecure cookies are set, despite there never having been an HTTP connection.
Again, one hopes that these insecure cookies, OriginalReferrer, CookiesAreEnabled, and s_sess, contain nothing sensitive. (RefControl takes care of my referrers now, thank you very kindly, Sir!
) And that the secure cookie received upon login, TLTSID, contains the goodies. So forcing HTTPS for the site, although successful in setting the HTTPS connection, still does not force all secure cookies. Please tell me that this is nothing to worry about. Thanks.
Is this different in F3?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US at an expert level; rv:18.104.22.168) Gecko/20081217 Firefox/22.214.171.124 diehard