HTTP Basic Authentication with credentials in URL fails

[basicmaster]

Describe the issue

Webpages that use HTTP Basic Authentication may be called with credentials embedded into the URL itself (I use this for a password-protected status page that is always open in a tab, across browser sessions).

When I retrieve a page with such an URL in Firefox, Firefox asks for confirmation if I really want to login as user "user" to the page. After confirmation, the page is loaded - but with the current uBlock Origin release, the page is not loaded after that confirmation (sniffing with Wireshark also shows that the page has not been requested again). Only when I again request the page, it is then loaded (of course without the conformation dialog once again, as Firefox caches the authentication information).

I also disabled all other add-ons, which did not fix the issue. Disabling uBlock Origin and leaving all other add-ons enabled fixed it.

One or more specific URLs where the issue occurs

The following test site uses HTTP Basic Authentication (user/pass: test):
http://browserspy.dk/password-ok.php

Steps for anyone to reproduce the issue

• open Firefox and a new tab
• paste the URL http://test:test@browserspy.dk/password-ok.php and press Enter
• Firefox asks "You are going to log in at 'browserspy.dk' as user 'test'." (I don't know the exact wording of this dialog in English)
• confirm that question with "OK"
• you will see a blank page - instead of the actual content
  [
• paste the mentioned URL again and press Enter
• you see the actual content
  ]

Note: As Firefox caches the authentication information for the current session, this will work only once per session.

Your settings

• OS/version: Ubuntu MATE 16.04 LTS AMD64
• Browser/version: Firefox 56.0
• uBlock Origin version: 1.14.10

Your filter lists

Default filter lists + Fanboys Annoyance/Anti-Third party social + DEU

[gwarser]

https://github.com/gorhill/uBlock/wiki/Firefox-WebExtensions#read-carefully-if-using-ubowebext

Probably https://bugzilla.mozilla.org/show_bug.cgi?id=1379148 , I see document.write in source, and is working fine in Nightly.

[gorhill]

I can reproduce with FF 55:

• uBlock Origin 1.14.11rc? (nothing was blocked by uBO as per logger)
• Privacy Badger 2017.9.12.1
• Adguard AdBlocker 2.7.2

I could not reproduce with FF 55:

• Adblock Plus 2.99.0.1867beta
• AdBlock 3.5.1

I can't reproduce with uBO and FF 58.

So as @gwarser said, quite probably related to https://bugzilla.mozilla.org/show_bug.cgi?id=1379148. Given that clicking "Cancel" or closing the prompt causes a crash, you might want to report this to Firefox devs: https://bugzilla.mozilla.org/.

[gorhill]

Not sure it's related to https://bugzilla.mozilla.org/show_bug.cgi?id=1379148, or else this raises teh question why it happens with some blockers, but not similar others.

I am sure however that this needs to be reported to Firefox devs.

[gorhill]

Here is a minimalist extension with which the issue can be reproduced:

manifest.json:

{
    "name": "uBO-issue-3087",
    "version": "1",
    "manifest_version": 2,
    "background": {
        "scripts": ["background.js"]
    },
    "permissions": [
        "webRequest",
        "webRequestBlocking",
        "<all_urls>"
    ]
}

background.js:

browser.webRequest.onHeadersReceived.addListener(
    function(details) {
        ;
    },
    {
        urls: ['<all_urls>'],
        types: ['main_frame'],
    },
    ['blocking']
);

With no other extension enabled:

• Launch Firefox.
• Load the above minimalist extension using "Load Temporary Add-on".
• Try to load http://test:test@browserspy.dk/password-ok.php in a new tab.

Result, failure to load the page if clicking "Ok", whole browser crash if clicking "Cancel".

When merely removing the , ['blocking'] argument in the call to browser.webRequest.onHeadersReceived.addListener, the issue disappears. This explains why the issue exists with some blockers but not others. uBO must use the ['blocking'] argument because this is how inline scripts and inline fonts are properly blocked, and also at the point where the csp= filter is enforced.

[gorhill]

@Rob--W Is this a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1401516? Minimal repro steps are in the comment immediately above. A blocking webRequest.onHeadersReceived listener is key to reproduce the issue.

[Rob--W]

@gorhil When I run #3087 (comment) in Firefox 58.0a1 (build ID 20171003220138 as seen at about:support), the test case completes successfully. So this is indeed a duplicate of https://bugzil.la/1401516 (which itself has been marked as a duplicate of https://bugzil.la/1396395 because that bug has the patch for the issue).

[basicmaster]

Thank you for the investigations!

[gorhill]

https://bugzilla.mozilla.org/show_bug.cgi?id=1396395

The issue is marked as wontfix for Firefox 57. Not good.