coltswalker wrote: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
The search query is in the URL, "&q=bulgaria". No big deal, really. But here's how a more aware site does it:
for "Bulgaria" produces this:
- Code: Select all
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.
coltswalker wrote:Are the bank web site coders idiots by utilizing a technique that is potentially insecure?
Yes, as said in my previous reply:
Tom T. wrote:The bank site coding is sloppy and potentially dangerous. Hardly the first time that's happened.
coltswalker wrote:Should I contact my bank and try to explain to them why their coders are not proficient?
Yes, as said in my previous reply:
Tom T. wrote: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.
Tom T. wrote:....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.
coltswalker wrote: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.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20111212 Firefox/3.6.25