HTTP Authentication notice missing when request sent via <img src>

NEW
Unassigned

Status

()

Core
Networking: HTTP
P3
normal
9 years ago
3 months ago

People

(Reporter: bsterne, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog])

(Reporter)

Description

9 years ago
MichaƂ Sajdak reported this issue via security@mozilla.org:

When HTTP authentication credentials are sent as part of a URL entered in the location bar such as:
http://foo:bar@example.com/authpage.html

we present the warning:
You are about to log in to the site "example.com" with the username "foo".

However, when the same URL is placed as the src attribute in an image tag, the request is made without presenting the warning and HTTP Auth occurs silently.  This is a bypass of a warning message intended to alert users that they are about to authenticate and could be used as part of a CSRF attack.
Sounds like the right fix is to simply prohibit user:pw in URLs unless they are top-level document requests.  From my chat with some security folks, the top-level user:pw ought to provide auth for any subpage elements anyway.  

IE apparently doesn't allow user:pw in URLs, period.  But we can be nice and allow it for page-level loads, in case anyone out there is using it.  

The alternative fix is to pop up a warning window (ideally only once per page per auth domain), which is a pain to program for a very marginal use case. 

Thoughts?
The point of the message you get when you put a user:pw in the url you put in the url bar was to alert users in situations like:

  http://mybank.com:really-long-string-goes-here@evilsite.com/

See bug 232567 for the history.

The prompt being different on 401/407 response is mostly so we don't lie to the user and say the site doesn't need auth; the fact that canceling it in those cases prevents us sending the username/password is more or less an accident.  Note that we don't even prompt if the username+password is under a certain length (1 char by default but pref-controlled).

If we're changing what the goal is, that's fine.  But if we're trying to prevent CSRF altogether, then I think we should just drop user:pw support period (though I'd be curious to hear what Safari/Chrome/Opera do here).

But I want us to be clear that we _would_ be changing what the goal is.  The primary purpose of this UI is phishing protection.

Comment 3

9 years ago
Hi

I reported the bug, according to some research regarding SOHO class routers.

You can attack such devices by putting a code to a website containing something like:
<img src=defaultuser:defaultpassword@192.168.1.1/...>

And if you are lucky you can own a router only when a victim visits a malicious web site (and the default password is not changed on the router).

Opera doesn't allow such requests (it asks for confirmation).

In IE afair it's optional (off by default but you can reenable the feature).

Purely from security perspective I think it would be OK to ask for every such request. Or just drop user:pw support (with an option to reenable it).

Michal Sajdak
Whiteboard: [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
You need to log in before you can comment on or make changes to this bug.