Closed
Bug 246476
Opened 17 years ago
Closed 16 years ago
Automatic Javascript form submission should be restricted (prevent cross-site request forgery)
Categories
(Core :: Security, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jsfbbz, Unassigned)
References
(Blocks 1 open bug, )
Details
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•17 years ago
|
||
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•17 years ago
|
||
*** Bug 246519 has been marked as a duplicate of this bug. ***
Updated•17 years ago
|
Assignee: firefox → dveditz
Severity: normal → major
Component: General → Security: General
OS: Windows 2000 → All
Product: Firefox → Browser
QA Contact: firefox.general
Version: unspecified → Trunk
Comment 3•17 years ago
|
||
This change would break legitimate sites and would not make Cross Site Request Forgery attacks much harder.
Reporter | ||
Comment 4•17 years ago
|
||
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•17 years ago
|
||
(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•17 years ago
|
||
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•16 years ago
|
||
Note that bug 246519 discusses a solution to this problem that has not been discussed here which may be more palatable.
Updated•16 years ago
|
Summary: Automatic Javascript form submission should be restricted → Automatic Javascript form submission should be restricted (prevent cross-site request forgery)
Comment 8•16 years ago
|
||
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•16 years ago
|
||
Wontfix, see comment 3 and comment 5 for reasons.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Updated•11 years ago
|
Assignee: dveditz → nobody
You need to log in
before you can comment on or make changes to this bug.
Description
•