previous Welcome SmartBlock: Script Surrogates for the masses!
17 02 2022

Contextual Policies & LAN Protection (ABE Quantum) in NoScript 11.3!

Posted by: Giorgio in ABE, WebExtensions, CSRF, XSS, Security, Mozilla, NoScript

ABE Quantum is the combination of Contextual Policies, one of the most requested features in NoScript's history, and LAN protection, an important "Classic" defense lost in the 2017 Quantum migration.

After years of waiting and months of hard work, this good stuff (which I personally missed a lot, too) is finally in the hands of all NoScript 11.3 users*, thanks to the precious support by the NLNet Foundation and the Next Generation Internet programme (more specifically the NGI0 PET fund).

The "ABE Quantum" nickname comes, of course, from the Application Boundary Enforcer module of NoScript Classic, which both Contextual Policies and LAN protection are in a sense a "modernized" descendant of, sacrificing some of the extreme flexibility of the original's firewall-inspired policy definition language in order to provide a simpler, more accessible and more intuitive user experience directly integrated in NoScript's main CUSTOM UI.

ABE Quantum Screenshot

Contextual Policies

Contextual policies let you assign different permissions (or "enable different capabilities", in NoScript's parlance) to a certain site depending on its context, i.e. which is the top level site (the address currently shown in the navigation bar).

For instance, you might want to enable scripts from twitter.com only if you're visiting maone.net - intrigued by Maone's awesome embedded tweet feed ;) - but not elsewhere, because you don't like Twitter to track you everywhere you go:

  1. While on maone.net, open NoScript's popup and select CUSTOM as the policy for twitter.com. You'll see a new drop down box, initially set to ANY SITE.
  2. Remove all the capabilities (e.g. script) you don't want Twitter to use on ANY SITE (notice that when CUSTOM is selected first time, the capabilities from the previously selected preset get copied, so if it was DEFAULT you can probably leave them that way).
  3. Then select ...maone.net from the drop down, and switch script, fetch and frame (the capabilities outlined in red, meaning they're are needed by twitter.com) on.

You're done: scripts from twitter.com are allowed to run only when the main site displayed is maone.net.
You can repeat this on any website (including twitter.com itself) where you want Twitter scripts and subdocuments to work normally.
If you change your mind, you can reset some or all the contextual policies you previously set in the CUSTOM permissions deck, either on from the popup (only for the current context) or from the Options>Per-site permissions panel, where all the context sites you had configured plus the ANY SITE default are listed in the Enable these capabilities when top page matches... dropdown.

LAN Protection

Simply put, the LAN capability lets documents coming from the public Internet (AKA World Area Network / WAN) to link / send requests to hosts inside your Local Area Network (LAN), which is pretty what they can do now, allowing so called cross-zone CSRF/XSS attacks.
By keeping it disabled (the factory setting in the DEFAULT and UNTRUSTED presets), you're replicating this feature from "Classic" NoScript, without the hassle of going through ABE's firewall-like rules when you need to set an exception, which now is just a matter of checking the LAN capability box.

The Contextual Policies & LAN Protection (ABE Quantum) project was funded through the NGI0 PET Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 825310.

* already available in auto-update from AMO, still waiting for review at the Chrome Store while writing this post.

This entry was posted on Thursday, February 17th, 2022 at 1:32 am and is filed under ABE, WebExtensions, CSRF, XSS, Security, Mozilla, NoScript. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

9 Responses to “Contextual Policies & LAN Protection (ABE Quantum) in NoScript 11.3!”

  1. #1 Rispetto_per_Signore_Maone says:
    February 28th, 2022 at 1:17 am

    Ciao Giorgio.
    Is this ABE returning, something to do with why I suddenly get a notification for the first time today - EVER - that NoScript requires NEW PERMISSIONS. https://support.mozilla.org/en-US/kb/permission-request-messages-firefox-extensions?as=u&utm_source=inproduct#w_access-ip-address-and-hostname-information
    Why would I want to give ANY extension permission to bypass NAT and see inside my network thus rendering multiple layers of protection null and void to anything with access to that data? Regardless of whether I trust the author as a good guy or not (which I guess I do).
    This is in Tor Browser 9.5.1 that I had lying around on an old install and was downloading the update for automatically. I never saw this permissions issue before. It smells like a hack, since there's NO OBVIOUS BLOG POST EXPLAINING SUCH A THING. Extension updates are signed, right? Any exploits in this old Tor Browser version that could be leveraged to hijack the extension update process?
    Is this going to be a prerequisite for running NoScript from now on?
    Please update here. I do not check email often due to technical issues.
    Grazie mille e tanti felicitas scusi il mia lingua Italiana no e buono!

  2. #2 Rispetto_per_Signore_Maone says:
    February 28th, 2022 at 1:23 am

    https://hackademix.net/2022/02/17/contextual-policies-lan-protection-abe-quantum-in-noscript-113/#comment-45700

    https://forums.informaction.com/viewtopic.php?f=7&t=26537

    Sorry I am too tired to remember which domain to check for the important info. Although it's not too clear, either, but you did try so please excuse the anti-RTFM behaviour from myself! Plenty of people have FAR poorer documentation, I guess (try using OpenWRT what a clusterfukk).

  3. #3 nojake says:
    March 1st, 2022 at 12:55 pm

    LAN protection brings more security problems than protection

    Currently, LAN protection use the `browser.dns` API to resolve a domain name to IP addresses, this is a very bad idea. Because user may configure the browser to use http proxy which can't prevent those DNS requests that sent by NoScript (This kind of DNS leakings may cost someone's life, it may sounds creazy but it's true). I checked the NoScript codebase, Most of requests will trigger DNS request. The opportunity of using http proxy is much higher than websites make LAN requests which is why i thought LAN protection brings more harm than good.

    The current souce code has already covered local IPs, local domains (`localhost`, `*.local`...). If this is still not enough, let user provide their local domains. So, wo can avoid using DNS API and lots of unnecessary DNS requests.

    ------------------

    I would like to report this to github issue, but the Github rejected me with a not working sign up page.

  4. #4 Giorgio says:
    March 1st, 2022 at 2:37 pm

    @nojake:

    I understand your good intention, but even if you "checked the NoScript codebase" you apparently missed this commit which should settle your issues.

    NoScript does use the browser.dns API, but

    1. It skips DNS resolution completely if the configured proxy performs DNS on its own (e.g if you're using Tor or in your HTTP proxy use case)
    2. Even when DNS resolution is performed, it's done in a stage of the request processing when any veto from content blockers has already happened, and parallel DNS querying is already undergoing or completed by the browser itself, therefore more often than not it just uses cached DNS resolution records without even hitting the net (and only if the browser would do it anyway).
    3. Actual DNS resolution for non-proxied requests is paramount for this protection not being just snake oil: user providing their local domains is useless, since an attacker can easily configure its own public domain names to point to LAN IPs or even dynamically change them from WAN to LAN (DNS rebinding attacks).

    However, if all the above doesn't reassure you yet, just feel free to check back the LAN capability in the relevant presets.

  5. #5 nojake says:
    March 1st, 2022 at 3:49 pm

    @Giorgio

    I found it leaks on version 11.3.2, I did check the code that i extract from browser profile directory, Actually I installed it as temporary add-on and write some log and confirmed it leaked.

    But I didn't check the github project. really sorry for that. I was so astonished that leaking happened.

    I'll test the latest version. Thanks for your quickly reply and sorry for the false alarm.

  6. #6 nojake says:
    March 2nd, 2022 at 9:52 am

    @Giorgio

    I tested the latest NoScript-V11.3.6 on Firefox with HTTP proxy configured. It turns out that DNS requests are still performed by NoScript.

    I found out that the value of `request.proxyInfo.proxyDNS` in file (src/bg/RequestGuard.js line 427) is `false` when using HTTP proxy.

    Then I search MDN for the [doc](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onBeforeSendHeaders), it says:

    > ProxyDNS
    > boolean. True if the proxy will perform domain name resolution based on the hostname supplied, meaning that the client should not do its own DNS lookup.

    But in HTTP proxy case, the DNS requesets are performed by the proxy server. Then why it's value is `false`. I also found [another web page](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/proxy/ProxyInfo) it says:

    > proxyDNS
    > boolean. If true, the proxy server is used to resolve certain DNS queries (only usable with "socks4" and "socks"). Defaults to false.

    I hope this can be helpful.

  7. #7 Giorgio says:
    March 2nd, 2022 at 11:49 am

    @nojajke

    That's very useful indeed (and the proxyDNS API quite misleading, IMHO).

    Please check this commit and version 11.3.7rc1, thanks.

  8. #8 nojake says:
    March 2nd, 2022 at 12:10 pm

    @Giorgio

    I have confirmed that NoScript-11.3.7rc1 don't send DNS requests if http proxy is configured. The commit looks good. Nice job!

  9. #9 MadManMoon says:
    March 30th, 2022 at 2:10 pm

    Hiya, I'm intrigued as to how this DNS stuff affects everything.

    Purely as a note (not as an angry internetter) I don't recall the new permissions being prompted upon any recent NS updates. I update manually, by the way.

Bad Behavior has blocked 868 access attempts in the last 7 days.