Block prompt for http auth credentials for subresorces as much as we can
Categories
(Core :: Networking: HTTP, defect, P2)
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:
-
we need a server with http authentication enabled in it. In my case I am using this https://techyfly.xyz
-
we need a Style tag with import using this url for example --
<style> @import 'https://techyfly.xyz' </style> -
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
Comment 1•3 years ago
|
||
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?
Comment 2•3 years ago
|
||
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.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 5•3 years ago
|
||
Nihanth, let's track this work in this bug.
Comment 2 links to Chrome's behavior and we should match that.
Updated•3 years ago
|
Reporter | ||
Comment 6•3 years ago
|
||
(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-779643387This 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.
Comment 7•3 years ago
|
||
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 😉
Comment hidden (obsolete) |
Comment 9•3 years ago
|
||
We should start with writing test and see how Firefox and Chrome differ. This is what we want to test:
- User has logged in already to target path before the authed subresource is requested.
- User has not logged in already.
- Credentials are included in the URL.
- Incorrect credentials are included in the URL.
- 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.
Comment 10•3 years ago
|
||
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.
Updated•3 years ago
|
Comment 12•3 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 13•2 years ago
|
||
Not actively working on this.
Updated•2 years ago
|
Updated•1 year ago
|
Description
•