Online Banking and Allow Scripts Globally

[Tom T.]

I wonder what particular element of NoScripts that remains active when "Allow Scripts Globally" is selected that prevents the successful login...

XSS protection, as you cited below, is indeed one element of NoScript protection that remains active even when scripting is globally allowed. (Not recommended, and never necessary, btw.)

One bank example not working is https://www.elevationscu.com/
Type in any username and password and you see the problem

[NoScript XSS] Sanitized suspicious upload to [https://www.elevationsbanking.com/onlineserv...

I was unable to reproduce the XSS message, using any user/pass as requested, on either Firefox 3.6.25 or Fx 9.01.

btw, your Fx 8.0 is obsolete and unsafe. Please update to the latest supported version. It may or may not affect this issue, but it should be done.

On that line of thinking, what version of NoScript are you using?
If it is not the latest, please update that also, and try again.

Also -- and this may in fact help -- try latest development build, whose release notes specifically cite this fix:

v 2.2.6rc2 =========================
x [XSS] Fixed sanitization reporting bug

It sounds from your XSS message that you may very well be a victim of that "XSS sanitization reporting bug".
That may well be why I couldn't reproduce the XSS message: I'm already using 2.2.6rc2.

Please try that development version, and let us know the results.
Thank you.

[therube]

@Tom, did you allow both elevationscu.com & elevationsbanking.com? You should be able to duplicate the XSS message.

Without the Reload, elevations reports:

Code: Select all

System Error 	#202-74713350

A system error has occurred while processing your last request. Please try again.

Once Unsafe Reload it reports:

Code: Select all

Error 	#1516-74722254

This login session is not allowed as you already have an existing Internet Banking session on this computer. If you wish to login again, please close all open Internet Banking sessions and / or browser windows and begin again.

To avoid this issue in the future, please close all Internet Banking sessions by clicking either the exit or logout button. If this problem persists, please refresh the Login page to begin.

In any case, suppose an exception would be appropriate, though I'm not really one to know such things? Now could quite possibly be poor programing on the banks end too?

[Tom T.]

@Tom, did you allow both elevationscu.com & elevationsbanking.com?

Yes.

You should be able to duplicate the XSS message.

Can't.

Without the Reload, elevations reports:

Code: Select all

System Error 	#202-74713350

A system error has occurred while processing your last request. Please try again.

Where? I don't see it.

Once Unsafe Reload it reports:

Code: Select all

Error 	#1516-74722254

Since I don't get an Unsafe warning in the menu or elsewhere, I can't do the Unsafe Reload.

This login session is not allowed as you already have an existing Internet Banking session on this computer. If you wish to login again, please close all open Internet Banking sessions and / or browser windows and begin again.

To avoid this issue in the future, please close all Internet Banking sessions by clicking either the exit or logout button. If this problem persists, please refresh the Login page to begin.

Possible cookie/cache issues?

In any case, suppose an exception would be appropriate, though I'm not really one to know such things? Now could quite possibly be poor programing on the banks end too?

Would rather consider the latter before suggesting XSS exceptions. We've seen plenty of poorly-coded sites, and banks are among the worst. (sigh)

In a somewhat-similar case, long-time Web site developer and multi-language programmer GµårÐïåñ was able to find the site-coding flaw. Let me see if I can get him to take a look at it when he has a chance.

[GµårÐïåñ]

In a somewhat-similar case, long-time Web site developer and multi-language programmer GµårÐïåñ was able to find the site-coding flaw. Let me see if I can get him to take a look at it when he has a chance.

Looked and answered in the PM but will leave it up to you how you want to disseminate the discussion.

[Tom T.]

@ ALL: Here is the pertinent part of GµårÐïåñ's PM:

(I) took a look and it seems that what they are doing is using URL posting variables to do their activity which is what legitimately triggers XSS.

Example: If I do a GET to the server and ask for variables (hidden) that are Name, Pass, X and get the reply, the URL won't contain that information. However, if I do a POST to the server like http://server/processor.ext?Name=Tom&Pass=dogfood&X=y , then that will show up in the URL and could possibly get exploited or even be an exploit if someone knows the hidden variables and be used for injection. Hence why XSS catches those, transforms them to a blank GET to prevent that information being sent for security. Some programmers unfortunately still using URL.parse technique for variables instead of using session.server.request variables which are not user side visible and that's the problem, many developers, bank or not, still have not changed their behavior and realized the potential for problem.

If say I want to hack a website. If I post a random form with some bs or even an empty form and then use transmission capture to see how the server was parsing that data, then I know that I can create a custom URL with all the needed data to bypass its check and voila I am in. Even with the sites that check header to make sure you don't access using hard URL, you can capture the legit header and make the header fake by forging it and then submit from a static HTML code and you are in. Now imagine if some bad code was capture these POST urls and keeping their variables and later using them to create fake code to access the system using your information they just got.

This is the problem that we have and people don't get and why despite what most consider counter intuitive or counterproductive, Giorgio turns the POSTs into GETs to prevent that potential XSS injection or capture, even if its innocent and just stupid coding. Hope that helps. Now GET is not invulnerable either, but certainly limits the attack the surface a bit more. You have to work harder to capture the data....

To put that in as non-technical language as possible:

The bank site coding is sloppy and potentially dangerous. Hardly the first time that's happened.
NoScript is quite properly protecting you from potential XSS attack.

@ elevation:
You may have to create an XSS exception, and we can help you there. Or if NS prompts you whether to allow an unsafe reload, it's up to you, same as if you choose to create an XSS exception. Either way, you cross your fingers and hope the bank has not been attacked by XSS.

However, if I were a customer, I would be screaming my head off to the bank's IT department. Often, they contract the site design to third parties, but no matter; the bank is still responsible. If they paid a third party for this design, then let them demand that the third party follow the safer coding practices as recommended by GµårÐïåñ, or get their money back and find a better contractor.

It doesn't matter if the OP or any other customer/user understands the above analysis. An actual programmer will, so feel fee to quote from this thread or to link to it, and make sure it gets into the hands of someone who has the capacity to understand and/or the authority to get it changed.

@ GµårÐïåñ:

I knew I could count on your many years of broad and deep experience in proper web site design to see where these people went astray. Many thanks, my friend.

[coltswalker]

Update: Culprit feature located:

Options -> Advanced - >
uncheck "Turn cross-site POST requests into data-less GET requests"

Since I am only allowed a finite number of failed login attempts every 24hrs it took some time and patience for me to go through the various NoScript options and by process of elimination determine which one was culprit.

When "Turn cross-site POST requests into data-less GET requests" is checked, I am not able to login to online banking, even with Allow Scripts Globally enabled. The bank web site treats it as though I entered an incorrect password.

By unchecking "Turn cross-site POST requests into data-less GET requests" I am able to login.

What are the security implications of disabling this particular NoScript feature?

Are the bank web site coders idiots by utilizing a technique that is potentially insecure?

Should I contact my bank and try to explain to them why their coders are not proficient?

These questions are worth pondering.

[Tom T.]

Update: Culprit feature located: <snip> By unchecking "Turn cross-site POST requests into data-less GET requests" I am able to login.

What are the security implications of disabling this particular NoScript feature?

You are drastically weakening NoScript's XSS protection.

If the bank is vulnerable, your machine could become totally compromised, and/or your funds stolen, login creds stolen, etc., without your knowledge, and there's probably nothing you can do to prevent it, barring very high-tech things like writing your own Greasemonkey scripts, in such a way as not to break the page (may not be possible).

See the XSS FAQ

Also see the quote from GµårÐïåñ's post about the dangers of posting your login creds in the URL (address bar). To illustrate the difference:

Searching Google for "Bulgaria" results in this address in the bar:

Code: Select all

http://www.google.com/search?sclient=psy-ab&hl=en&site=&source=hp&q=bulgaria&btnG=Search&gbv=1&sei=TukgT8e_FMT00gGtntDtCA 

The search query is in the URL, "&q=bulgaria". No big deal, really. But here's how a more aware site does it:

Searching https://ssl.scroogle.org for "Bulgaria" produces this:

Code: Select all

https://ssl.scroogle.org/cgi-bin/nbbwssl.cgi 

And the Google results show *with that same URL in the address bar*.

Now, I don't really care who knows that I searched for "Bulgaria". And for more sensitive searches, Google now offers a secure beta version,
https://encrypted.google.com/. But having one's bank logins sent in the URL - not so good.

Admittedly, the bank *should* encrypt the connection *before* the login is sent. Some didn't (even though the page looked like it would), which was a prime motivator for NoScript's Force HTTPS feature. And attacks on SSL, and forged certificates, aren't unheard of, alas. So, better to hash (encode) your login creds, and send them in the message body of your login attempt, instead of in the URL.

If this isn't totally clear to you, whoever wrote the site had darned well better understand it.

Are the bank web site coders idiots by utilizing a technique that is potentially insecure?

Yes, as said in my previous reply:

The bank site coding is sloppy and potentially dangerous. Hardly the first time that's happened.

Should I contact my bank and try to explain to them why their coders are not proficient?

Yes, as said in my previous reply:

However, if I were a customer, I would be screaming my head off to the bank's IT department. Often, they contract the site design to third parties, but no matter; the bank is still responsible. If they paid a third party for this design, then let them demand that the third party follow the safer coding practices as recommended by GµårÐïåñ, or get their money back and find a better contractor.

Noting that:

....feel fee to quote from this thread or to link to it, and make sure it gets into the hands of someone who has the capacity to understand and/or the authority to get it changed.

(added the emphasis here).

I can assure you that Customer Service isn't the place for that. You can try the Online Tech Support, etc., but usually, they're limited to the most common user issues, and not one caused by a tool protecting you from dangerous coding. (They didn't code the site, I promise.)

What they'll probably do is tell you to disable the offending tool -- as you did.
They'll assure you the site is safe. They have no clue.
There's a pretty good chance -- no guarantees on this one, but likely -- that they have no idea what "Cross-Site Scripting attacks" are, and probably have never even heard of them.

You may have to write letters to the President or whatever. Assure them that you'll hold them liable for any losses caused by the faulty programming.
(Might not win, but the thought of "lawsuit" and "bad publicity" are highly effective.)
Possibly, e-mails to places either high enough in the bank's food chain, or if you can get an actual address for someone who knows about programming.
As said, it's likely that they used a contractor anyway, but they should forward it on.

I've had sites tell me to disable my AV, my firewall, etc. -- uh, no, thanks.
If you can't make your site safe enough to pass my AV and firewall, I'll find a bank who can.

Two examples, not of danger, but of "false sense of security":

1) Bank X strongly urged me to install an "online banking security tool" from a third party. I don't want to mention the name of the tool, because that opens up a whole new discussion of that tool, which we don't need. I just sent them a link to a tech article describing how the tool was trivially defeated. They still have the link to the tool on their site, but they aren't so insistent any more. -- at least, to *me*.

2) Bank Y introduced a new "security stamp", which would be included in all e-mails they sent, to ensure that the e-mail was from them, and not a forgery (phishing attack) -- or so they said.

I copied/pasted their "security stamp" into a Word-type doc, added some verbiage, and sent it back to them, showing how ridiculously easy it was to forge such things. And since the stamp contained the name of the account holder and the last four digits of the account number, the phiser has the same info, since non-encrypted e-mail is more like e-postcard -- a lot of people can read it *effortlessly* as it travels the Net, and others can do so with some effort.

I suggested that they get rid of the stamp, take the name off of e-mail communications, or at least, the last name (since the email address didn't necessarily match the account name), take the digits off of same, and most of all, stop sending e-mails. If there is info I need to know, they, like most online financials these days, have an internal secure messaging system that functions only when you are already logged in, and therefore, over an SSL/TLS encrypted (https) connection. They can then send me a notification in regular e-mail: "Hello, customer. You have a new message. Please log in to your account to read it." Fine.

But DON"T put a link to the bank's login page in the e-mail!

Bank Y has ignored me, so far. Since it's mostly the false-sense-of-security thing, and I'm less likely to fall for a phishing scam than most of their customers, I didn't waste any more time. But your issue puts *you* at risk.

These questions are worth pondering.

IMHO only, they're no-brainers.

Again, please feel free to refer to this thread (especially to GµårÐïåñ's analysis), to the NoScript FAQ, especially XSS FAQ, or any other resource.
Good luck, and let us know how you fare.

[GµårÐïåñ]

I could have told you how to get NS to stop protecting you if that's what you wanted. That option is there to protect you in the sense discussed in my message with Tom, but if you prefer to run without it, godspeed and best of luck. Don't be surprised if it comes back to bite you, even with a bank.

Tom, you are welcome my friend and it seems regardless of the explanation, people will do what they will do. The path of least resistance. I guess they have no choice or know no better, who knows.

[Tom T.]

I could have told you how to get NS to stop protecting you if that's what you wanted. That option is there to protect you in the sense discussed in my message with Tom, but if you prefer to run without it, godspeed and best of luck. Don't be surprised if it comes back to bite you, even with a bank.

Tom, you are welcome my friend and it seems regardless of the explanation, people will do what they will do. The path of least resistance. I guess they have no choice or know no better, who knows.

My friend, I think you may be a bit harsh on our OP. He wants to log in, but can't. How annoying would that be, when it's your BANK?
And especially when it's the bank, and not the user, who is at fault here.

In his exasperation, perhaps he did not read carefully, or did not understand, or just *needed* to get into his bank, and so took the risk until the topic could be discussed further. Let's give the benefit of the doubt.

We know these dangers. Most users don't. I've given a good-faith explanation, and let's hope OP takes it to heart.
It's a nasty virtual world out there, and the task of protecting *and educating* users is never-ending, but I know that you're as committed to it as I.

Peace, Brother.

[GµårÐïåñ]

I said what I said in direct response to what the OP said in the followup. He said that he nearly burned all his logins to try and figure out to disable XSS function in NS, we could have told him that if he had just said he cares more about logging in rather than understanding why he can't. Also I was clear that sometimes they have no choice, although sometimes they just don't care or understand. All legitimate, however harsh it may seem in writing.

[Tom T.]

He said that he nearly burned all his logins to try and figure out to disable XSS function in NS, we could have told him that if he had just said he cares more about logging in rather than understanding why he can't.

Valid point, especially if "cares more about logging in than about the security risks of doing what the bank requires".

Still hope OP takes the advice and gets on the bank, because every other customer of that bank is at the same risk.
We, and OP, could be doing a lot of customers a huge service if the bank corrects its dangerous coding.

[coltswalker]

What I am forced to do is to temporarily disable "Turn cross-site POST requests into data-less GET requests," do my online banking, then immediately enable the feature once I am completed. As a general rule I deny scripts globally and leave the protection features of NoScript active. Only the one bank web site requires I disable the cross-site POST request feature. Incidentally, I am now able to leave "deny scripts globally" active. I recognize the crappyness of the bank's web site, and with that being said, my bills are still due. The online bill pay keeps the creditors away.

This is in a small town and I have few options for banking resources here. The bank I use for my business is the _only_ bank in town that offers online services and is a national bank, which is necessary for me when I travel. Again, the _only_ bank. The only national bank chain represented in this small community of less than 8000 residents. I consider all options, paper bill pay, the bank, other banks, etc. and I make a realistic decision based on the reality of circumstance.

I could have told you how to get NS to stop protecting you if that's what you wanted

Ummm, yeah! At least for the immediate. I have no choice, I _must_ do my banking. I am like, "I hope these guys in the forum can help me out so I can get these bills paid today." Give me the duct tape today, and tomorrow I will worry about the long term viability and consider all my options. Today, I must pay these bills that are due! Tomorrow I will tackle a long term solution.

cares more about logging in than about the security risks of doing what the bank requires.

The fact that I took the time to install noscript and that I actively use noscript on a daily basis I think refutes any claim that I am not security conscientious. I never said, "Oh I am just going to stop using this darn noscript thing forever." I merely said, "I gotta disable it to do the banking." No other "surfing" is performed until NoScript is enabled. Consequently, you do realize that no less than 98% of the web browsing community is not using NoScript, or any other security related extension that is even a fraction as comprehensive. Most people surf with their pants down and eyes wide shut.

I am guilty of skimming forum responses, only because in these types of forums there are a lot of unqualified responses mixed in with useful information. It takes a lot of valuable time to read and discern the useful from the noise. I mostly focused on carefully reading the responses of Tom T since my initial read scan concluded most relevant. No offense to anyone else, and everyone's desire to assist is recognized and appreciated, but I know, for example, that blaming "cookies" is just part of the noise that my visual scan is engineered to skip.

Point: Users are looking for an immediate "work around" as well as a long term viable solution, both. Both are critical in about any support scenario.

I will get after the bank for all the good it will do. They probably don't care or won't listen. Although, to their defense, it is difficult for companies to discern the kooks from the occasional creditable customer complaint. First level support is their "firewall" between the kooks and the creds. Unfortunately, it has become next to impossible to get past first level and onto someone that can utilize the data in the complaint details - with any business the customer tries to communicate with nowadays.

Thank you all kindly.

[Tom T.]

This is in a small town and I have few options for banking resources here. The bank I use for my business is the _only_ bank in town that offers online services and is a national bank, which is necessary for me when I travel. Again, the _only_ bank. The only national bank chain represented in this small community of less than 8000 residents.

Great! If it's a national bank in a town of 8000, then there is surely only one branch, and the employees are more "know every customer" than in the Big City with 100 branches.

So get right to the manager, bringing that mobile device with which you travel, with this thread up and ready when you wake 'er up, and sit there until s/he reads it. Of course it will be gibberish. But demand to know who at the national level can and should receive this info.

Letters to the editor of small-town paper, local blogs or community bulletin boards -- a lot of pressure can be exerted in such situations.

Also, is it possible to find a better (more secure) bank online, even though it has no local branch, and then do a one-time linking of the accounts? I have one online-only bank -- have had others over the years -- so: You deposit your paycheck, cash, direct deposit, etc., @ localbank, should you like. You log in -- safely -- to a better-coded bank. Transfer the needed funds -- takes about 2-3 business days. (This does NOT require logging into local unsafe bank. All done from SafeBank.com) Then do all that online stuff from the people who care enough to hire competent site designers. Which is *NOT* all of them. If they require disabling NS or any function, forget it. (I have another story about that, but not sure if your scanner is engineered to skip Real Life anecdotes, so will save it for the end.)

Anyway, now you can travel, pay the bills, etc., with SafeBank, while still having the convenience of LocalWebDisasterBank for ATM, cashing checks, etc.
... Just a thought.

The fact that I took the time to install noscript and that I actively use noscript on a daily basis I think refutes any claim that I am not security conscientious. .... Consequently, you do realize that no less than 98% of the web browsing community is not using NoScript, or any other security related extension that is even a fraction as comprehensive. Most people surf with their pants down and eyes wide shut.

Yes, we do realize that. Which is all the more reason that for those 2% who do care enough, we feel that we owe it to them to help them get the maximum possible benefit and protection from NoScript. (or any other tool or situation that arises in the discussion, if relevant to the topic.) Make sense?

It takes a lot of valuable time to read and discern the useful from the noise.

Can't argue. But when we're talking online safety, especially *banking* safety, isn't the time even more valuable if it obtains info that might be missed in a quick scan? Fifteen minutes could save you (uh-oh, starting to sound like a car-insurance company here. )

Point: Users are looking for an immediate "work around" as well as a long term viable solution, both. Both are critical in about any support scenario.

Counter-point: That isn't always possible. (Cue song, "You Can't Always Get What You Want".) Of course, the quick work-around for any NS issue is just to disable NS. You may choose to do that, but we're either going to find a viable long-term solution (which may be "change banks", since we can't change their coding), or, if there isn't a risk-free work-around, advise exactly what the risks of less-desirable workarounds are. Then you can make an informed decision -- as you have done, but with full knowledge.

I will get after the bank for all the good it will do. They probably don't care or won't listen.

See above re: small-town relationships.

Although, to their defense, it is difficult for companies to discern the kooks from the occasional creditable customer complaint.

I think this product and this forum have a fair amount of credibility, which is why I suggested loading your ammo and your team first (that's we), rather than goin' in alone. (Hint: Service reps in such situations are intimidated by those with a higher level of tech knowledge than theirs. Works for me. )***

First level support is their "firewall" between the kooks and the creds. Unfortunately, it has become next to impossible to get past first level and onto someone that can utilize the data in the complaint details - with any business the customer tries to communicate with nowadays.

Clearly we agree, as I pretty much said the same thing. Persistence pays. "The squeaky wheel gets the grease".

You like short answers? "Squeak!"

Thank you all kindly.

You're quite welcome. Do let us know how you fare with Evil Bank, and if they have a toll-free tech #, PM it to me. Heck, I may (or may not) call them myself. No promises, 'k?

*** I've spoken to bank Cust. Svc people who've never even heard of Firefox, much less NS. Hey, if you want to get online, you just click this little blue "e", right?
*******************************************************
End of actual discussion. Strictly-optional anecdote if you ever have a couple of spare minutes, or for anyone else reading this thread.

I couldn't log in to Bank Z. Turns out that they required allowing a third-party data-mining script - also running under HTTPS, kind of under their umbrella - mining my financial transactions?

Called and squeaked. (How's that for short version?) Said, there's an easy out for me here. Whenever I need to do something, I'll call your friendly customer-service reps, for every transfer, every payment, etc. Which costs them a lot more money than letting the magic box do it.

Never got a phone call from anyone about it (of course), but within a few months, the data-miner was running as a separate third-party script, as it should, and therefore, blockable by NS. Or with Surrogate Script, in some cases. Happy ending.

Another, less-harmful case: Saw that BankQ itself was running the data-mining script, Urchin Tracker, which has been owned by Google since 2005. I asked Giorgio, what could be done about the bank running it itself? Answer: "You're much safer with the bank running it on their own, in-house, to collect general usage data than with them contracting a third party, like google-analytics.com, to get the data and send it to them." Cool.

This Just In: Urchin Tracker sales are being discontinued at the end of March 2012, though current installations should continue to function.

We are encouraging Urchin users to migrate to Google Analytics,

ETA: Now you understand my friend GµårÐïåñ's nick: He's the Guardian of your and other people's bank accounts -- and their computers, *identities*, servers, web sites, corporate infrastructures, proprietary/trade secrets, etc... (yeah, he gets a bit riled at programming incompetence. So would you, if you were in his place, and saw it so frequently, and to such a degree.
Cheers.

[Tom T.]

national bank is great bank

Totally irrelevant post. If your purpose for joining here and trying to make a "legitimate" post (you did not succeed) was to start spamming,
DON'T EVEN THINK ABOUT IT!