227.19 KB, application/pdf
moving from architecture to the browser product
Assignee: endico → mstoltz
Component: Misc → Security: General
Product: Architecture → Browser
QA Contact: nobody → czhang
Version: 5.0 → other
I don't see how "contexts" would mitigate the problem of a site using its users' permissions on another site without the consent of the user. Suppose, for example, that I want to submit comments to slashdot under someone else's name. I can make the "context" be "submitting form" by setting up a button that looks like a link, adding some hidden form elements, and enticing users to click on the "link". As far as I know, the best a website can do is to escape untrusted data and set tight restrictions on the "referrer" (same hostname, or even an exact URL) for each form. If the referrer is not correct, the site should spit the form back out, with the data included and properly escaped, so that the user can re- submit the form if desired. This method has the unfortunate side effect of blocking out HTTP/1.0 users, since they don't have the "referrer" feature. On the browser side, one possible solution is to warn "Site x is trying to submit a form to site y on your behalf. Site x may think data in this form is coming from you, so proceed only if you trust content on site x to not attempt to masquerade as you on site y." Options on the dialog might include: - submit form - stop submission - view details of form - set permissions (allow www.hotmail.com to submit to hotmail.passport.com) Of course, many users won't want to bother setting these permissions, so they will disable the warning for all cross-site forms, or all cross-site GET forms. Note that this new security policy would have to apply to images and other page elements that might try to "submit" a GET form. Comments and flames ("file a separate bug, you dumbass!") are welcome. ---- I read most of the pages linked to in this bug after I wrote my comment. The pages are very interesting. For future reference, the comments on the slashdot article mentioned in this bug link to http://lwn.net/2000/features/Redirect.phtml as well as back to the page that posts under your name. The lwn page is a good summary of the zope page and includes some interesting examples.
*** This bug has been marked as a duplicate of 38933 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
Reopening bug, as suggested/discussed in bug #38933. See discussion in that bug for background. I'll post to n.p.m.security for further discussion.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
This is a potentially serious issue, but a complex one, and responsibility lies partially (mainly?) with website owners. Marking M20.
Target Milestone: --- → M20
Assigning QA to czhang
Summary: Mozilla, like most web browsers, leaves users vulnerable to a attacks, where cached authentication credentials are leveraged to gain access to resources. → Cached authentication credentials can be used by third-party content using redirects
> responsibility lies partially (mainly?) with website owners No, I completely disagree. How could a server know thatthe request was not performed by a human but a script? *We* have to make sure, our browser does nothing our users don't want it to do. > the best a website can do is to [...] set tight restrictions on the "referrer" [...] > This method has the unfortunate side effect of blocking out HTTP/1.0 users And those who intentionally filter out Referrers.
Target Milestone: M20 → Future
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
To make Mozilla/Firefox the safest browser around shouldn't this be put in a higher severity class? (or is this problem allready fixed but not yet closed yet?)
Assignee: security-bugs → dveditz
Status: REOPENED → NEW
QA Contact: ckritzer → toolkit
You need to log in before you can comment on or make changes to this bug.