Preventing the sausage attack UPDATED

[ciphergoth]

Update: note for new readers

I probably can't answer your questions about the attack. If bad things have happened to your journal, as a result of this attack or otherwise, please file a support requestIf you got bitten by a new attack on LJ that's recently become popular, and someone directed you here for more information, I'm sorry but you've

Comments

[bradfitz]

But then we break LJ clients that do a POST to /update.bml instead of going through the protocol handler.

Yes, they're lame, but they exist.

Maybe we only do the secret-expiry/value check if there's a referer. (from anywhere: LiveJournal or external)

Then clients who just do an /update.bml POST are unaffected.

?

Re: Handling dumb clients

[ciphergoth]

Do those clients use cookies? Maybe you only do the secret-expiry/value check if you're authenticating with a cookie.

[jgrafton]

Do those LJ clients set something for the Referer field, though?

If they don't, then you could just allow POSTs that have no referer field (bad LJ clients) or have the appropriate referer (the normal update page).

The only issue is really if these broken LJ clients are just websites, because then the browser will set the referer.

Re: Cookies are the problem

[ciphergoth]

I prefer my secret approach - relying on the Referrer header just seems a bit fragile to me. Some users switch off the sending of this header for security reasons in browsers that offer that control; perhaps there are still browsers out there that don't send it, or new browsers for PDAs or suchlike,

It's cookie authentication which is the problem, because you can make people's browsers do things on other websites and the cookies show it's them. If these clients don't use cookie authentication - which I suspect they don't - then using the secret-expiry/value check when cookies are used for authentication means everybody's happy.

Re: Cookies are the problem

[hughe]

firstly: posting, or any other forms, can't rely on javascript. there always needs to be a non javascript option. therefore the fundemental solution needs to be a non-javascript one.

secondly: for the third-party to get your secret code server-side it would need your cookies :) (which it wouldn't have). OR client side, it would need to access content of another cookied frame etc. (which, IE security non-permitting, it doesn't have access to)

Re: Cookies are the problem

[deliberateblank]

If the secret is specific to a logged-on user, and only generated when a valid cookie is sent from the client, then MITM won't be possible: the third party won't be able to pull a valid MAC from LJ for the user as they won't have access to the user's LJ cookie.

Cross-site scripting restrictions should prevent them from finding out what any of the user's MACs are from forms requested by the user.

Re: Cookies are the problem

[ciphergoth]

I think you have to. On a browser where the JavaScript has unbounded power to do what the hell it wants, no measure will prevent this attack from working.

Re: Cookies are the problem

[hughe]

yes cookies are the problem and using referrers in not a solution. but an expiry date might also be a problem. too short and it will expire before posts can be made/options can be set. too long and you might as well not have one.

one possible option would be for a secret expiry to be only set when another secret is requested for that type of post. again still some problems.

- secret requested for posting entry: secret1 returned
- secret requested for adding a friend: secret2 returned
- secret requested for posting an entry: secret3 returned, expiry set on secret1

etc.

Re: Cookies are the problem

[ciphergoth]

No, there's no problem with making the expiry period very long - this information should be totally inaccessible to the attacker. I only have an expiry period at all because, well, it's good practice.

[pyran]

Yes, but those clients are wrong. I have a hard time feeling bad about clients that don't use the APIs that exist specifically for clients.

[ttyv0]

This feature concerns not only /update.bml POST.

See source of http://darkman.4host.ru/kolbasa/addfriend.htm.

Re: A little more warning?

[pamc]

I'd recommend to anyone wanting to look at that source make sure they've logged out of LJ first.

[bryant]

I think breaking those clients is legitimate. It's unfortunate, but given the clunky nature of the alternative, it's inevitable.

[schnee]

Those clients are broke to begin with; fixing this issue will just put more pressure on their authors to fix them, which is a good thing.

Besides, breaking existing apps is always acceptable when you close a security hole.