This is the kind of vulnerability that should be caught on the whiteboard before a single line of code is written.
I know this isn't what you're talking about, but I hope that an institution that's protecting my money will formally specifying their protocol and not haphazardly putting their app together with "Test Driven Development". But maybe that's how they managed to be this stupid.
Though there are no doubt very, very smart developers scattered across Citi, please bear in mind that the wiring-up-form-fields-using-J2EE jobs in large financials are among the least prestigious in our field. These are the types of apps that are among the first to get outsourced.
Your idea that the input and output paths through a typical banking J2EE app were carefully whiteboarded seems mythologized, based on what I've seen at fisrv companies.
That's hair-raising. I have only a small amount of financial firm experience. I'm just used to ordinary software development being white-boarded first.
People forget that statistically the devs hanging around on HN are in the top brackets. The overwhelming majority of devs are 9-5 paycheck players with exactly the level of competence required to execute J2EE and .NET CRUD apps that pass internal acceptance testing.
If you are an enterprise dev with a knack for making web apps that are't horribly insecure, and you don't have a phantasmagorically awesome comp package already, more advice: start looking for new gigs. You're underemployed.
The problem is to the PHB's in HR, there doesn't appear to be a difference between you and the guy who just makes it work, security-be-damned except that you likely take longer and cost more.
In a market like the New York, Boston, or Seattle areas, with 5+ years of experience, a top tier software engineer should be able to pull down $100k salary plus 401(k), a good health insurance package (ie, something better than a high deductible plan plus HSA), and long term/short term disability insurance. Adjust the salary number for your local cost of living.
Online bank websites are, at least in the UK, universally terrible. They seem to be just a very, very thin layer on top of the bank's back-end systems, giving such delightful results as being two different sorts of recurring payments and two types of non-recurring payments I can do from my online banking (actually, I can't set up or cancel every type from within online banking.)
Do banks make so little from checking/current accounts that it isn't worth spending a dollar per customer to build a decent solution?
(UK has a shared ATM network, so it's not the same issue it is the States where I fondly remember hunting for damm BofA machines. I agree there are other reasons to choose a bank than website.)
However, it seems like there is relatively little to distinguish between banks, and a web service that truly pleased people might be a good way to get and retain customers, whilst cutting costs (branches and call centres.)
Even for those people who do care about the quality and security of their bank's web services, how many of them are really going to take the time to compare the web services of various banks?
How do you compare them, anyway? It's not like banks give out trial accounts you could use for this purpose.
You'd have to go to the trouble of signing up for a real bank account at each of the banks whose web services you'd like to evaluate. Then spend the time to try them out and compare. So even a cursory inspection of a variety of banks' web services would already be a pretty huge hassle.
Even if you go to all this touble, you're probably not going to know much more than how intuitive a given bank's web interface is, or if they did something glaringly awful in terms of its usability.
You wouldn't know how accessible the interface is under load, or test how well the bank's interface handles the various real-life corner cases you're likely to encounter over time.
And how would you test the interface's security? Is even a reasonably security-aware consumer really going to try breaking in to the bank?
The ironic thing is that most users who use online banking probably do care about the web interface and its security, even if they can't articulate it in so many words. But of them, only a small minority care enough and aware enough of the issues to take the time to comparison shop. And even then they probably won't find out much.
There's an opportunity here for a Consumer Reports style investigation in to the web interfaces of various banks. That would be a valuable service that could save the consumer a lot of time and hassle, and maybe even do things that a lone consumer couldn't: evaluate interface security.
I did just that when I last needed to open a bank account :) I googled for users' comments about the bank's web interface (was it working fine in non-IE browsers, not using Java applets, etc).
Out of the major banks in Canada, the one with the most ATMs is the smallest--and incidentally also has the highest Forrester's marks in online banking.
I agree with you about planning, but "test driven development" isn't haphazard; it's not just clicking around to see what happens. It's a way of formally specifying your design that simultaneously confirms that your code does what it should.
For instance, you write a test that says the user should get a "not authorized" if they try to access another user's account. You run the test, and it fails. You change your code to make it pass. And every time you update your app from then on, you re-run the test and make sure you didn't make that test fail.
Having a design on paper isn't as useful as having one that you can PROVE your code conforms to.
There is no guarantee that anything specified on a whiteboard will actually make it into physical code, particularly if it's handed down from on high. Banking websites are terrible not because they use TDD, but precisely because of the supposition that a good architect and a whiteboard is enough safeguard to skip them.
Tests make it possible to refactor your code towards simplicity and clarity, making security errors more clear. If you're writing a banking application, ignoring them is simply foolhardy.
So you're taking a ridiculous loophole created by enterprise architects that probably spent six months whiteboarding this shit before letting the devs write a single line of code as an excuse to troll on the subject of TDD? Lame.
Firstly this kind of vulnerability requires no white-boarding. It is fair to assume that a dev with a reasonable understanding of how the web protocols work will not need a white board to figure this out. So firstly the argument of catching this on a WB is a little juvenile.
Associating TDD to being haphazard is pretty random. Being hap hazard and TDDing are really in 2 different math spaces. Care not to mix em?
I know this isn't what you're talking about, but I hope that an institution that's protecting my money will formally specifying their protocol and not haphazardly putting their app together with "Test Driven Development". But maybe that's how they managed to be this stupid.