Log in

No account? Create an account
January 26th, 2006 - LiveJournal Development [entries|archive|friends|userinfo]
LiveJournal Development

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

January 26th, 2006

Apache2 + LJ fun [Jan. 26th, 2006|04:30 pm]
LiveJournal Development


So, I decided to ignore the warnings about the LiveJournal code not working on Apache2 and try it anyway (using Apache2::compat for now). Oddly enough, some of the problems I've run into so far are mod_perl ones (I'm using 2.0.2) rather than LiveJournal ones...

  • PerlSetEnv doesn't seem to have any effect in a VirtualHost, even though the docs say it should work (this is where someone else's attempts failed). Moving it to global scope made it work. This would probably also apply if porting to mod_perl 2.0 properly.
  • Apache::LiveJournal::Interface::S2 - 'Bareword "OK" not allowed while "strict subs" in use', solved by changing the include to 'use Apache::Constants qw(NOT_FOUND OK);'. Not sure what causes this (but the change might still be necessary if porting properly)...
  • Apache2::compat "doesn't provide a complete back compatibility layer" for Apache::Constants. BAD_REQUEST is missing (it's Apache2::Const::HTTP_BAD_REQUEST in mod_perl 2). This breaks FotoBilder.pm
  • Apache::Log and Apache::URI aren't provided by Apache2::compat, though their functionality is
  • Apache::compat doesn't work outside of Apache. update-db.pl indirectly depends on Apache::Constants. If anyone actually ports LJ, this should work properly.

  • It still doesn't work (BML docs not handled, DocumentRoot not set, etc - IOW, the httpd.conf injection doesn't seem to work), though at least Apache starts now. I wonder how much work porting it to mod_perl 2 (rather than using Apache2::compat) would be?
link5 comments|post comment

Discussing The Security Changes [Jan. 26th, 2006|04:36 pm]
LiveJournal Development


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.
link129 comments|post comment

[ viewing | January 26th, 2006 ]
[ go | Previous Day|Next Day ]