Cached authentication credentials can be used by third-party content using redirects

NEW
Assigned to

Status

()

Core
Security
P3
normal
17 years ago
3 years ago

People

(Reporter: Martijn Pieters, Assigned: dveditz)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Trunk
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
For a more complete description of the problem, see the URL. The page at this
URL is a Wiki, anyone with a Zope.org account (free, no strings) can add
comments.

Two examples of such an attack (one executed in a lab environment, one recently
seen in action on Slashdot):

- Deletion of a Netscape Enterprise server install with a redirect. See issue
description at URL attached.

- Posting of browser information to a forum, revealing OS information of the
person attacked. See the comments accompanying this slashdot article (read at
level 0):

  http://slashdot.org/article.pl?sid=00/05/19/190219

Other articles on the subject:

  Edd Dumbill (managing editor of XML.com):
  http://weblogs.oreillynet.com/edd/stories/storyReader$52
  http://weblogs.oreillynet.com/edd/discuss/msgReader$54
  
  LinuxNews.com:
  http://www.linuxnews.com/news/?1,145

I believe that browsers can help mitigate the risks by providing additional
context with requests, so a server can assess wether or not a request was made
by the user itself.

Such additional context should not reveal any privacy information, so there
isn't any reason for proxies or firewalls to filter this information out. I am
thinking along the lines of something like "Context: Javascript", or "Context:
Redirect".

More discussion on this issue is needed, it isn't an easy one to solve.

Comment 1

17 years ago
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

Comment 2

17 years ago
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
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 4

17 years ago
vrfy
Status: RESOLVED → VERIFIED
(Reporter)

Updated

17 years ago
Blocks: 38933
(Reporter)

Comment 5

17 years ago
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.
No longer blocks: 38933
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Updated

17 years ago
Blocks: 38933

Updated

17 years ago
No longer blocks: 38933

Updated

17 years ago
Depends on: 38933
This is a potentially serious issue, but a complex one, and responsibility lies
partially (mainly?) with website owners. Marking M20.
Target Milestone: --- → M20

Comment 7

17 years ago
Assigning QA to czhang

Comment 8

17 years ago
Shortening SUMMARY.
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

Comment 9

17 years ago
> 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.
Retargeting Future.
Target Milestone: M20 → Future

Updated

17 years ago
Keywords: mozilla1.0

Updated

17 years ago
QA Contact: czhang → junruh

Comment 11

17 years ago
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer

Comment 12

12 years ago
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?)

Updated

12 years ago
Blocks: 322301

Updated

11 years ago
Assignee: security-bugs → dveditz
Status: REOPENED → NEW
QA Contact: ckritzer → toolkit

Comment 13

7 years ago
Created attachment 462837 [details]
How I used the log on , to get various credentials
You need to log in before you can comment on or make changes to this bug.