David Recordon (![[info]](http://p-stat.livejournal.com/img/userinfo.gif){kind=small} daveman692) wrote in ![[info]](http://p-stat.livejournal.com/img/community.gif){kind=small} lj_dev,@ 2006-01-26 16:36:00 |
|
Discussing The Security Changes
As we announced last week in![[info]](http://p-stat.livejournal.com/img/newsinfo.gif)
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.
Shortly before our news post last week, we became aware that it was possible to use the “-moz-binding” CSS attribute within Mozilla and Mozilla Firefox to execute arbitrary offsite JavaScript. As this attribute is designed to allow attaching an XBL transform and JavaScript to any node within the DOM, it is quite easy to use in a malicious fashion. A bug has also been filed in Mozilla's BugZilla tracker to try and address this issue. Over a year ago, we sponsored and developed a patch for Mozilla to support HTTPOnly cookies which emerged in Internet Explorer 6 and would have prevented this attack, though this patch was never included in Mozilla.
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.
Due to the fact that we cannot clean every external CSS stylesheet linked to every time we generate a journal page, this change is required. While it does not fully protect us from some new cross site scripting vulnerability that can be exploited via entries or comments, they are much easier to block, patch, and recover from quickly. With Mozilla deciding to allow the execution of arbitrary JavaScript via CSS, there is no other viable solution than the one we have undertaken.
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.
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.Shortly before our news post last week, we became aware that it was possible to use the “-moz-binding” CSS attribute within Mozilla and Mozilla Firefox to execute arbitrary offsite JavaScript. As this attribute is designed to allow attaching an XBL transform and JavaScript to any node within the DOM, it is quite easy to use in a malicious fashion. A bug has also been filed in Mozilla's BugZilla tracker to try and address this issue. Over a year ago, we sponsored and developed a patch for Mozilla to support HTTPOnly cookies which emerged in Internet Explorer 6 and would have prevented this attack, though this patch was never included in Mozilla.
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.
Due to the fact that we cannot clean every external CSS stylesheet linked to every time we generate a journal page, this change is required. While it does not fully protect us from some new cross site scripting vulnerability that can be exploited via entries or comments, they are much easier to block, patch, and recover from quickly. With Mozilla deciding to allow the execution of arbitrary JavaScript via CSS, there is no other viable solution than the one we have undertaken.
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.