Fixing XSS on a bank website - A customer's saga | Hacker News Reader

Fixing XSS on a bank website - A customer's saga

tech.bluesmoon.info

85 pointssagarun26 comments

I had some fun, fun times attempting to address a wide variety of security issues in code from a partner company at, well, let's call them a popular outsourcing destination. It involved, at one point, having to explain to my management why their least senior engineer needed the webcasting room so that he could explain XSS to the ISO-certified 20+ years of experience blah blah blah project leads over there. "This is not Severity: Cosmetic. It lets anyone expose our corporation to End Of The World Nightmare PR, because they get to [predictable consequence of compromise of system, punchline is 'people die']." "But only if they find out about it, right?"

That was a very, very long 2.5 years.

Might this popular outsourcing destination be the same one that ICICI Direct serves? :)

My current employer has asked me to forget about "SQL Injection `problems`" and told me to focus on the deadline. sigh

This came up in our engineering ethics class in college. Suppose you said "No, that is unethical / professional irresponsible / etc." or its effective-but-weasley younger brother "Please document that request in writing."?

Don't worry, I ignored his request. :)

Submit an exploit anonymously somewhere where it will get published. Obviously, don't indicate that you're an employee. A big benefit of full disclosure is that it doesn't allow companies to sit around and ignore security problems without facing serious liability risks at the very least.

I've never used any library to communicate with a database that made safe code harder to write than unsafe code, so I don't see how this will be an issue.

It's not difficult to avoid, is it? Sanitize input and use parameterized statements. I'd take longer to not do those things, personally.

"`problems`" in scary quotes. :)

He is lucky the bank did not serve him with a lawsuit for "hacking".

Actually, the bank is lucky that they didn't get exploited by some kids in Russia and then get shut down by the government.

That's exactly why I would be afraid to report something like this.

Reading the article, I was wondering if the story was going to take a turn in that direction. Luckily, it seems that ICIC handled the issue pretty well.

All in all, they seemed to have addressed it a lot better than I would have expected for a large company.

> Although there are better ways to accomplish what you need to do, the immediate way to fix this is to validate the errmsg parameter to make sure it only contains safe values. This means that there should be no <, > &, " or ' characters in this parameter.

No! XSS is an encoding failure. Don't try to solve it with sanitization. That leads to silly situations like users named O'Malley getting errors because you don't allow quotes in names.

Sanitization is for controlling the structure of data, like making sure names aren't a million characters long, or making sure all orders have at least one order line. It prevents situations that shouldn't be possible, that aren't sane. Get it?

"Encoding" means representing data in different ways, for instance so it can be stored/transported in a stream.

    Raw string: <>&"'
    XML-encoded: &lt;&gt;&amp;&quot;
    JSON-encoded: <>&\"'
    URL-encoded: %3C%3E%26%22'
    SQL-encoded: <>&"\'
    CSV-encoded: <>&""'

Same string, different representations. That's encoding.

encoding is a subset of sanitization

One of my clients is a Bank. I work occasionally on one of their intranet-sites-that's-actually-not-on-the-intranet-but-the-internet, and it has a password recovery procedure written in plain text on the login screen and open to the most basic social engineering imaginable [Have to be careful what I say here. I'd love to describe just how easy it is, but I'd better not]

I've spoken to them and told them this is A Very Bad Thing, but they just brushed me off, so I wrote a pretty strongly worded email outlining how and why it was bad, but they just said [paraphrasing] "That's our procedure. people forget passwords all the time and we need to make it easy or they'll get upset"

The people in charge honestly seem to have no idea that people from outside the company can see this site. I try and try, but now I just despair

> One of my clients is a Bank.

In that case, and based on their brush off, don't deal with IT. Send your concerns to the Internal Auditing department. They (usually) have the stroke to make people sit down and take things seriously. Internal Auditing is the ones who have to interface with federal regulators, and possibly with the SEC.

Incidentally, I work at a bank, and to get access remotely you have to have a randomly-generated username, a random password, and a client-side certificate. The VPN software denies all outgoing connections except to port 80 (and the VPN port, I guess) when it is not active. When it is active, it makes all the network interfaces that aren't the VPN disappear (so you can't see your link-level network anymore). Then, it asks for your password every 24 hours.

Usually I find the commute to work less stressful.

But it does show you that some organizations do take data security seriously... perhaps too seriously. (The port blocking is just security theater. I can run whatever I want over port 80. But the random username / random password / client-side SSL certificate is excellent security.)

But the random username / random password / client-side SSL certificate is excellent security.

The SSL certificate is, but not the random username. That's just a maintenance hassle. A username is not a secret - that's what the password is for. The random password isn't so great, either, because it pretty much forces you to write it down and then it just becomes a (poor) version of the SSL certificate. It should instead be a strong password that you can actually remember.

It should instead be a strong password that you can actually remember.

I agree that in theory a strong password one can remember is more secure than a randomly generated password that you have to write down.

However in practice, people just choose easy to guess passwords, or reuse the same password everywhere. That's a larger security problem, so the random passwords are more secure in practice.

Most really secure VPNs I've used have use a SecurID[1] token and PIN, instead of a static password.

[1] http://www.rsa.com/node.aspx?id=1156

I've been using an extranet site recently that calls you, using Twilio or something I guess. They have my mobile phone number.

You enter your username and password on the web form and your phone rings a couple of seconds later. You are asked by a recording to type in your PIN. When you do, the HTTP request is completed and you are logged in.

It's very easy as a user, and seems quite secure. The username/password/PIN are all quite weak and easy to remember, but in conjunction with the phone call, it's fairly strong.

What do you mean by not seeing the link level anymore? What happens if you connect your vpn through a virtual machine? Will the host still have normal internet?

[Have to be careful what I say here. I'd love to describe just how easy it is, but I'd better not]

I know, dealing with "legacy" PR based on controlling the message that is fundamentally flawed.

I wouldn't be too quick to criticize ICICI on their fix. They did the right thing -- the quickest possible secure fix. Yes, input filtering is the "most right" fix, but speed is even more important in cases like this. It's quite likely that switching to a boolean significantly reduced the number of side effects. If they don't switch on input filtering in January some time, then we can start criticizing.

Reply on news.ycombinator.com