Bad interaction between Clipperz and NoScript

[hansfn]

Hi!

This topic has as far as I know already been raised by the Clipperz developers, but I would like some public feedback/explanation.

Clipperz, a free and anonymous online password manager, has a nice feature called "Direct login". This means that you can just click a link (in your password database) and Clipperz will log you in - quite obvious I guess. This plays very well with NoScript, but now Clipperz is working on a new version which uses a different implementation of the direct logins. Basically a new window is opened and the address bar filled with the HTML source for the login form encoded - "data:text/html;charset=utf-8;base64 ...". This is blocked by NoScript with a warning in the consol:

[NoScript XSS] Rengjorde en mistenkelig opplasting til [http://forum.pivotx.net/ucp.php?mode=login] fra [moz-nullprincipal:{189449de-a084-426a-bb38-ed1ca9624d9f}]: omgjort til en kun-nedlasting GET forespørsel.

I'm sorry it's in Norwegian, but I guess the message is quite clear: The upload/submit was cleaned and turned into a GET request, because it came from moz-nullprincipal.

Why can't I white-list moz-nullprincipal? What are the security issues that I don't see? (I must admit that I don't really know what moz-nullprincipal is, but I guess it's something local.) Any feedback would be appreciated? Either how Clipperz could avoid this problem or how NoScript could be changed/configured to work. I'm not prepare to drop any of these applications ...

[GµårÐïåñ]

[NoScript XSS] Rengjorde en mistenkelig opplasting til [http://forum.pivotx.net/ucp.php?mode=login] fra [moz-nullprincipal:{189449de-a084-426a-bb38-ed1ca9624d9f}]: omgjort til en kun-nedlasting GET forespørsel.

Translation: [NoScript XSS] Cleaning a suspicious upload to [http://forum.pivotx.net/ucp.php?mode=login] from [moz-nullprincipal:{189449de-a084-426a-bb38-ed1ca9624d9f}]: converted to an only-download GET request.

But as you said, it was quite clear and it seems to be a chrome behavior, so it should be fine if chrome is allowed, no? Giorgio, isn't this a variant of the DOMParser() issue? It came up in this bug https://bugzilla.mozilla.org/show_bug.cgi?id=416534 but should have been resolved. Anyway, this is all I can think of and remember off the top of my head, maybe Giorgio can elaborate.

[Giorgio Maone]

Basically a new window is opened and the address bar filled with the HTML source for the login form encoded - "data:text/html;charset=utf-8;base64 ...". This is blocked by NoScript with a warning in the consol:

[NoScript XSS] Rengjorde en mistenkelig opplasting til [http://forum.pivotx.net/ucp.php?mode=login] fra [moz-nullprincipal:{189449de-a084-426a-bb38-ed1ca9624d9f}]: omgjort til en kun-nedlasting GET forespørsel.

Any malicious web site could do the same (opening a new window with the data: URL and submit a XSS payload), therefore NoScript is right in blocking the request. "moz-nullprincipal" is not a local thing, is just an auto-generated fake origin which Gecko uses when the "real" origin can't be guessed, marking the content as unsafe (origin unknown).
I've already been contacted by the Clipperz developers and explained them how to perform the submit safely, but they apparently need to work around some different issues before changing the submission in a NoScript-compatible way.

[hansfn]

Thx a lot for the fast reply. I'll wait for the Clipperz developers then.

A general question: You wrote that

Any malicious web site could do the same (opening a new window with the data: URL and submit a XSS payload), therefore NoScript is right in blocking the request.

That makes 100% sense to me, but couldn't NoScript block the actual opening of a new window with a data URL for all untrusted sites (instead of blocking the XSS payload)? I do understand that this is not what NoScript was invented to do, but I'm just curious.

PS! I do understand if you don't have time to explain

[Tom T.]

...Clipperz, a free and anonymous online password manager...

I know you didn't ask, but I wouldn't trust *any* remote source to store my passwords for me. I don't know who their employees are, how they're screened, how secure the database is... Coincidentally, yesterday I received a notice from my credit card company that one of their merchants had a database breach, possibly compromising thousands or millions of credit card numbers, and so as a precaution, they rightly sent me a new card. That' the second time in about a year or so. It isn't the credit card issuer; it's the merchants who store your account info. It seems very difficult to get people to secure databases properly. Food for thought.

FWIW, my *personal* solution is Password Safe, a free, open-source password manager designed by world-famous cryptographer Bruce Schneier. I know of Schneier's reputation and standing in the cryptographic community, and I trust him. Plus, the program and all of the data are stored on my local machine, with the password database securely encrypted with Schneier's TwoFish algorithm. Portable, fits on a Flash drive, can be used as a guest on someone's else computer without leaving any Registry traces behind, etc. Forensic analysis of your HDD would show only a blob. A rubber-hose cryptanalysis would be much more feasible.

Of course, this is my personal opinion only, shared in the hope that it might be of some value, but neither NoScript, this site, nor its developer/admin are endorsing the product, nor can they or I give any warranties or accept any liability for its use. Investigate thoroughly before deciding, and use at your own risk.

[therube]

("yesterday I received a notice from my credit card company that one of their merchants had a database breach". Ditto. Capital One in my case.)

[Tom T.]

("yesterday I received a notice from my credit card company that one of their merchants had a database breach". Ditto. Capital One in my case.)

Ditto ditto in mine. Musta' been huge. And they *never* tell you which merchant, by agreement with the merchants. Otherwise, they're afraid that the merchants won't report it, out of fear of being embarrassed at their Swiss-cheese db security. Which they should be. Otherwise, no incentive to fix it. Like reporting a vuln privately -- you give the vendor two or three weeks to fix it, and if not, you go public. *Then* maybe they'd pay a few bucks for a decent, professional security team instead of Joe the Database Plumber. (hehehehe)

[hansfn]

Thx for your concern Tom T., but you clearly haven't read closely about Clipperz. (I know very well who Bruce Schneier is - I follow his and several other security researchers blogs.)

Anyway, to get back on topic, I have gotten some feedback from the Clipperz developers and they say that they can't load the data URL in a NoScript safe way (as suggested to them by Giorgio) because

doing so we will trigger a Firefox bug that will not display the feedback in the loading page.

Argh.

[GµårÐïåñ]

You can always setup an exception for them to get them to work but I am personally not buying their explanation.

[gcsolaroli]

Hello everybody,

I would like to provide some feedback to this nice discussion about Clipperz.

The problem we are facing with Firefox is this:
- http://forums.mozillazine.org/viewtopic ... &sk=t&sd=a

As you may notice, I have personally reported it more than two years ago. Since then, nothing had happened. I have to admit that the problem is triggered in a very odd situation, but this is what we have to deal with for implementing our Direct Logins.

The only way we have found to work around the above issue is using a data: URL; it basically works, but unfortunately it also triggers NoScript.

Until the Firefox problem is fixed (or we can find a different workaround) we have only two options: keeping the old implementation (with no feedback for the user) or leaving the new one (that triggers NoScript).
At the moment we are opting to leave the new one that provides some feedback also to Firefox users.

Let me be clear: NoScript behaviour is completely legitimate, and their reasons to block the script are absolutely valid.

We would be very pleased if they could add an exception to their code to allow Clipperz performing these "bad" actions, but we can also easily understand why the would not do so.

Hope this make Clipperz current standing in this problem a little more clear.

Giulio Cesare Solaroli
Clipperz CTO

[Tom T.]

...The problem we are facing with Firefox is this:
- http://forums.mozillazine.org/viewtopic ... &sk=t&sd=a

As you may notice, I have personally reported it more than two years ago. Since then, nothing had happened. I have to admit that the problem is triggered in a very odd situation, but this is what we have to deal with for implementing our Direct Logins.

The only way we have found to work around the above issue is using a data: URL; it basically works, but unfortunately it also triggers NoScript.

Until the Firefox problem is fixed (or we can find a different workaround) we have only two options: keeping the old implementation (with no feedback for the user) or leaving the new one (that triggers NoScript).
At the moment we are opting to leave the new one that provides some feedback also to Firefox users.

Let me be clear: NoScript behaviour is completely legitimate, and their reasons to block the script are absolutely valid.

We would be very pleased if they could add an exception to their code to allow Clipperz performing these "bad" actions, but we can also easily understand why the would not do so.

Hope this make Clipperz current standing in this problem a little more clear.

Giulio Cesare Solaroli
Clipperz CTO

Signore Solaroli,

Thank you for your time to come here and explain your company's policy and actions.
Wouldn't it be better to write your code in a manner that conforms to the browser, and to the admittedly legitimate actions of NoScript for your program's "bad" actions, rather than ask Firefox and NoScript to make exceptions for your particular case?

Also, imagine if every company that had its own novel implementation asked Firefox and NoScript to make such exceptions. This is an impossible burden.

Clearly, your company is endowed with talented programmers. Surely, you can write your program in such a fashion as to conform to the browser, and not to trigger alarms in NoScript?

Thank you again for your time and consideration.

-- Tom T.
NoScript Forum

[gcsolaroli]

Hello Tom,

Surely, you can write your program in such a fashion as to conform to the browser, and not to trigger alarms in NoScript?

We have tried to find such a solution, but we couldn't. As I have tried to say, we are not doing anything that does not "conform to the browser", but we are actually hitting a "blind spot" of the Firefox implementation the is not behaving as expected. But being a "blind spot", no one is interested in fixing it.

As we don't aspect this situation to change soon, we have tried ways to work around it.

When we realized that the alternative implementation was triggering NoScript, I have personally contacted NoScript developers that have kindly explained me why that was happening. As NoScript triggering was not the result of a side effect, but an explicit behavior needed to avoid some bad scripts, it was immediately clear that "fixing" that side of the problem would have not be possible.

Also, imagine if every company that had its own novel implementation asked Firefox and NoScript to make such exceptions. This is an impossible burden.

I have reported the problem to Firefox because that is a BUG (confirmed by the long thread with one of the developers), and not because we were looking for exceptions.
I have contacted NoScript developers to understand why we were triggering it and asked if they have a configurable option to set exceptions to the rules (kind of white list).

Sorry, but this doesn't really seems to me like asking everybody for special exceptions just to please our need.

Other than that, we have found only two ways to implement that given feature; each feature as some pros and some cons, so all we can do is pick one and live with its cons.

We are sorry for current NoScript users that will not be able to fully leverage our service, but we consider this the best tradeoff we can have right now.

Regards,

Giulio Cesare

[Tom T.]

Hello Giulio,

Thank you for your further clarifications. I'm not connected with Firefox development or support, but I'm sorry that there is a blind spot that they will not fix.

I am vaguely aware that there are other single sign-on services or online account-manager services. I know nothing of them, as I don't use them. (I use a local-machine-based tool for this purpose.) Perhaps you might research these other services, and see if you can find out whether they implemented their plans in some way that might be adapted to your model? This is a courtesy suggestion only, as I know nothing of these products.

Good luck to you, Sir.

Regards,

Tom T.

[therube]

I have reported the problem to Firefox because that is a BUG (confirmed by the long thread with one of the developers)

Just to be clear, you have filed an actual bug report at Bugzilla@Mozilla?

[gcsolaroli]

Just to be clear, you have filed an actual bug report at Bugzilla@Mozilla?

I must confess that I don't remember exactly, but I don't think I have created an entry into Bugzilla; what I do remember is that following the suggestion of one of the developers to open a thread into the bug forum (http://forums.mozillazine.org/viewtopic.php?p=2837424).

But as I did not get any reply I have give up (that was more that two years ago).

The issue I had (and I still would have), is how to properly create a bug report for this condition.
I know this is not exactly a topic very relevant for this forum, but if anyone here has some experience/understanding on how to report Firefox bugs and is willing to help, I would really appreciate.

The problem is obviously not how to create the Bugzilla entry, but how to formulate it, how to "classify" it in order for the right people to see it, etc ...

Any suggestions?