As we announced last week in news, we have changed the canonical URL of most journal, community, and syndicated content. We have also now changed our cookie handling as Brad previously described. In the end this means that it is much more difficult to steal a useful cookie. Our goal with our new cookie scheme is to limit the damage that can occur when your cookies do get stolen, which we're just going to assume is inevitable, as vulnerabilities have been found in all major browsers and we're quite sure new vulnerabilities will continue to be found.
We immediately altered our cleaner to strip this attribute from entries and comments, though also realized that wasn't even half the battle. As we allow custom CSS in many of our styles, as well as the ability to link to an external stylesheet in a variety of fashions, it was quite possible to take advantage of this exploit and hijack the session cookie of any user who views your journal. As we, along with many other sites, used one cookie to authenticate a user, this cookie was quite powerful if stolen. If the user had not chosen to bind their cookie to their IP address, a malicious user could steal it, login as that user, deface the account and spam with it, as well as modify that user's style to include the exploit thus causing this problem to spread much like a virus.
Borrowing the idea from another development team within Six Apart, we decided we needed to break our cookies into three categories. One cookie would be our master cookie, this cookie would only be accessible on www.livejournal.com where we will not display untrusted content. A second cookie will be accessible on all subdomains of livejournal.com, though it only will say if you are logged in or not; it is solely for optimization. We then will issue one cookie for each journal you visit. This cookie will be only accessible on username.livejournal.com or community.livejournal.com/username as it is limited to a single journal. This cookie will only grant you the permission to read protected entries and post in the particular journal. This means that if the journal owner steals your cookie, they will be able to do nothing more than view their journal as if they are you. In the end you will have n+2 cookies, with n being the number of journals you visit.
We've already taken a variety of steps to further protect your account such as we've implemented a page where you can see all of your login session, now require your password to change your email address, and now send secure password reset emails. We also are planning future improvements, especially related to external CSS stylesheets, and hope everyone realizes the amount of attention we place on the security of every account. We're more than happy to answer any questions you have in regards to the changes we've made over the past week, though also hope it is understood that we are limited in what information we can share when actively dealing with a situation such as this.