246476 - Automatic Javascript form submission should be restricted (prevent cross-site request forgery)

Status: RESOLVED WONTFIX

Description

[John Sullivan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

Warning: the URL above is an *exploit* script. Do not attempt to access it until
you have read this and understand the implications! The URL has been broken in
an obvious way to slow you down here!

LiveJournal (LJ), a popular journal/blog site, is currently suffering from an
exploit which has already spawned a couple of copycats such as the link above.
The basic setup is that some original poster posts an entry to their journal
with either a link to, or a form that submits to a script on a third party site
they control.

That script generates a new HTML form, which is a mock-up of the real LJ New
Post form. It fills the form in with a copy of the original post, and uses
JavaScript to automatically submit the form back to the real LJ New Post script.
LJ's cookie based authentication then allows the post to be made using the
'victim's' credentials. (The usual cookie domain restrictions prevent the third
party site from stealing those credentials directly, thankfully.)

Result: the 'victim' user has a new entry posted to *their* journal, which they
didn't ask for and weren't aware they were about to generate. Because of 

i) the LJ 'Friends' feature (users automatically see all posts from a set of
other users they have selected) 

ii) the well known degrees-of-separation property (most people in the world can
be linked to any other person via a surprisingly small number of "who they know"
steps - and this is true of LJ journals as much as for real world acquaintances) 

iii) the additional fact that most people will implicitly trust a link posted by
a "friend" of theirs on the assumption that they knew what they were posting

These exploits are currently spreading like wildfire across LJ.

Now there are three tacks to dealing with the problem:

i) Sadly, people will have to become less trusting about what they click on,
even if it appears to be posted by a friend. Unfortunately there is nothing in
these posts that gives any indication of what will happen, so this is unworkable
as it implies never clicking on anything ever again!

ii) LJ need to implement some system of making sure that only a form generated
from their own server can be submitted to their form processing scripts.
Cross-site scripting restrictions should ensure that these can not be
automatically submitted by third party sites, and there are known techniques
(adding time-limited, user-specific secrets to the form data produced by
legitimate form requests) to do this. There are already a couple of issues on
their own issue tracking system concerning this. This needs to be done and there
is a certain amount of surprise from those in the know that it isn't already
done like that.

iii) The fact that a third party site can generate and auto-submit a form needs
to be looked at by the browser developers. There are already restrictions in
Firefox/Mozilla concerning what Javascript can do fully automatically, what it
can do only as a result of a real user input event, and what it just can't do.
In this case there is a user input event on Page 1 that sends data or just
redirects to the third party server (URL above). Page 2 then contains a form
with javascript to automatically submit it, with no further user interaction. I
see little reason why form submission ought not to be restricted to Javascript
running only from a user input event, just like opening a new window is
currently restricted. *Especially* (but not only) if the form is submitted to a
server different from that which generated it.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Dave Hodder]

N.B. This is multi-platform and affects both SeaMonkey and Firefox.  I've
reproduced it on Mozilla 1.4, 1.6 and Firefox 0.8.  Suggest changing Product
field to Browser, and Hardware/OS to All.

Mozilla's advanced options already has fine-grained JavaScript control under
Preferences: Advanced: Scripts and Plugins.  It's possible to allow/disallow
scripts doing things like "Move or resize existing windows", "Change the status
bar text", "Create or change cookies", etc.  There's plenty of room in the UI to
add "Submit forms" to this list, preventing document.SOMEFORM.submit(); from
working...

Comment 2

[Thomas Thurman]

*** Bug 246519 has been marked as a duplicate of this bug. ***

Comment 3

[Jesse Ruderman]

This change would break legitimate sites and would not make Cross Site Request
Forgery attacks much harder.

Comment 4

[John Sullivan]

Jesse: you could argue that blocking popups "breaks legitimate sites" too, but
this is a popular feature because it prevents sites from taking control of
aspects of the browser that the user would rather remain in control of.

Can you give an example of legitimate use of automatically submitted forms
without user interaction? If this is an issue then perhaps a whitelist mechanism
similar to that used for popups would be appropriate too. In general I can't see
why this behaviour should be allowed by default though. At the very least it
ought to generate a warning and be cancellable.

Can you also give an example of how such an attack might bypass the block I
propose? (Without social engineering. If you can persuade the user to
deliberately run the exploit for you, there is no hope.)

(I should stress that I don't believe this is a complete solution: the target
sites *need* to protect themselves too, however in the absence of such
protection this would put the user back in control. It's a useful extra measure,
security in depth.)

Comment 5

[Jesse Ruderman]

(In reply to comment #4)

> Can you give an example of legitimate use of automatically submitted forms
> without user interaction?

I believe Hotmail's login system does. 
http://www.cs.hmc.edu/~jruderma/quicksearch.html?query=foo&auto=yes does, but it
uses GET rather than POST.
 
> Can you also give an example of how such an attack might bypass the block I
> propose? (Without social engineering. If you can persuade the user to
> deliberately run the exploit for you, there is no hope.)

It doesn't take much "social engineering" to convince a user to click on
something that looks like a link or even something that looks like a button.  If
the attacker can do that, it isn't even necessary to use JavaScript!

Comment 6

[Hermann Schwab]

Automatic form submission via email: 
A javascript fill in a form amd tries to send it via email.
No problem with my Mozilla Mail, a mail window opens, shows me the form, and I
can decide what to do. I don´t know and don´t care, if Mozilla mail could be
configured to send automatically. I would care, if the default would be to send
automatically.
BIG user problem, if you are using EUDORA as default mailer, Eudora can be
configured to send automatically. Mozilla Mail is my one and only mailclient,
and it is set to be default mail client, on Win98, and Win98SE.

I´ve checked the website also using Opera, Opera pops up a dialog box telling
you a form will be sent via email, and asks, if you want to use another address.

ATTENTION: page will try to send form via email, if JS is enabled:
http://www.nscrypt.com/nisse/

Discussion about this:
http://forums.mozillazine.org/viewtopic.php?t=104344

Comment 7

[Paul Crowley]

Note that bug 246519 discusses a solution to this problem that has not been
discussed here which may be more palatable.

Comment 8

[Gervase Markham [:gerv] (not reading bugmail)]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 9

[Jesse Ruderman]

Wontfix, see comment 3 and comment 5 for reasons.