Open Bug 1704346 Opened 3 years ago Updated 11 months ago

Block prompt for http auth credentials for subresorces as much as we can

Categories

(Core :: Networking: HTTP, defect, P2)

defect

Tracking

()

People

(Reporter: pm.mahendra1, Unassigned)

References

(Depends on 2 open bugs)

Details

(Keywords: csectype-spoof, sec-want, Whiteboard: [necko-triaged])

Attachments

(1 obsolete file)

+++ This bug was initially created as a clone of Bug #1692268 +++

I can Prompt http authentication while using Style tag

Steps to reproduce the problem:

  1. we need a server with http authentication enabled in it. In my case I am using this https://techyfly.xyz

  2. we need a Style tag with import using this url for example --
    <style> @import 'https://techyfly.xyz' </style>

  3. while using this html Tag, it is prompting http authentication.

POC - http://designs.ndev.xyz/img/crash.html

Http authentication is so dangerous, I already explained in this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1692268 check comment 6 . But I don't know know where they got struck.

I think this show be fix ASAP.

Firefox Version 87.0

User agent - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:87.0) Gecko/20100101 Firefox/87.0

Thanks,
Harshit mahendra

See Also: → 1692268

Yes, we know. You can prompt with any 3rd-party resource type except <IMG> which was singled out in bug 1357835, as noted in bug 1692268 comment 11. You don't need to file a bug for each resource type: bug 647010 covers the general case

Dragana: do we want to dupe this to bug 647010 or bug 1692268? For the <video> case in the latter bug it's pretty easy to decide "it's like and <img>, we don't have to think hard about this". I don't know if we need to do more telemetry or site compat work to different types like <style>. I know a few years back we ran into site breakage because of sites explicitly using XHR() to trigger logins, but maybe all HTML elements can be lumped together.

Johann: have any thoughts or plans here?

Group: core-security → network-core-security
Depends on: 647010
Flags: needinfo?(jhofmann)
Flags: needinfo?(dd.mozilla)
See Also: → 647010

I found out what Chrome is doing (thanks Anne). We should do the same:
https://github.com/whatwg/fetch/pull/465#issuecomment-779643387

This defines behavior with a userinfo in a URI. For URI without a userinfo, I think they block all subresources except XHR. I ask in the issue to confirm Chrome's behavior.

We should match their behavior.

I will leave this bug open and dup the other one.

Flags: needinfo?(dd.mozilla)
Summary: Style tag can prompt for http auth credentials → Block prompt for http auth credentials for subresorces as much as we can
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---

Nihanth, let's track this work in this bug.
Comment 2 links to Chrome's behavior and we should match that.

Flags: needinfo?(jhofmann) → needinfo?(nhnt11)

(In reply to Dragana Damjanovic [:dragana] from comment #2)

I found out what Chrome is doing (thanks Anne). We should do the same:
https://github.com/whatwg/fetch/pull/465#issuecomment-779643387

This defines behavior with a userinfo in a URI. For URI without a userinfo, I think they block all subresources except XHR. I ask in the issue to confirm Chrome's behavior.

We should match their behavior.

I will leave this bug open and dup the other one.

Here is the chromium behaviour That I researched,

It seems chromium only block cross origin images from triggering HTTP auth prompts, but not other subresources, this was added back in https://chromiumcodereview.appspot.com/17738004/diff/18001/content/browser/loader/resource_dispatcher_host_impl.cc, and on the fetch spec, it seems basic auth itself is not considered in it (other than user:pass@ URLs, but that doesn't apply to this case).

I reported the same issue to the chrome and the bug is still open.

Your earliest attention would be appreciated.

Thanks.

Flags: needinfo?(dd.mozilla)

I've started hacking on this with Valentin's help, here's a try push:
https://treeherder.mozilla.org/jobs?repo=try&revision=73b64dac9cdef209a8a4d19f35159dcad09d133c&selectedTaskRun=G-LKJY0cS-yL55ewzysPXA.0

The test failures reveal more things to consider e.g. web sockets, and post messaging from an iframe with a userpass src seems to be expected to work. Also we need to expect successes now where we used to expect failures in /fetch/security/embedded-credentials.tentative.sub.html 😉

Assignee: nobody → nhnt11
Status: REOPENED → ASSIGNED
Flags: needinfo?(nhnt11)
Flags: needinfo?(dd.mozilla)

We should start with writing test and see how Firefox and Chrome differ. This is what we want to test:

  1. User has logged in already to target path before the authed subresource is requested.
  2. User has not logged in already.
  3. Credentials are included in the URL.
  4. Incorrect credentials are included in the URL.
  5. same-origin and cross-site and the influence of partitioning on the latter

We should write WPT.

The next step would be to match Firefox and Chromes behavior.

After these are done we will decide on next steps.

There's one other scenario worth testing as per Mike West's comment on the Fetch PR:

Say you have an authed document and an authed subresource on that document. What happens if the URL to the document and the URL to the subresource both contain username:password? Per his comments it seems that would work in Chrome, even if username:password in a URL might otherwise lead to failure.

I'm thinking we should move the conversation and fix to bug 1340200.
There are already a few WPT out there we can test against, but we definitely need more.

Depends on: 1340200
Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged]
Attachment #9225571 - Attachment description: Bug 1704346 - Block prompt for http auth credentials for subresorces as much as we can. r=#necko! → WIP: Bug 1704346 - Block prompt for http auth credentials for subresorces as much as we can. r=#necko!
Flags: sec-bounty? → sec-bounty-

Not actively working on this.

Assignee: nhnt11 → nobody
Status: ASSIGNED → NEW
Attachment #9225571 - Attachment is obsolete: true
Group: network-core-security
Keywords: sec-lowsec-want
See Also: → 791594
See Also: → 1830519
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: