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.
See http://www.livejournal.com/users/nightway/63251.html - but beware that filling in the form will update your journal without your consent.
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: 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.