Noscript blocking Dashlane extension Firefox 50

Ask for help about NoScript, no registration needed to post
Gauner

Noscript blocking Dashlane extension Firefox 50

Post by Gauner » Wed Nov 23, 2016 9:53 am

I've just discovered that the latest Noscript is blocking the Dashlane extension in Firefox 50, causing it to not function at all. If I disable noscript, Dashlane works fine. This just seemed to happen recently, and from my limited investigation appears to be related to ABE blocking local connections. (not super technical :) )

I've tried the latest dev build and it still fails.
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0

im3or
Posts: 4
Joined: Wed Nov 23, 2016 7:14 pm

Re: Noscript blocking Dashlane extension Firefox 50

Post by im3or » Wed Nov 23, 2016 7:25 pm

I have this problem too. I disabled all the extensions in the firefox, finally discovered it is NoScript's fault. Finally, disabled the ABE & my password manager is working fine now.

I am using NoScript 2.5.9.1 with FF 50 32-bit. My password manager is sticky password.

PS: Is ABE essential to NS? Are there any repercussions?
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0

barbaz
Senior Member
Posts: 9269
Joined: Sat Aug 03, 2013 5:45 pm

Re: Noscript blocking Dashlane extension Firefox 50

Post by barbaz » Thu Nov 24, 2016 12:14 am

Do you get any message from ABE in your Browser Console (Ctrl-Shift-J)?

im3or wrote:PS: Is ABE essential to NS? Are there any repercussions?

By default, ABE is set to block CSRF to your local network. It blocks any requests to your local network that didn't originate from there. i.e. it prevents router tampering, websites playing with your local server(s), connections from websites to your computer, etc.

So, if you disable ABE, now any site can access any resource on your local network.

You will also lose NoScript's DNT implementation. If you want DNT, be sure to turn that feature on in your browser if you haven't already.
*Always* check the changelogs BEFORE updating that important software!
-

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Noscript blocking Dashlane extension Firefox 50

Post by Thrawn » Thu Nov 24, 2016 1:19 am

If ABE is blocking something, there should be details in the Browser Console (Ctrl+Shift+J), which we can use to help you craft an appropriate rule to allow Dashlane.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0

Gauner

Re: Noscript blocking Dashlane extension Firefox 50

Post by Gauner » Thu Nov 24, 2016 4:32 am

What I'm seeing in the log is the following over and over.

Code: Select all

Firefox can’t establish a connection to the server at ws://127.0.0.1:15674/.  (unknown)
[ABE] < LOCAL> Deny on {GET http://127.0.0.1:17896/ <<< about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://127.0.0.1:17896/.  (unknown)
[ABE] < LOCAL> Deny on {GET http://127.0.0.1:21953/ <<< about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://127.0.0.1:21953/.  (unknown)
[ABE] < LOCAL> Deny on {GET http://127.0.0.1:32934/ <<< about:blank - 1}


With this showing up from time to time as well:

Code: Select all

dashlane-extension:Error: Couldn't find the worker to receive this message. The script may not be initialized yet, or may already have been unloaded.
Stack trace:
send@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/content/worker.js:82:13
sendOrderToJs@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:245:70
sendOrderToAllFrames@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:249:70
KWTabController.prototype.sendOrderToAllFrames@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:665:62
activateDOMNodeInsertedEvents@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:589:64
@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:454:94
KWTabsController.getCurrentTabController@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:770:66
@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:454:2
notify@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/timers.js:40:9
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Noscript blocking Dashlane extension Firefox 50

Post by Thrawn » Thu Nov 24, 2016 4:37 am

Hmm...it seems to be hitting a few different port numbers. For testing, try putting this rule above the existing rule in the SYSTEM ruleset:

Code: Select all

Site 127.0.0.1
Accept GET
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0

idf
Posts: 16
Joined: Tue Feb 05, 2013 9:48 am

Re: Noscript blocking Dashlane extension Firefox 50

Post by idf » Thu Nov 24, 2016 5:50 am

This was happening before FF 50 for Windows. The problem started, actually - this morning, when I was still on prior version of FF. I've been ignoring the FF notifications to update to FF 40 the last couple of days.

So Dashlane stopped working - and, actually, to try to FIX this, I updated to FF 50, which obviously didn't help.

I think I noticed a recent update to NoScript? Currently I have NoScript 2.9.5.1 installed.

If there was just a change to NoScript in the last day, that may be the problem. An update to NoScript seems to have hit at about the same time as a new version of Firefox.

I am running FF 49.0.1 for Mac - and Dashlane is working on that platform with NoScript 2.9.0.14, not sure why it is so far behind.

It might help diagnose matters if the changelog at noscript.net included date/time and not just version number of updates, and/or if there were a straightforward way to tell when NoScript updates on a computer. Let me know if I am overlooking something.

Hope there is a fix soon.

Thanks.
Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0

idf
Posts: 16
Joined: Tue Feb 05, 2013 9:48 am

Re: Noscript blocking Dashlane extension Firefox 50

Post by idf » Thu Nov 24, 2016 6:03 am

Sorry for the typo. Where I wrote:

I've been ignoring the FF notifications to update to FF 40 the last couple of days.


I meant FF 50.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0

Gauner

Re: Noscript blocking Dashlane extension Firefox 50

Post by Gauner » Thu Nov 24, 2016 9:15 am

Thrawn wrote:Hmm...it seems to be hitting a few different port numbers. For testing, try putting this rule above the existing rule in the SYSTEM ruleset:

Code: Select all

Site 127.0.0.1
Accept GET


this seems to have fixed the issue.

This started recently, so I'm assuming either the latest Noscript or Firefox.
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0

im3or
Posts: 4
Joined: Wed Nov 23, 2016 7:14 pm

Re: Noscript blocking Dashlane extension Firefox 50

Post by im3or » Thu Nov 24, 2016 11:37 am

barbaz wrote:Do you get any message from ABE in your Browser Console (Ctrl-Shift-J)?


I get these:

Code: Select all

[ABE WAN] Detected WAN IP 59.89.130.191
MozSocialAPI injectController: unable to attachToWindow for resource://light_plugin_acf0e80077c511e59ded005056c00008-at-kaspersky-dot-com/data/background/sandbox.html: TypeError: containingBrowser is null  MozSocialAPI.jsm:84


And these over & over again:

Code: Select all

[ABE] < LOCAL> Deny on {GET http://localhost:45872/ <<< http://localhost:45872/, about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://localhost:45872/.  (unknown)
[ABE] < LOCAL> Deny on {GET http://localhost:45872/ <<< about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://localhost:45872/.  (unknown)
[ABE] < LOCAL> Deny on {GET http://localhost:45872/ <<< about:blank - 1}
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0

idf
Posts: 16
Joined: Tue Feb 05, 2013 9:48 am

Re: Noscript blocking Dashlane extension Firefox 50

Post by idf » Thu Nov 24, 2016 12:26 pm

Putting this into ABE options, as suggested, solves it for me too:

Code: Select all

Site 127.0.0.1
Accept GET


The existing rule allows any behavior from local, and denies everything else. This rule apparently allows any GET operation from anywhere to succeed, regardless of source - which seems like it might break a fair amount of ABE protection by allowing some operations to succeed?

Is this a safe thing to allow? What is the nature of typical external attacks on local that ABE is designed to prevent?

Did something change in NoScript, or did something change in a Dashlane update? According to Dashlane changelog, the most recent version of Dashlane for Windows - version 4.6.3 - was released on November 15 - 8 or 9 days before this problem surfaced. My dashlane executables seem to have been updated on or before that date. (The executables are in AppData\Roaming\Dashlane, not in Program Files.)

It's possible that NoScript was changed in advance to try to work around a problem the developers knew was coming in Firefox 50, but FF 50 was released before this problem occurred in NoScript. I was getting notifications to upgrade to FF 50 for a least a day before Dashlane/NoScript broke in FF 49.

I hope that makes sense. Here is a better timeline:

FF 49 - no problem
FF 49 - a day or so ago, I started getting notices to upgrade to FF 50
FF 49 - Dashlane breaks before I upgrade FF. This happened early on 11/23 (Pacific Standard Time)
FF 50 - I upgraded FF to try to fix the problem, but Dashlane is still broken

Then I came here.
Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0

barbaz
Senior Member
Posts: 9269
Joined: Sat Aug 03, 2013 5:45 pm

Re: Noscript blocking Dashlane extension Firefox 50

Post by barbaz » Thu Nov 24, 2016 2:32 pm

This looks like a NoScript bug. Thanks for the report

Better ABE exception, if it works, would be -

Code: Select all

Site 127.0.0.1 localhost
Accept GET from about:blank
*Always* check the changelogs BEFORE updating that important software!
-

idf
Posts: 16
Joined: Tue Feb 05, 2013 9:48 am

Re: Noscript blocking Dashlane extension Firefox 50

Post by idf » Thu Nov 24, 2016 6:03 pm

Your suggestion

Code: Select all

Site 127.0.0.1 localhost
Accept GET from about:blank


Does work, but there is a 10-15 second pause before Dashlane starts working. (It is gray till ready; then it turns green.) The console shows this:

Code: Select all

Could not read chrome manifest 'file:///C:/Program%20Files/Mozilla%20Firefox/chrome.manifest'.
Use of nsIDOMWindowInternal is deprecated. Use nsIDOMWindow instead.  bootstrap.js:43:20
Warning: NetUtil.newChannel(uri) deprecated, please provide argument 'aWhatToLoad'
“nsICookieManager2.add()” is changed. Update your code and pass the correct originAttributes. Read more on MDN: https://developer.mozilla.org/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsICookieManager2  my.js:156:5
[ABE WAN] Detected WAN IP 24.23.190.43
[ABE] < LOCAL> Deny on {GET http://127.0.0.1:11456/ <<< http://127.0.0.1:11456/, about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://127.0.0.1:11456/.  (unknown)
Firefox can’t establish a connection to the server at ws://127.0.0.1:15674/.  (unknown)
Firefox can’t establish a connection to the server at ws://127.0.0.1:17896/.  (unknown)
Firefox can’t establish a connection to the server at ws://127.0.0.1:21953/.  (unknown)
Firefox can’t establish a connection to the server at ws://127.0.0.1:32934/.  (unknown)
Key event not available on some keyboard layouts: key=“c” modifiers=“accel,alt”  browser.xul
Key event not available on some keyboard layouts: key=“r” modifiers=“accel,alt”  browser.xul
Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift”  browser.xul


But it still loads after all that.

By this point I don't know if what I have is correct. This is what I have for the SYSTEM ruleset:

Code: Select all

Site 127.0.0.1 localhost
Accept GET from about:blank
# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny


Is that what you are proposing, or did I mess something up?
Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0

barbaz
Senior Member
Posts: 9269
Joined: Sat Aug 03, 2013 5:45 pm

Re: Noscript blocking Dashlane extension Firefox 50

Post by barbaz » Thu Nov 24, 2016 6:26 pm

Oops, my bad. This should work better -

Code: Select all

Site 127.0.0.1 localhost
Accept GET from about:blank 127.0.0.1 localhost
*Always* check the changelogs BEFORE updating that important software!
-

idf
Posts: 16
Joined: Tue Feb 05, 2013 9:48 am

Re: Noscript blocking Dashlane extension Firefox 50

Post by idf » Thu Nov 24, 2016 8:13 pm

barbaz wrote:Oops, my bad. This should work better -

Code: Select all

Site 127.0.0.1 localhost
Accept GET from about:blank 127.0.0.1 localhost


Yes! Errors gone, and extension initializes quickly.

Will there be a fix to NoScript making this change unnecessary? I'm guessing it would be a fix to how the default system LOCAL rule is currently being interpreted, rendering this extra rule obsolete (but perhaps harmless). I hope the changelog makes some mention of a fix in this area, and if you remember, could you update this thread after the fix, to tell us if we should delete this extra rule?

Thank you very much.
Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0

Post Reply