Update things.

[zotz]

Useful summary here.

Executive summary : Don't click on a link before making sure that you trust the site it's linking to.

Comments

[http://users.livejournal.com/_nicolai_/]

Also, active content bad.

[zotz]

Well, yes. Whenever I moan about it people tell me I'm overreacting, though.

[http://users.livejournal.com/_nicolai_/]

I think the real fix is for the browser to warn or disallow posting to a different site than where the page comes from - causing "this page wants to submit to that site - are you sure?" at least.

[zotz]

That would definitely be sensible.

[deliberateblank.livejournal.com]

This is used too often for the warning not to be disabled by most users though. If disabled, it has no value.

The fix I suggested in my Firefox bug (restrict Javascript from automatically submitting forms without user interaction) would stop it.

LJ will need to protect their forms against attacks like this though. Soon, hopefully.

[inferis.livejournal.com]

That would be useful, granted, and I think there is something like that in IE ("Warn if form submission is being redirected" or similar). What would be equally useful is developers of sites like LJ actually checking the HTTP referrer and making sure the form submission comes from their site, it's a rookie forms hack which shouldn't be so easy to get away with.

[ciphergoth.livejournal.com]

Checking the referrer field is one fix, but not all browsers present this field. Check the fix I propose in lj_dev

[http://users.livejournal.com/_nicolai_/]

I think checking the referrer is not a complete fix because a malicious client can submit a faked referrer. Some proxies strip referrer, so you must also not reject the post if the referrer is wrong but instead confirm it.
Your second fix looks sound. It fixes livejournal.
I think a browser should -also- warn because this problem could happen to a lot of sites authenticated by a stored cookie and they won't all be well-written even if a server-side protection method is available.

[ciphergoth.livejournal.com]

A malicious client can't get the user's cookie though. Unless the client is malware running on the user's machine, of course, but in that instance you're completely cooked no matter what.

I agree that a browser-side fix is desirable. I propose that if site X POSTs a form to site Y, that only those cookies that both X and Y can see go with the form.

[inferis.livejournal.com]

only those cookies that both X and Y can see go with the form

That's not strictly what's happening here though, is it? LJ is merely being told by the posted form to check it's own cookies. The posting site doesn't (and cannot) know even if the cookie exists...

[ciphergoth.livejournal.com]

Site X contains a form. When that form is submitted, it is submitted to LiveJournal via a POST request. Your browser notices that it has cookies for LJ, and includes them with the request; LJ checks the cookies, and treats the POST request as authenticated.

I'm proposing that the browser NOT ship the cookies with the POST request to LJ; only cookies that would be shipped also to site X should be shipped.

So if you have cookies from fish.example.com, fosh.example.com, and example.com, and the form is on fish, and it's POSTed to fosh, then only the cookie from example.com goes with the form.

[inferis.livejournal.com]

Forgive me if I'm mistaken, but I'm not sure that's how the exploit or cookies work anyway. Yes, only the cookies at a common domain level should be transmitted to the server, but that's what happens now anyway. Cookies from Site A.com aren't going to be transmitted to B.com and never will be because that's the way cookies work (as far as I understand it, and assuming the browser isn't malicious or broken)...the foreign page that posts to LJ doesn't, never has and never will contain *any* cookies whatsoever...it doesn't even need to, all it includes is a hidden field which LJ interprets as a notice to check the cookies it already owns. They are in no way transmitted from one site to another.

This is, of course, assuming that my understanding of cookies is not in some way flawed :)

[ciphergoth.livejournal.com]

I'm frustrated at my inability to explain this to you, and I may give up, but I'll try again.

Cookies are not transmitted "cross-site" as you say. This attack only requires cookies from LJ to be transmitted to LJ. These cookies are sent whenever the browser makes an HTTP request to LJ. The point is that there are circumstances where the browser should not send cookies for LJ to LJ, even if it has them. Those specific circumstances are when the type of request is a POST request, and the cause of the request is a form submission, where the form comes not from LJ itself but from Site X. (Where "Site X" is any site not authorised to see the cookies, ie any site other than LJ itself).

[inferis.livejournal.com]

To add to the frustration, I thought this through after I posted and went out, and ended up realising exactly what you meant :D

Sorry, me being slightly dumb and arrogant for a moment there (nothing unusual about the latter, I'm afraid :)

[inferis.livejournal.com]

Fair point. I have to admit, I usually go for something like the solution you've suggested on my own site designs. I include some hidden field with the current session ID, or similar, on it and if the posted form doesn't include this when I check the values it denies the transaction...