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
<input type="hidden" name="secret-expiry" value="2004-06-11_20:20:17">
<input type="hidden" name="secret-value" value="OCBVYgI exQEqdmL9HPK3GHT1p0=">
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:
Footnote: remember, never post support questions to

← Ctrl ← Alt
Ctrl → Alt →
← Ctrl ← Alt
Ctrl → Alt →