Port_Authority icon indicating copy to clipboard operation
Port_Authority copied to clipboard

[BUG] Links to LAN resources from non-LAN pages are treated as portscan attempts

Open mwsundberg opened this issue 9 months ago • 3 comments

Describe the bug We use the originUrl field of the webRequest.onBeforeRequest listener args as the official request source. When a link to a LAN domain in a non-LAN page (example parent page example.com, link destination http://localhost:8080) gets clicked, the web request that loads the new tab has its originUrl value set to example.com, the site which linked to it (MDN cite, it's unfortunately intended behavior). All links to any local, PortAuthority protected domain are interpreted as a port-scan attempt coming from the page with the link in it.

To reproduce

  1. Try clicking this link: http://localhost:8080
  2. If github.com isn't on the allowlist, the request should be blocked and the page will fail to load.
  3. You can force the page to load properly by manually pasting the domain into the URL bar or opening the link in a new tab, focusing the URL bar, and hitting <Enter>, which will treat it as an independent page load separate from the linking page context.

Expected behavior The page loads unimpeded. There might be good reasons to not take this approach everywhere, I'd be curious to hear from someone with more technical know-how or context on why webRequest.onBeforeRequest behaves this way. I suspect historical reasons related to opener behavior, or some web-dev trick that's long fallen out of fashion.

Workaround You can force the page to load properly by manually pasting the domain into the URL bar or opening the link in a new tab, focusing the URL bar, and hitting <Enter>, which will treat it as an independent page load separate from the linking page context.

Additional context Discovered debugging #51, more info/expanded explanation in my comment there. Seems like a nasty but rarely encountered bug, many thanks to @genekellyjr for submitting the issue and crucial details which uncovered it. I'm unsure if it's a long-standing issue or something caused by a recent change. Confirmed to occur on main's HEAD, at tag v2.0.0, and in the AMO release.

mwsundberg avatar Mar 20 '25 08:03 mwsundberg