Re: URL userinfo as a phishing vector

Hi Emma, thanks for your response and the insight.
I would disagree that this threat model is outdated (1905322
<https://bugzilla.mozilla.org/show_bug.cgi?id=1905322#c0>), as we're seeing
this exact trick being used in the wild on a large scale.
Fraudsters are sending these types of links in bulk via SMS and many
victims are falling for it. Happy to provide more evidence of this
privately.
This thread model being available to fraudsters makes it incredibly hard
for companies to detect and take down the sites, as traditional detection
methods don't work.
Is there any chance to reconsider the implementation of warnings?

Best,
Marco

On Wed, Apr 15, 2026 at 3:43 PM Emma Zühlcke <emz@mozilla.com> wrote:

> Hi Marco,
>
> Firefox used to have warning prompts for this scenario, but we decided to
> first disable <https://bugzilla.mozilla.org/show_bug.cgi?id=1905322> and
> finally fully remove
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1905323> them.
>
> Quoting @Daniel Veditz <dveditz@mozilla.com> here
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1571003#c4>
>
> There's also a similar AutomaticAuth prompt. These were implemented in
> 2004 (bug 232567 <https://bugzilla.mozilla.org/show_bug.cgi?id=232567>)
> when many phishing attacks came through text links in mail or chat apps
> (AIM!). Spoofing users via the source link was popular: people looked more
> closely at what they were clicking on than they were likely to double-check
> the URL bar to make sure that's where they ended up. Potential victims knew
> spoofing via HTML was easy -- the link didn't have to look like a URL at
> all -- but tended to trust text more.
>
> This also predated SafeBrowsing phishing protection by 5 years or so.
> Attacks are different now, and we have other defenses.
>
> Pretty sure we can rip these out, but if we want to be more conservative
> we could pref them off and add telemetry to count how many times we see it
> being used in the wild. Between the two prompts there appear to be three
> cases.
>
> SuperfluousAuth is used in two places:
>
>    - the site does not use Auth (always suspicious)
>    - the site uses auth (returns 401/407) but auth fails (might be a
>    legit error, might be a phish trying to avoid the first case)
>
> AutomaticAuth is a warning for the "normal" case of a URL with userinfo.
> Maybe it's legit, or maybe the phisher implemented auth to avoid the
> SuperfluousAuth warning.
>
> We implemented these rather than follow IE's lead and simply reject any
> attempt to load a URL with userinfo. If telemetry shows a low incidence of
> the legit case maybe we can just follow suit at long last. But *this* bug
> should not be about that. Telemetry yes, but otherwise just solve the
> prompt DOS issue. We can revisit bug 479038
> <https://bugzilla.mozilla.org/show_bug.cgi?id=479038> if we want to
> disable these entirely.
>
> On Wed, 15 Apr 2026 at 11:52, Marco Cancellieri <me@marco.sh> wrote:
>
>> Hi all,
>>
>> I wanted to raise an issue that may be worth discussing in this group.
>>
>> The URL syntax allows a userinfo component before the host, separated by
>> `@`. This is a legacy feature that sees little legitimate use in HTTP(S)
>> URLs today, but can be used to construct deceptive URLs such as:
>>
>>   https://paypal.com@evil.com/login
>>
>> Here, the actual destination is evil.com (paypal.com is the username
>> field). Users reading the URL left-to-right are likely to mistake the
>> userinfo for the destination host.
>>
>> Some browsers currently strip the userinfo silently before making the
>> request, but this still results in the user landing on the unintended
>> destination without any indication that the URL was unusual.
>>
>> One possible approach would be to display a warning before navigation
>> when the userinfo portion of an http(s) URL resembles a domain name, for
>> example when it contains a dot and matches a known public suffix. This is
>> already used by browsers for cookie scoping, so the infrastructure exists.
>>
>> I think this is worth defining guidance on, and would welcome discussion.
>>
>> Thank you,
>> Marco
>>
>