Open Bug 479038 Opened 16 years ago Updated 6 months ago

Should the suspicious-auth warning apply to all loads? Should URI userinfo be banned?

Categories

(Core :: Networking, defect, P2)

Product:
Core
Component:
Networking
Type:
defect
Points:
7

Tracking

()

People

(Reporter: rinsmaster, Unassigned)

References

Details

(Keywords: sec-want, Whiteboard: [sg:investigate] [necko-triaged] [necko-priority-next][patch-available])

Attachments

(1 file)

WIP: Bug 479038 - referenced url containing userinfo or password must not be loaded
48 bytes, text/x-phabricator-request
Details | Review
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121623 Ubuntu/8.10 (intrepid) Firefox/3.0.5 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121623 Ubuntu/8.10 (intrepid) Firefox/3.0.5 Normally when trying to access a page with HTTP authentication (whether it is by a form, an img tag, an iframe, or anything else) then Firefox prompts the user. When using this javascript this won't happen. Using this an attacker could even change a user's router settings without him noticing. Reproducible: Always Steps to Reproduce: 1. Make sure you're logged out on the HTTP authed site. 2. Submit a form that tries to log into this site: You'll get a confirm dialog, press cancel 3. Now go to the page with this javascript in it. 2. Submit that form again and you're logged in. Actual Results: I was able to log users in to a HTTP authenticated site without them knowing it. Expected Results: Give the same dialog as in step 2 ("You're about to visit X as Y. Cancel/OK") Here's the test page I used: <html> <head> <title>test</title> <script type="text/javascript"> im = document.createElement('img'); im.src="http://test:test@site.com/secured/"; document.appendChild(im); </script> </head> <body> <form method="post" action="http://test:test@site.com/secured/"> <input type="submit"> </form> </body> </html>
Why is this a problem? * Site A is passing an explicit username/password pair that it already knows * It can only issue a GET to site B * It can't read any of the data from site B I think this is the way it's supposed to work.
You're right, It can't read data, but it can send a request, for example a post request which can do some serious stuff in some cases. Apart from whether or not this is serious. In case of for example: <img src="http://test:test@site.com/secured/"> or <iframe src="http://test:test@site.com/secured/"> Firefox will give the user that prompt, using this javascript, it won't. Opera for example gives the same prompt as firefox does in the above situations, even with this javascript.
I forgot to mention this: "* It can only issue a GET to site B" No, it can also issue a POST, by first using this javascript, and then a form (which could be sent onload for example), the user won't get a single warning, because when posting the form, the javascript has already logged the user in.
But... the username and password are known by site A, so why does it matter whether it prompts the user? Couldn't site A just submit the request directly from their server? How is this any different from submitting a form without a specified username and password?
Because the user can hit a server that evil site A can't on its own, e.g. the router in comment 0 or some other intranet site. This is exactly the scenario we added the prompting for. IE has taken a more draconian approach of disallowing URLs with user:pass supplied and that's actually safer.
We don't warn on images, whether in-line or injected via script, because the warning was a phishing defense. You don't see the URL for an image, so something like http://www.mybank.com:secure-login@evil.com/image.png isn't going to make you think you were at "MyBank". When we load that page at the document level maybe you would get fooled and not realize you were at evil.com so that's what the warning is about. Basically the originally described issue is "as designed", the warning wasn't designed for that case. Rather than immediately close the bug, however, should we change the design? IE seems to have gotten away with blocking URIs with userinfo and the RFCs recommend against using them. We could do the same, although we know from when the suspicious-auth dialogs were added that lots of people care about this case. Maybe allowing userinfo could depend on a pref and the minority that really do use this feature can turn it on.
Group: core-security
Status: UNCONFIRMED → NEW
Component: Security → Networking
Ever confirmed: true
Product: Firefox → Core
Summary: Javascript allows to visit authenticated site in background without confirmation → Should the suspicious-auth warning apply to all loads? Should URI userinfo be banned?
Whiteboard: [sg:investigate]
QA Contact: firefox → networking
Keywords: sec-want
Hi all, This has been published in various security blogs in Spanish as an example of how to do client-side attacks, see duplicated bug 862450 for an example. Safari is the only one blocking this right now.
Whiteboard: [sg:investigate] → [sg:investigate][necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
QA Whiteboard: qa-not-actionable

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --
Severity: -- → S2
Priority: P3 → P2
Whiteboard: [sg:investigate][necko-backlog] → [sg:investigate] [necko-triaged] [necko-priority-review]

Investigate what other browsers are doing and align to spec.

I see we have https://wpt.fyi/results/fetch/security/embedded-credentials.tentative.sub.html?label=experimental&label=master&aligned&view=subtest that deals with this case.
Chrome appears to block cross origin subresources with credentials. I think we should try to do the same.

Severity: S2 → S3
Whiteboard: [sg:investigate] [necko-triaged] [necko-priority-review] → [sg:investigate] [necko-triaged] [necko-priority-review][necko-next]
Whiteboard: [sg:investigate] [necko-triaged] [necko-priority-review][necko-next] → [sg:investigate] [necko-triaged] [necko-priority-next]
Whiteboard: [sg:investigate] [necko-triaged] [necko-priority-next] → [sg:investigate] [necko-triaged] [necko-priority-queue]
Assignee: nobody → smayya
Attachment #9346122 - Attachment description: WIP: Bug 479038 - disable userinfo and password from url → WIP: Bug 479038 - referenced url containing userinfo or password must not be loaded

The implementation in Chrome is already leading to issues for people, it is one the reasons for me to keep using Firefox. I would suggest not to adopt the Chromium-behaviour.
There are valid use cases for using basic auth in iframes. Instead of blocking it, displaying the prompt may be enough.

I wont be working on this for this month. I will get back to this, once I have some cycles.

Assignee: smayya → nobody
Whiteboard: [sg:investigate] [necko-triaged] [necko-priority-queue] → [sg:investigate] [necko-triaged] [necko-priority-next]
Points: --- → 7
Whiteboard: [sg:investigate] [necko-triaged] [necko-priority-next] → [sg:investigate] [necko-triaged] [necko-priority-next][patch-available]
Duplicate of this bug: 1340200
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: