Open Bug 479038 Opened 13 years ago Updated 4 months ago

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

Categories

(Core :: Networking, defect, P3)

defect

Tracking

()

People

(Reporter: rinsmaster, Unassigned)

References

Details

(Keywords: sec-want, Whiteboard: [sg:investigate][necko-backlog])

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
Duplicate of this bug: 862450
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]
Duplicate of this bug: 1246830
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
Duplicate of this bug: 1519522
QA Whiteboard: qa-not-actionable
You need to log in before you can comment on or make changes to this bug.