InformAction Forums

I've narrowed down an issue that is directly caused by NS regarding the Citibank online website.

Same problem occurs in both of these cases:
1) Pale Moon 26.1.1 (current build) using NS 2.9.0.9
2) Firefox 42.0.1 using NS 2.9.0.10
3) There are no problems with any browsers that do not use NS
4) This problem does not occur if I have NS totally disabled in either PM or FF (that have this problem).

I'm not blocking anything in NS for the website (if I allow Scripts Globally I get the same result), again the only thing that solves the problem is if the NS extension is totally disabled.

Problems:
1) Logging in the website hangs the system (browser not responding) for 30-90 seconds.
2) Then navigating the website more hangs and I get the following irrelevant prompt each time I try to do anything on the website:

3) The only resolution is to totally disable NS.

If I do nothing the website will eventually logout as expected and I will once again get the same prompt you see above no matter what tab I'm on and I'll find that the website will be logged out with the following message: "We're very sorry we're having technical issues. Please try again. We apologize for any inconvenience and appreciate your patience. [Citi002]". Of course this is simply another navigation of the website triggered by the website itself because of a login time-out process built into the website which is to be expected due to the problem that NS is causing somehow.

Thanks for any help.

sigh..... this again: viewtopic.php?p=78963#p78963

What solved my issue as described above was the following for each browser designated below:

Firefox: I actually added the exact URL's that were having problems to the Anti-XSS exception list for the specific URL's causing issues, specifically "^https://online.citi.com/US/JPS/portal/Index.do" and "^https://steps.citi.com". Since there are no wild cards involved (I found wildcards in this case failed to work anyway) there is virtually zero risk involved since the XSS exceptions are exclusive to only those specific pages.

Pale Moon: For this browser I only needed the first XSS exception "^https://online.citi.com/US/JPS/portal/Index.do" and didn't need the second one. And of course Pale Moon already has an XSS Filter built into the browser so I'm doubly protected in the case of Pale Moon anyway. (and as mentioned above the absence of wildcards makes the XSS exception only applicable to this specific page)

I found my solution shortly after I initially posted my topic but the topic was promptly locked at the time so I didn't bother to get back until now. I've decided to go ahead and post my resolution in the event it might be of help to anyone else especially since I've noticed another user has been recently experiencing problems with Citibank that is attributable to NoScript.

Those XSS exceptions are allowing ANY site to XSS your banks!!!!!! That is *not* safe, expecially since the bank sites using this system might be actually vulnerable to XSS!

If you are going to use XSS exceptions then the only safe(ish) way to do so is create a new profile which is used ONLY for the bank site, then install NoScript & make XSS exception for the *origin* of request (match "@" + the URL - see the sticky for more info).

Thanks barbaz for the reply. I have to say, based on what your saying NoScript is about the most counter-intuitive process I can thing of.

This is the way I see it from an intuitive (logical) concep.

1) ^https://roll\.bankofamerica\.com/.*

The above example (which I've used for BofA and posted a discussion on this in the past here on this forum or at least another bank based on this same principle) as I understood it would impart an "XSS exception" for any website that matches up to the wildcard and thereafter anything that a website would have in their URL after the wildcard. That is what makes intuitive sense. So what other websites would match that URL pattern? None as I see it other than BofA.

That said, back when I did this I was told presumably on this forum that I needed to add an ABE entry for this bank and was instructed to do the following in that regard:
Site .roll.bankofamerica.com
Accept from .bankofamerica.com
Deny

So I did this presuming what I've been told is what I needed to do and based on the instructions give me that this is what would be safe as well.

Also referring what I've made BOLD and since BOLD does not differentiate enough I'm referring to where the "1)" above (using RED colored fond would be helpful but doing this will NOT get past the asinine SPAM protection on this site which if it doesn't the user doesn't just get a warning and the post remains to be edited but the entire post is removed which is doubly ridiculous on it's face (but I better stop there to avoid the SPAM monster raising it ugly head on this board). So getting back to the red err I mean BOLD post, I have no idea why "\" had to be used instead of the standard "/" but so be it I tried both in reference to the following explanation.

Now getting back to this current problem, if I recall regarding Citibank I was unable to get the website to work at all with any wildcards so what DID work is entering the entire URL for the page that was causing the issue. Which was ^https://online.citi.com/US/JPS/portal/Index.do" for Pale Moon and as I said before the other URL as well was needed for Firefox (back then I used FF, until I found the far far better PM browser).

Now let me ask you a question.

Common sense tells me that the XSS is bypassed for all website URL's that will specifically match this "^https://online.citi.com/US/JPS/portal/Index.do". Am I right?

So what other URL will match this other than Citibank?

And one last point, I'm not going to bother changing Profiles back and forth just to use a Bank and have NoScript work properly. For one thing I really NEVER use Firefox anyway and ONLY use Pale Moon exclusively (Firefox only used for comparison testing occasionally like in this case). And as I previously posted Pale Moon has it's own built in XSS Filter code so in my mind if NoScript isn't able to do the job in a practical manner so be it, Pale Moon is also protecting me in regards to XSS vulnerabilities ANYWAY. AM I WRONG HERE? (better leave off the red font to avoid SPAM detection on this odd forum. I'll be surprised if the post works frankly at this point with bold/underline).

It worked (font color is the SPAM problem obviously after taking ½ to find out).

So in conclusion, the way I see it since I'm using Pale Moon, I am protected by Pale Moon in regards to XSS protection for this Citibank site and for the Merrill Edge website in regards to processing trades only (and the only site that has an XSS protection issue with Pale Moon's XXS protection function) I'm protected by NoScript for this Merrill Edge website regardless. So if one XSS has a problem the other XSS will do the job whether it be NoScript of Pale Moon. Which I have to say with all the issues regarding this protection level it's good I am using both Pale Moon and NoScript which both work seamlessly together by the way. All of which I intended to post prior to you lock on this topic.

Thanks for all your help.

MAN O MAN, THANK GOODNESS FOR Form History Control, as I posted the insane SPAM filter kicked in so I started trying to post in steps until I found that it all came down to ONE entry regarding font color causing the problem.

I DON'T KNOW HOW YOU GUYS PUT UP WITH THIS CRAZY SPAM PROTECTION ON THIS FORUM. I have a suggestion, how about they just disable the "Font color" button in this forum since using this will apparently not get past the weird SPAM protection on this board.

lakrsrool wrote:That said, back when I did this I was told presumably on this forum that I needed to add an ABE entry for this bank and was instructed to do the following in that regard:
Site .roll.bankofamerica.com
Accept from .bankofamerica.com
Deny

So I did this presuming what I've been told is what I needed to do and based on the instructions give me that this is what would be safe as well.

An ABE rule for Citibank would certainly mitigate the risk significantly.

lakrsrool wrote: I have no idea why "\" had to be used instead of the standard "/" but so be it I tried both in reference to the following explanation.

"\" is the escape character for regexp. See this tutorial for more info about regexp.

lakrsrool wrote:Common sense tells me that the XSS is bypassed for all website URL's that will specifically match this "^https://online.citi.com/US/JPS/portal/Index.do". Am I right?

Yes, XSS is bypassed for all requests to URLs matching that pattern. But, it matches *any* source - meaning any site could try to XSS that URL and would bypass the XSS filter. That's why in these situations adding XSS exception for origin of request is safer (allowing citibank to XSS any site).

lakrsrool wrote:And one last point, I'm not going to bother changing Profiles back and forth just to use a Bank and have NoScript work properly. For one thing I really NEVER use Firefox anyway and ONLY use Pale Moon exclusively (Firefox only used for comparison testing occasionally like in this case). And as I previously posted Pale Moon has it's own built in XSS Filter code so in my mind if NoScript isn't able to do the job in a practical manner so be it, Pale Moon is also protecting me in regards to XSS vulnerabilities ANYWAY. AM I WRONG HERE?

Keep in mind that not only Pale Moon's XSS filter is newer than NoScript's (so less "live testing"), but due to its target audience it also has to be generally more permissive than NoScript. I personally wouldn't trust it to be comprehensive, but that's just my opinion.
There is thread here about it: viewtopic.php?f=19&t=21463

lakrsrool wrote:MAN O MAN, THANK GOODNESS FOR Form History Control, as I posted the insane SPAM filter kicked in so I started trying to post in steps until I found that it all came down to ONE entry regarding font color causing the problem.

I DON'T KNOW HOW YOU GUYS PUT UP WITH THIS CRAZY SPAM PROTECTION ON THIS FORUM.

Personally I use Form History Control which you recommended some time back.

barbaz wrote:

lakrsrool wrote:Common sense tells me that the XSS is bypassed for all website URL's that will specifically match this "^https://online.citi.com/US/JPS/portal/Index.do". Am I right?

Yes, XSS is bypassed for all requests to URLs matching that pattern. But, it matches *any* source - meaning any site could try to XSS that URL and would bypass the XSS filter. That's why in these situations adding XSS exception for origin of request is safer (allowing citibank to XSS any site).

Thanks so much for all this detailed and very helpful information (I'll certainly take a look at this when I have more time, got to get to some errands today).

OK,I'm not at all sure if we are in agreement with the concept that the more wildcards used will by definition increase the generalization of the target as opposed to less or not using wildcards at all which results in increasingly less generalization thus a far greater restriction is imposed as a result of increasingly using the latter.

I would have highlighted in red a part of your former post because bold is not distinct enough I'll instead of using red font have to re-post:

barbaz wrote:But, it matches *any* source - meaning any site could try to XSS that URL and would bypass the XSS filter. That's why in these situations adding XSS exception for origin of request is safer (allowing citibank to XSS any site).

Could you please clarify in a more distinctive way the following:

What is meant my ".. *any* source"? meaning any domain?
As to in so many words "any site could.... bypass the XSS filter"... regarding "that URL" (paraphrase). Am I wrong to say that any site would only be able to bypass the XSS protection that is using this specific distinct URL? And if that's correct then what are the odds that a specific URL i.e. "https://online.citi.com/US/JPS/portal/Index.do" would be targeted and by the way how difficult if not impossible would that be considering we are discussing a "secure" site in the first place (that is "https", I'd highlight the "S" in red if I could on this SPAM paranoid board but I presumably can't ).

And beyond that I'm also including the ABE setting as mentioned:
Site .online.citi.com
Accept from .citi.com
Deny

.... which you've said "mitigates significantly" the risk and beyond that as "new" or "less tested" or "forgiving" as the XSS Filter might be in PM it's there and would presumably be to whatever limitation exists certainly a deterrent in regards to XSS vulnerabilities such as they are.

As I see it, I'm most likely far safer than the literally hundreds of millions of users worldwide who do not even use either/or NoScript or Pale Moon first of all, and second of all I'm doing what I can to be practical as far as user convenience (that is not needing to switch profiles or use other browsers or whatever) with what I've done so far to to protect from XSS vulnerabilities.

That all said, I'm always grateful for any additional advise as to how I should configure the XSS Exception for this Citibank website in the XXS exception entry as opposed to what I currently have, that being as you know "^https://online.citi.com/US/JPS/portal/Index.do".

lakrsrool wrote:Could you please clarify in a more distinctive way the following:

What is meant my ".. *any* source"? meaning any domain?
As to in so many words "any site could.... bypass the XSS filter"... regarding "that URL" (paraphrase). Am I wrong to say that any site would only be able to bypass the XSS protection that is using this specific distinct URL? And if that's correct then what are the odds that a specific URL i.e. "https://online.citi.com/US/JPS/portal/Index.do" would be targeted and by the way how difficult if not impossible would that be considering we are discussing a "secure" site in the first place

What I mean is with your XSS exception as you have it, for example some page on evil.net access "https://online.citi.com/US/JPS/portal/Index.do" would bypasses the XSS filter. https is irrelevant when XSS is at hand because A) the scripts run in the context of the target site, B) it's the user's browser being used as part of the delivery vector.

lakrsrool wrote:And beyond that I'm also including the ABE setting as mentioned:
Site .online.citi.com
Accept from .citi.com
Deny

.... which you've said "mitigates significantly" the risk and beyond that as "new" or "less tested" or "forgiving" as the XSS Filter might be in PM it's there and would presumably be to whatever limitation exists certainly a deterrent in regards to XSS vulnerabilities such as they are.

As I see it, I'm most likely far safer than the millions of users who do not even use either/or NoScript or Pale Moon first of all, and second of all I'm doing what I can to be practical as far as user convenience (that is not needing to switch profiles or use other browsers or whatever) with what I've done so far to to protect from XSS vulnerabilities.

Well, new or not, Pale Moon's XSS filter is going to be MUCH better than having no XSS filter at all. It's not like a group of people who design a nice browser are suddenly going to mirror Microsoft from 7 years ago, right?

lakrsrool wrote:That all said, I'm always grateful for any additional advise as to how I should configure the XSS Exception for this Citibank website in the XXS exception entry as opposed to what I currently have, that being as you know "^https://online.citi.com/US/JPS/portal/Index.do".

If multiple profiles is off the table, about the only other thing to do is switch the XSS exception to match origin of request. The console message should give both the origin and destination URLs.
Also replace all . with \. to match literally a . and not *any* character at those positions.

the only other thing to do is switch the XSS exception to match origin of request.

I too have been having the Citibank (online.citi.com) whiteout scripting freezes and have taken to making payments *gasp* by phone! I KNOW! So having read through this entire page and other threads, allow me to say, barbaz, I will give you my firstborn male child if you can provide the exact / correct XSS exception syntax / text for me to stick where it belongs, because... scary. It's a good deal.

JLJ, in case you didn't notice, lakrsrool was not using Firefox. lakrsrool was using Pale Moon 26, which had its own built-in XSS filter. That made it relatively safe for lakrsrool to deal with their problem in a NoScript XSS exception.

You are using Firefox 51, which does not have a built-in XSS filter. Thus, this thread irrelevant to your problem.

You're looking for this thread - viewtopic.php?f=7&t=22574

barbaz wrote:You are using Firefox 51, which does not have a built-in XSS filter. Thus, this thread irrelevant to your problem. You're looking for this thread - viewtopic.php?f=7&t=22574

Yeah thanks I read that page, but I didn't see anything solution-wise. It may well be in plain sight, but I missed it, maybe proudly. To date the only way into Citibank here under Firefox 51.0.1 x 64 w/ NoScript 2.9.5.3 remains to fully disable NS and restart FF. It wasn't this way as of 2-3 months ago, when the page(s) would eventually load functionally after 1-2 minutes; now they never do and the whole browser freezes fatally. Any ideas on a fix that even the likes of me can comprehend gratefully appreciated as always, and the firstborn child thing still holds, if you're interested

No need to sound quite so smug about it, skim reading isn't a virtue.

barbaz wrote:this thread irrelevant to your problem.

You're looking for this thread - viewtopic.php?f=7&t=22574

So how about asking for clarification in the other thread, where your problem has some relevance.

Since current versions of Pale Moon don't have a built-in XSS filter anymore, let's lock this thread. lakrsrool, if you'd like it to be unlocked again, please PM me.