Noscript is blocking Startpage custom search

[userek]

Since the update to 2.9.5 Noscript is blocking my custom Startpage search as a potential XSS. Console shows the following:

Code: Select all

[NoScript XSS] Sanitized suspicious upload to [https://startpage.com/do/search] from [moz-nullprincipal:{[i]<some number>[/i]}]: transformed into a download-only GET request.

Prior to 2.9.5 everything worked fine.

[userek]

Adding ^https://startpage.com/do/search to XSS whitelist solves the issue, but since there are other search enginges there maybe it's worth considering whether this should be a part of the default whitelist.

[Giorgio Maone]

Where do you initiate the search from?

[dnolan]

Hi Giorgio,

This happens for me as well. I have several "search plugins" which send the search request via POST (many of them bill this practise as a privacy feature: the idea is that when you click away from the results page the destination site does not learn what search terms you used by way of the Referer header).

Using one of these search plugins works fine if I use the search bar. However using the the location bar (do they still call it "awesomebar"?) together with an appropriate search plugin keyword triggers NoScript XSS protection.

For example, using https://searx.laquadrature.net/ with the "q" keyword and entering "q noscript e10s" in the location bar results in the message:

[NoScript XSS] Sanitized suspicious upload to [https://searx.laquadrature.net/] from [moz-nullprincipal:UUID_HERE]: transformed into a download-only GET request.

I observed this with NoScript 2.9.5.1 on Firefox 50.

Cheers!

[Rollo]

I got an XSS warning when doing searches from the context menu on script-disabled pages with duckduckgo html/ssl, others search plugins are working for me.
Maybe related?

My STR:

1)FireFox 45.5 ESR new, clean profile.

2)Install NoScript 2.9.5.1

3)Install duckduckgo html/ssl from
https://addons.mozilla.org/en-US/firefox/addon/duckduckgo-html/
and make it default search engine.

4)Delete "addons.mozilla.org" whitelist entry.
See https://postimg.org/image/6ho3g70k3/

5)In NoScript Options/Advanced/Untrusted select "Block scripting in whitelisted subdocuments of non-whitelisted pages".
See https://postimg.org/image/6sl5bjtqv/

6)Go to
https://addons.mozilla.org/en-US/firefox/addon/noscript/
Select some text and search for it:
See https://postimg.org/image/txtrfl05r/

This will result in an xss warning.
Not happening with NoScript 2.9.0.14

See https://postimg.org/image/jwzrhjmcn/

System: Debian Stable x86_64
Consistently reproducible with firefox 45.5 ESR (both debian version and Mozilla binary tarball) and with
SeaMonkey 2.47 unofficial from Adrian Kalla
https://l10n.mozilla-community.org/~aka ... e-linux64/

Not reproducible with FireFox 50 (Mozilla binary tarball).

I've added this exception
^https://duckduckgo\.com/html/
to the XSS filter and it's working for me.

[Giorgio Maone]

It seems to affect Firefox 50 but not Nightlies (53), because in 53 loads initiated from the navigation bar are reported by Necko as triggered by the [System Principal], rather than the null principal (in 50). The new behavior actually makes more sense to me, anyway I'm trying to find a work-around for stable Firefox.

[dnolan]

Ok this is rather confusing...

I said that searching via the search bar worked fine but the situation is actually more complicated. It seems to depend on what sort of document is loaded in the foreground tab at the time the search is performed.

So far I've seen it work if the current tab is at (call this group A):
- about:home
- about:about
- about:preferences

While NoScript's XSS protection is triggered when the tab is at (call this group X):
- external http(s) documents
- about:blank

This is all while using the search bar. But the behaviour is also more complicated than I anticipated when searching from the location bar. I made the following table to summarise what I found so far:

Full size image: https://s13.postimg.org/gj1ftspbb/xss_bug.jpg

In all cases the request method is POST. Search plugins using GET seem to never trigger the bug.

In case it matters: the only entries in my whitelist are the mandatory ones.

[_xx_]

Just starting getting ABE errors for the same reason I would guess (Necko now reporting origins as moz-nullprincipal as Giorgio noted above). Have had Accepts set up for months for Site LOCAL and just started getting errors after FF50 update this week.

Also only happens (as Giorgio said) when loading from navigation bar. Exact same site works fine when loading from bookmarks library window.

[Tree]

I actually get the same [NoScript XSS] Sanitized suspicious upload to [https://startpage.com/do/search] from [https://startpage.com/do/search?]: transformed into a download-only GET request. error even when just using the direct site, https://startpage.com, upon trying to go to page 2 of results. Just started happening on 2.9.5.1 (Final version, not development)

[Rollo]

2.9.5.2rc1 no XSS warning for me.

Thanks, Giorgio!

[dnolan]

InjectionChecker.js:1122

Code: Select all

  checkPost: function(channel, skip) {
    if (!((channel instanceof Ci.nsIUploadChannel)
          && channel.uploadStream && (channel.uploadStream instanceof Ci.nsISeekableStream)))
      return false;

    var clen = -1;
    try {
      clen = chan.getRequestHeader("Content-length");
    } catch(e) {}
    MaxRunTime.increase(clen < 0 || clen > 300000 ? 60 : Math.ceil(20 * clen / 100000));

    this.log("Extracting post data...");
    return this.checkPostStream(channel.URI.spec, channel.uploadStream, skip);
  },

Isn't "chan" supposed to be "channel"?

RequestWatchdog.js:717

Code: Select all

    let stripPost = trustedTarget && originDomain && !trustedOrigin && ns.filterXPost &&
      ns.getBaseDomain(originDomain) === ns.getBaseDomain(targetDomain);

I'm going on a limb here, but why is it === and not the opposite, that is, strip when the request is cross-origin.

[dnolan]

Another one.

ABE.js:189

Code: Select all

      if (!(browserReq || res.fatal) &&
          this.siteEnabled && channel instanceof Ci.nsIHttpChannel &&
          !ABE.reqData(channel).preflght &&
          req.destinationURI.schemeIs("https") &&
          req.destinationURI.prePath != req.originURI.prePath &&
          !(this.skipBrowserRequests && req.originURI.schemeIs("chrome") && !req.window) // skip preflight for window-less browser requests
      ) {

Looks like "preflght" should be "preflight" (mind the "i").

[dnolan]

What's the matter Giorgio, has the cat got your tongue?

Anyway, I can confirm that release 2.9.5.2 fixes the regressions observed in this post, thanks!

I also see that you fixed the mishaps pointed here. However this one still stands. I don't understand the code well enough to be sure, but it seems that as a result ABE checks will result in extra remote requests, if remote rule sets are enabled.

Cheers.

[_xx_]

I'm still getting the error on 2.9.5.2 when loading from the command bar (vs the booksmarks sidebar).