Hello Nika, Do(In reply to :Gijs (he/him) from comment #7) > (In reply to Sean Kim from comment #5) > > Actually, Bug 1763671 introduced a pref (`network.http.basic_http_auth.enabled`) to disable basic HTTP auth (and simply show the error page before executing JavaScript). However, we decided to enable it by default because basic http auth can still be a viable option for many users (as you mentioned). I am not entirely certain on the scope of this bug, but I think we can prevent the execution by flipping `network.http.basic_http_auth.enabled` (which is optional). > > > > https://searchfox.org/mozilla-central/rev/548b6981501f59e3c9f2f7851c013e7d53c4e72f/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#644-649 > > As you say it probably is not practical to turn off http auth for everyone in order to fix this bug. > > So my question is about the timing of unload events when http auth happens, and if we can force unloads at the docshell level when we hit an http auth prompt for the next load as discussed in bug 791594 (but not implemented) and, in the case of this particular exploit, unload before/without executing the `window.stop` and whatever other JS, in order to break the attack. Can you help with that? If not, please can you redirect to someone on the docshell / dom navigation side who could? Thank you! > > The fact that XHR events fire while modal dialogs are shown is a very old publicly known bug (bug 360871). Hello Nika, I was wondering if we could force unloads at the docshell level when encountering an http auth prompt during the next load as Gijs mentioned here? I am not very familiar with docshell, it would be great to receive input from someone experienced in DOM navigation. Thanks!
Bug 1944926 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Do(In reply to :Gijs (he/him) from comment #7) > (In reply to Sean Kim from comment #5) > > Actually, Bug 1763671 introduced a pref (`network.http.basic_http_auth.enabled`) to disable basic HTTP auth (and simply show the error page before executing JavaScript). However, we decided to enable it by default because basic http auth can still be a viable option for many users (as you mentioned). I am not entirely certain on the scope of this bug, but I think we can prevent the execution by flipping `network.http.basic_http_auth.enabled` (which is optional). > > > > https://searchfox.org/mozilla-central/rev/548b6981501f59e3c9f2f7851c013e7d53c4e72f/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#644-649 > > As you say it probably is not practical to turn off http auth for everyone in order to fix this bug. > > So my question is about the timing of unload events when http auth happens, and if we can force unloads at the docshell level when we hit an http auth prompt for the next load as discussed in bug 791594 (but not implemented) and, in the case of this particular exploit, unload before/without executing the `window.stop` and whatever other JS, in order to break the attack. Can you help with that? If not, please can you redirect to someone on the docshell / dom navigation side who could? Thank you! > > The fact that XHR events fire while modal dialogs are shown is a very old publicly known bug (bug 360871). Hello Nika, I was wondering if we could force unloads at the docshell level when encountering an http auth prompt during the next load as Gijs mentioned here? I am not very familiar with docshell, it would be great to receive input from someone experienced in DOM navigation. Thanks!
(In reply to :Gijs (he/him) from comment #7) > (In reply to Sean Kim from comment #5) > > Actually, Bug 1763671 introduced a pref (`network.http.basic_http_auth.enabled`) to disable basic HTTP auth (and simply show the error page before executing JavaScript). However, we decided to enable it by default because basic http auth can still be a viable option for many users (as you mentioned). I am not entirely certain on the scope of this bug, but I think we can prevent the execution by flipping `network.http.basic_http_auth.enabled` (which is optional). > > > > https://searchfox.org/mozilla-central/rev/548b6981501f59e3c9f2f7851c013e7d53c4e72f/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#644-649 > > As you say it probably is not practical to turn off http auth for everyone in order to fix this bug. > > So my question is about the timing of unload events when http auth happens, and if we can force unloads at the docshell level when we hit an http auth prompt for the next load as discussed in bug 791594 (but not implemented) and, in the case of this particular exploit, unload before/without executing the `window.stop` and whatever other JS, in order to break the attack. Can you help with that? If not, please can you redirect to someone on the docshell / dom navigation side who could? Thank you! > > The fact that XHR events fire while modal dialogs are shown is a very old publicly known bug (bug 360871). Hello Nika, I was wondering if we could force unloads at the docshell level when encountering an http auth prompt during the next load as Gijs mentioned here? I am not very familiar with docshell, it would be great to receive input from someone experienced in DOM navigation. Thanks!