ciphergoth
in
lj_dev
Preventing the sausage attack UPDATED
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 request.
If 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 probably been directed to the wrong place. This forum is for HIGHLY TECHNICAL discussion among programmers on changes to the program code that drives LJ. This post is about what changes to LJ are needed to prevent the attack from working. It assumes you're familiar with HTTP, POST requests, cookies, JavaScript cross-site scripting restrictions, and other technical details that affect the attack and its prevention. If you're not interested in all that but just want your LiveJournal fixed, please file a support request and stop reading here.
There's a meme going around that redirects you to a page that submits an entry to LJ on your behalf, using JavaScript. In its current form the meme is harmless, but it shows a security hole that should be fixed.
See http://www.livejournal.com/users/nightway/63251.html - but beware that filling in the form will update your journal without your consent.
Here's how it works: you fill in a form you see on someone else's journal. This takes you to a third-party page. That page includes a form very much like the LiveJournal update form. JavaScript on that page then automatically fills out the fields on the form, and submits it, without your intervention.
I see two ways to prevent this attack. One would be to check the "referrer" field on LJ form submissions.
The other would be to include a hidden, user-specific secret on each form, that can be checked at submission time. If the secret doesn't check out, just take the user to a "preview" page instead of acting on their request.
It could be as simple as
where the first value is when the form is valid until, and the latter is HMAC-SHA1(user-secret, secret-expiry).
I think this provides a total defence. I don't know how hard this would be to add, though.
Update: ravenblack proposes a very nice improvement on this technique which makes it more efficient and simpler to implement. If I've understood the proposal correctly: When you set the auth cookies, just set an extra cookie which is a randomly generated string. Include the cookie as a hidden field on every form, and make sure the cookie and the hidden field match when you get a form. It's just as secure and you don't have to do any crypto or store anything in the database. However, it can't be made to work with form submission from comment emails; for that, you need something more like what I proposed originally.
Footnote: remember, never post support questions to lj_dev or similar forums - post them in Support. Thank you.
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 request.
If 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 probably been directed to the wrong place. This forum is for HIGHLY TECHNICAL discussion among programmers on changes to the program code that drives LJ. This post is about what changes to LJ are needed to prevent the attack from working. It assumes you're familiar with HTTP, POST requests, cookies, JavaScript cross-site scripting restrictions, and other technical details that affect the attack and its prevention. If you're not interested in all that but just want your LiveJournal fixed, please file a support request and stop reading here.
There's a meme going around that redirects you to a page that submits an entry to LJ on your behalf, using JavaScript. In its current form the meme is harmless, but it shows a security hole that should be fixed.
See http://www.livejournal.com/users/nightway/63251.html - but beware that filling in the form will update your journal without your consent.
Here's how it works: you fill in a form you see on someone else's journal. This takes you to a third-party page. That page includes a form very much like the LiveJournal update form. JavaScript on that page then automatically fills out the fields on the form, and submits it, without your intervention.
I see two ways to prevent this attack. One would be to check the "referrer" field on LJ form submissions.
The other would be to include a hidden, user-specific secret on each form, that can be checked at submission time. If the secret doesn't check out, just take the user to a "preview" page instead of acting on their request.
It could be as simple as
where the first value is when the form is valid until, and the latter is HMAC-SHA1(user-secret, secret-expiry).
I think this provides a total defence. I don't know how hard this would be to add, though.
Update: ravenblack proposes a very nice improvement on this technique which makes it more efficient and simpler to implement. If I've understood the proposal correctly: When you set the auth cookies, just set an extra cookie which is a randomly generated string. Include the cookie as a hidden field on every form, and make sure the cookie and the hidden field match when you get a form. It's just as secure and you don't have to do any crypto or store anything in the database. However, it can't be made to work with form submission from comment emails; for that, you need something more like what I proposed originally.
Footnote: remember, never post support questions to lj_dev or similar forums - post them in Support. Thank you.