Banking apps: Handy, can grab all your money... and RIDDLED with coding flaws

The whopping 70 per cent of retail and 69 perc ent of financial services apps are vulnerable to data breaches. That's according to an analysis of 705 million lines of code as used by 1,316 enterprise applications carried out by software analysis and measurement firm CAST. The firm reckons a growing number of data breaches and …

[Anonymous Coward]

Not entirely surprising when IT in most banks is treated as nothing more than an annoyance that should be outsourced whenever possible, and then to the lowest bidder, and then with insufficient oversight, and tested by another lowest cost outsourced company with similarly poor oversight.

There's nothing wrong with getting good value for money, but until banks realise that IT is the core of their business and that modern banks are far more dependent on IT than their entire branch network then this isn't going to change.

[AJames]

Not surprising

I don't think anyone is surprised by this. You could choose any random group of software applications and find the same thing. We could hope that mobile banking apps would be better tested than most, but I think we all suspect that they aren't.

From my own perspective of decades of experience as a software developer, product manager, and software business owner, I know it's really about the money, but I'd also like to point the finger of blame at two technical issues:

1. The C language and its derivatives. Biggest mistake in the history of computers. Every time you hear about a buffer overflow error in software, realize that it's due to a fundamental design flaw in the C language that leads to the same error repeated over and over. If civil engineers had used building techniques as flawed as the C language, our civilization would lie in ruins today.

2. The preferred modern software development method of "code and test incrementally until it doesn't crash any more". Naturally produces poorly tested software riddled with bugs. Reminds me of the early history of constructing railroad bridges: no need for detailed analysis, if it falls down we'll double the strength and try again.

[Destroy All Monsters]

Re: Not surprising

This.

People are just too fucking stupid to use C. ESPECIALLY the ones who take pride in bumming every single "drop of performance" out of some crap loop that isn't even used in a supercomputer matrix multiplication.

Declarative and Functional programming should have been taken up big in the early 90s so that it would now be pervasive, but even back then academia was still forecefully studying how to write "for" loop properly and was actually teaching this to students.

[Dan 55]

Re: Not surprising

Not sure why C's getting the blame for bad Android apps (see end of article) since most Android apps are written in Java which, lest we forget, is a language that's so bureaucratic that if you want to do anything with a string or a buffer you must take a number and fill out a form in triplicate while you wait... yet even that doesn't stop bad apps getting coded.

Bad programmers are going to code badly. C, ever obliging, just helps them get there quicker than other languages.

I do any bank stuff in a browser anyway, on the assumption that whoever's written the browser cares about doing SSL properly whereas the bank cares more about how pretty the app looks.

[RyokuMas]

Re: Not surprising

Now hold on...

"Not sure why C's getting the blame for bad Android apps (see end of article)"

The end of the article is talking about free apps that were surveyed, not banking apps. In fact, I don't recall the article mentioning that the problem was specifically with Android banking apps.

Not that I trust any banking app, regardless of OS: while the current security spotlight is on Android due to it being both the biggest and easiest target, I firmly believe that nothing is secure if someone has good enough reason to want to break it.

[dogged]

Re: Not surprising

Hold on a moment.

Java and C# are both C derivatives. Neither are susceptible to buffer overflows. Both are (now) efficiently garbage-collected.

Really, your issue appears to be the Design Authority specifying unnecessary close-to-the-metal performance languages where they're not required.

Also, if you have a problem with TDD techniques, I suggest you're either some sort of project manager who knows dick about dick or one of those legion of Reg-reading first line support wonks who only knows what his script says. But not to worry, you can always turn it off and on again, right?

[Nick Ryan]

Re: Not surprising

Sorry, but singling out "C" as the "biggest mistake in the history of computers" comes across as nothing more than fanatacism. Dumb, dangerous code can be written in all usable computer languages. Newer languages may have more built in range checks at the language level but these most definitely do not prevent stupid and there is no single programming paradigm that is more correct or more universal than others. "C", being a defined standard, was probably the best thing that happened to computers as it facilitated code and skill re-use rather than the previous situation of vendor and system specific languages and code. Copying code has its drawbacks of course, but it is generally considered better to re-use code than rely on individuals recreating the same things time and time again.

Most dumb code is produced either by poor quality or inexperienced developers (usually operating in a poor or non-existent review framework), developers who do not use how to use profiling and checking tools or chose not to use them, or developers working in a financially constrained environment where there is pressure to release code whatever the state in as short a time period as possible. On a lesser pool, the "I'm really clever I write minimalistic code" developers cause a lot of issues as well, but these are usually swamped by the quantity of code produced by others.

I've had to beat so many developers who turn off compiler warnings and hints because "there are so many"... FFS... they are there for a reason. Look at them, learn from them, fix them. There are (rare) occasions when compiler warnings and hints are genuinely false, but on these rare occasions such checks can be turned off and re-enabled and clearly documented as to why this is happening.

In the past I've also had the joyless task of having to to unpick "exceedingly clever" code that featured convoluted 40 operator logic statements and to instead separate them into useful code blocks that was both maintainable and allowed problems to be accurately logged with appropriate error handling rather than anonymous failures.

As previously noted here... Input validation: it's not optional. Validate for expected, unexpected and total nonsense values and handle them appropriately. Trust nothing, especially when it has an external origin and write code that propagates failure cleanly.

[dogged]

Re: Not surprising

> Copying code has its drawbacks of course, but it is generally considered better to re-use code than rely on individuals recreating the same things time and time again.

We re-use through encapsulation, not copying.

[Roo]

Re: Not surprising

"Most dumb code is produced either by poor quality or inexperienced developers (usually operating in a poor or non-existent review framework), "

The lack of adequate review framework is a key fail. You have no idea about the quality of a piece of code until it's been tested and those tests have been reviewed by > 1 trustworthy third parties...

[Charles 9]

Re: Not surprising

"The lack of adequate review framework is a key fail. You have no idea about the quality of a piece of code until it's been tested and those tests have been reviewed by > 1 trustworthy third parties..."

But tell that to the bean counters...

[LucreLout]

Re: Not surprising

"Most dumb code is produced either by poor quality or inexperienced developers (usually operating in a poor or non-existent review framework), developers who do not use how to use profiling and checking tools or chose not to use them, or developers working in a financially constrained environment where there is pressure to release code whatever the state in as short a time period as possible. "

It's a little like driving isn't it. 90% of drivers think they're above average when evidently that can't be the case.

I have never met a programmer that defines themselves as average - everyone thinks they're good and others are average or poor. I have the happy joy of working with a decidely average guy who is extremely vocal about what a good developer should and shouldn't know, down to the minutae of the framework.... yet he still doesn't know what SOLID is, or if he does, he *never* produces code based upon its principles. Config ends up as code. Exception handling ends up missing. Methods end up filling a screen every single time. And still, despite this, and having less than half the industry experience of some of the team, he is adamant that he is the best developer in the team, when there is simply no evidence for that. People like this are dangerous in any language.... in every language.

[circusmole]

Re: Not surprising

C was designed by software engineers for software engineers who know what they are doing. C was deliberately designed NOT to do things the the programmer does not specifically ask it to do - i.e. buffer overflow checks etc. The biggest mistake is by programmers who choose to use C without understanding its design goals - not the language itself.

[dogged]

Re: Not surprising

> The biggest mistake is by programmers who choose to use C without understanding its design goals - not the language itself.

I beg to differ on the details here - programmers very, very rarely get to choose the tools they are asked to use in corporate environments. That happy task falls to "design authorities" who are usually ex-programmers promoted to their level of incompetence and too damn dangerous to be allowed near live code anymore. Sometimes those are project managers or technical leads or even the Reg's beloved CTOs (a less competent bunch would hard to imagine) but the odds against it being an actual programmer who writes code are astronomical.

[Roo]

Re: Not surprising

"I'd also like to point the finger of blame at two technical issues:

1. The C language and its derivatives."

The root cause of that problem is the people choosing to use C where it is not a good fit for their problem & skill set. As it happens it was a pretty good fit for systems programming on PDP-11s with 64kb address space.

[Fibbles]

Re: Not surprising

I don't know why C is getting so much flak. It's not a particularly difficult language, you just need to be attentive to what you're doing. That said, I prefer to use C++ because of RAII (amongst other things).

As mentioned above, bad programmers will produce bad code regardless of what language they're using.

[Brewster's Angle Grinder]

Re: Not surprising

I use C++ because TEMPLATE META PROGRAMMING! Truly, it's one of life's greatest pleasures! Oh shit, I may have outed myself as a crap programmer. Thanks for my coat, I always wanted to be a writer anyway.

[heyrick]

Re: Not surprising

"1. The C language and its derivatives. Biggest mistake in the history of computers. Every time you hear about a buffer overflow error in software, realize that it's due to a fundamental design flaw in the C language that leads to the same error repeated over and over."

I would certainly advocate a compiler option to include bounds checking, however...

Screwing up buffers and pointers is not uniquely a C problem. You could make the same mistake on the BBC Micro with code like pointer%!0=blahblah% which might go badly wrong if pointer% wasn't actually pointing at the bit of memory you wanted to write to.

That said, aren't apps written in a bastardised Java (Android) or some sort of distantly-C-like (iOS) both of which are capable of trapping buffer overruns?

"If civil engineers had used building techniques as flawed as the C language, our civilization would lie in ruins today." - we don't (usually) make buildings with faults because even by a process of trial and error we'd learn pretty quickly how to correct these issues. On the other hand, we seem quite content to build entire societies with hokey specifications that make the C standard look a paragon of perfection. Turn on the TV news and count how many seconds elapse before there is a story regarding a bunch of people dying or killed as a result of theologies with holes big enough to fly an Airbus through.

"2. The preferred modern software development method of "code and test incrementally until it doesn't crash any more"."

Yup. Life was much nicer in the era of software supplied on ROM. If it came on EPROM, you knew to expect some quirks. But if it came on a ROM, well, a faulty ROM set could sink a company so there was none of this "push out what we have and fix whatever develops in the field later" idea.

Now we can have software that checks for updates daily. Sure, it can give you an improving user experience and more and more features, but this is only because the product was a rush-job pile of loosely interacting bugs to begin with. When you start with manure, most things are an improvement...

[Charles 9]

Re: Not surprising

"Yup. Life was much nicer in the era of software supplied on ROM. If it came on EPROM, you knew to expect some quirks. But if it came on a ROM, well, a faulty ROM set could sink a company so there was none of this "push out what we have and fix whatever develops in the field later" idea."

Even then, the fact that everyone only had ONE chance to get it right didn't exempt rush jobs. In the business world, the coders have to compete with the other departments just like everyone else. Ask Atari back in the early 80's. It's particularly hard to to code a game when you have such a short timetable (with NO room to maneuver--it MUST be ready in time for the Christmas sales rush or it's not worth doing). Perhaps the RISK of going under beats the CERTAINTY of losing your business to the competition if you don't deliver.

[Anonymous Coward]

What's the stack-smashing protector?

If they've had stack protection since at least Aug 2005, then why aren't they using it.

http://web.archive.org/web/20140430091850/http://www.research.ibm.com/trl/projects/security/ssp/

[Primus Secundus Tertius]

Re: Not surprising

I believe some C compilers have an option to include bounds checking. (It is a long time since I wrote C; the nearest I get to programming these days is a spreadsheet.)

Unfortunately there are always some people who want to optimise the hell out of the program. That is so rarely needed these days, with the hardware so much better and indeed the compilers; but old ideas never die, they just fade away.

[Gordon 11]

Re: Not surprising

Every time you hear about a buffer overflow error in software, realize that it's due to a fundamental design flaw in the C language that leads to the same error repeated over and over.

I disagree. I reckon it's down to a lack of fundamental design by the implementer, who should be using a library function or macro to check sizes and/or use proper typedefs to ensure that things remain the same size.

The problem is that too many coders reckon that the language is going to avoid problems, rather than assuming any responsibility for it themselves.

A bit like saying that when a joy-rider rolls a car by driving too fast that he's not to blame at all as it's the car's fault for not preventing him from speeding.

[RyokuMas]

Re: Not surprising

Nah, Javascript is the biggest mistake in the history of computers - almost illegible if you want to construct anything much bigger than "animate this bit of webpage"...

[geekguy]

Re: Not surprising

Point 1 is true,

I cannot agree with Point 2, it is not the case that either TDD or BDD leads to poorly tested bad quality code. It IS the case that people have bad practises around testing.

[SW10]

(Understanding VFM)

Very few people truly understand value-for-money. They focus on the money and forget about the value.

I've got problem getting the same outputs for a lower price - I positively encourage it. However, less valuable outputs for a lower price is NOT the same thing.

Hold price constant and you have:

More valuable outputs > my outputs > less valuable outputs

Hold outputs constant and you have:

Higher price < my price < lower price

Try varying the two and... well, you work it out.

[P. Lee]

Re: (Understanding VFM)

I think people understand value-for-money, they just don't care about other people's money.

e.g. a manager extracts maximum value (i.e meeting his KPI) from his budget. The fact that he is dealing with an app which deals with other people's money is really irrelevant to him, especially if the work is outsourced and he can blame someone else if a vulnerability is discovered 1 year down the line.

It's why large companies tend to evil, aggregated systems devalue individual customers and encourage shaving marginal costs which simply wouldn't be worth doing for smaller companies.

[Anonymous Coward]

Why do coders fail to code for input validation

First rule - assume users are idiots and expect them to do stupid things (even by accident).

Time and again I see apps at work abend and crash, due to allowing the users to upload or input data which the application was not expecting ('too much' data, or 'the wrong type' of data).

Input validation should be hard-wired into app coders at every layer - the web layer of app input, data transfer input, API input, ETL processing, to/from the databases...

Garbage in should not mean crash and burn and leak....

[dogged]

Re: Why do coders fail to code for input validation

First rule (in classic banking Waterfall styleee) is actually "write what the business analyst tells you to write or they'll just make you rewrite anyway".

You carry on and blame the programmers though.

[Alan Brown]

Re: Why do coders fail to code for input validation

35 years ago I was writing input validation routines for my programs - and most people around me couldn't understand why I wasted memory and cpu doing so.

Fast forward to today and those same people are the elder gods of coding, passing their arcane knowledge to the new generations.

Couple that with managerial tendencies to grab what's been knocked up in an hour to see if something is viable and push that forward as the finished product and you have a recipe for badness.

[kmac499]

Oft quoted poster on a Garage wall..

" All work guarenteed to be Quick, Cheap,Good (pick any two) "

[Primus Secundus Tertius]

@kmac499

The spelling in that notice, as quoted, does not inspire confidence.

[Anonymous Coward]

Obviously it was produced quickly and cheaply.

[Guus Leeuw]

@LatinWanker:

It does, but only in the quick and cheap parts...

It even fecking said to pick just two...

[Hargrove]

Too big not to fail?

From the perspective of the average "user" computer code is like the US Code of Federal regulations--so monstrously bloated, convoluted, and arcane as to defy any understanding. Sys admins are not much better off, as code critical to system security functions and security is patched and re-patched, often without any visibility. Finally, even were the fact that changes are occurring visible, the code itself is proprietary and invisible.

My experience with government systems has been that, as a result, there is no way that users and sysadmin/IT support people can have any idea what the actual configuration of their systems is, or what any of the parts or the system as a whole actually do.

In my misspent youth i worked on naval tactical data systems. And, I have to concede that all of us involved, individually and collectively did not have a full grasp on everything we needed to know about the systems. But we had some understanding of what the system and different code modules were supposed to do.

When problems occur--and they will--the difference between some understanding and being bloody clueless is like day and night.

What will it take to force a change? The already ubiquitous compromises of individuals credit information and the attendant threat of identity theft at retail points of sale hasn't done it. I don't believe wiping out a significant percentage of our savings and retirement accounts will do it.

A successful hack of one of the "too big to fail" global financial institutions would probably do the trick.

Grandma Hargrove was right: You don't want all your eggs in one basket.

[Anonymous Coward]

Re: Too big not to fail?

"A successful hack of one of the "too big to fail" global financial institutions would probably do the trick."

If the hack of Target and the Crash of 2008 is any indication, I don't think this will do anything, either. Basically, western civilisation has so much institutional momentum that it'll endure anything short of an existential threat. Like the latter days of Rome, nothing will change until the whole blanking works comes tumbling down. Nothing else will budge it, like a wall built so strong that the only way to take it down will require wiping it out completely—AND everything in a 20m radius around it.

"Grandma Hargrove was right: You don't want all your eggs in one basket."

Trouble is life isn't so accommodating. What do you do when the only container at hand is a single half-gnawed basket with holes in it? Oh, and you've only time for ONE trip.

[Vanir]

Re: Too big not to fail?

"Grandma Hargrove was right: You don't want all your eggs in one basket"

Yeah, but Grandma had only one basket, so it was well cared for, maintained, and cleaned regularly.

It was valued. Still, Grandma was wise enough to be aware of risk.

Some people, on the other hand, have had created quickly quite a few baskets, of dubious quality, thinking that this is minimising the chances of breaking their or more probably others' precious eggs. These baskets are not valued, so they are not cared for. Eggs will be broken; that their rickety baskets carry other peoples eggs does not seem to be of concern.

The baskets are now beginning to break up, one by one.

[jonathanb]

Re: Too big not to fail?

I don't think it would, simply because cashing-out on large sums of money that you obtained from hacking into a bank computer, without getting caught, is not that easy.

[Peter Ford]

Re: Too big not to fail?

Cashing out is not necessary - after all, that cash may be worthless anyway if you really succeed in bringing down the system.

The banks just need a sufficiently large shock to restart their hearts.

[ItsNotMe]

Very simple kids...

...G-I-G-O.

[pyite]

One egregious example

My bank's web app has a nice two step authentication process.

However, if you bring up their mobile site you just get a single login/password screen.

L4ME!

[jonathanb]

Re: One egregious example

I can only use my mobile banking apps to pay people that I have already added to the list on the website, so that somewhat reduces the risk.

[Charlie Clark]

Just don't do it

Without an additional thing like hardware encryption just don't do banking with your phone. Even if the code is good, and this is unlikely, the device and the communication channels are too easily compromised.

[Anonymous Coward]

Re: Just don't do it

But then, do you trust the hardware cipher? e-Commerce is basically an inherent risk simply because of the "e". Heck, even B&M banking has its risks (runs on the bank, anyone?).

[heyrick]

Re: Just don't do it

My bank is okay. The code might be utter crap, but the app permits me to check my balance, review a screenful of account activity, order a chequebook, transfer money from one of my accounts to the other. Err... Err... Maybe I can auto-phone my branch too. Or something.

But, then, this is the same bank that requires me to generate a virtual credit card for online use as the real card is blocked from use in any situation where I am not physically present. Can't even use it to pay the electricity bill!

Certainly, I get that this is ultimately about reducing the bank's exposure to risks, but I'm okay with that if it means my account is that much less likely to get screwed over as a result of this. The hassle that would cause doesn't bear thinking about.

[Adrian 4]

Re: Just don't do it

Which bank is that ?

I opened a bank account with cahoot specifically because of the virtual card facility .. which they then dropped (after first making it windows-only .. lol)

[heyrick]

Re: Just don't do it

"Which bank is that ?"

Crédit Mutuel de Bretagne (bet you weren't expecting that!). I would imagine it is likely the same for any of the regional versions of the Crédit Mutuel family.

[Velv]

Re: Just don't do it

"Additional think like hardware encryption..."

So that would be Apple iPhones then. Hardware encryption as standard (3GS and later). I haven't investigated any others.

As for the communication channels, they're the same for all Internet access, so you might as well restrict yourself to performing all transactions at a branch. And carry lots of cash. And be even more vulnerable to attack.

[ecofeco]

That's not their only problem

Bad code is just a part of the problems. The others are inaccurate balance reports and ID confirmation that is either very poor or overly complicated.

List others if you've experienced them.

[Daedalus]

Drones will be drones

The latest way of ensuring poor software quality is to suck everybody into compliance review meetings, or make them work on compliance documents that nobody reads before going into review meetings, which then consist of interminable sessions of dealing with irrelevant questions from people who shouldn't even be there, let alone causing unnecessary distractions.

[ecofeco]

Re: Drones will be drones

You just described most business meetings in every industry.

[englishr]

"Why do coders fail to code for input validation

First rule - assume users are idiots and expect them to do stupid things (even by accident)."

That's a good start, but doesn't go nearly far enough.

Assume that users are evil geniuses with access to the source code and have embarked on a personal vendetta against you, and code to handle input of that nature!

[Anonymous Coward]

this is a long standing problem

I recall a researcher reworking windows 95 to change the routines to "assume input is poor" and design for failure at each point.

I have been coding like this for over 20 years already and where a failure or input error occurs the code can even tell me where and why so when I was called in the middle of the night i didnt have to spend hours just working out what caused it to fail.

Developers, especially outsourced developers rarely have to support or maintain their code once delivered so have no real buy-in to any quality critera other than it didn't crash altogther during testing. We developers on the whole tend to be newer to the game too, and know a language but not the broader skills in developing for security, reliability etc that core system programmers that are measured by their own mistakes whereas mistakes only seen by individual consumers are rarely even reported.

Yes, cost is an issue but application architecture governance is also cheaper if it is lost out of the development costs...

[PassiveSmoking]

Good, Cheap, Fast

The standard maxim in software engineering and development is "Good, Cheap, Fast: pick two".

Sadly, the choice made is almost always "Cheap and fast". Finding the answer as to why this is and what to do about it is what will solve about 80% of failures in code quality.

[Just Enough]

contrary to public perception...

"government IT had the highest percentage of applications without any input validation violations"

This doesn't surprise me, for two reasons;

- Govt applications are invariably designed with the principle that it has to be usable by all of the general public. There is no option to exclude the truly clueless from your customer user-base.

- For the Govt bosses in charge, the worse thing that can happen to their IT systems is that they lose or leak data. No-one wants to be on the front page of the tabloids. For commercial bosses the worse thing that can happen is not turning a profit.

Both of these principles tend to encourage robust code in the public sector, and whatever-gets-by code in the private. (Which is not to say that IT in the public sector doesn't have plenty of other issues the commercial sector doesn't.)

[WaveSynthBeep]

Did a signup process for a financial institution recently. Authentication secrets in the post, all very secure. But then the letter with the random key arrives and says:

"you must enter your postcode in upper case with no spaces"

Err, perhaps somebody ought to introduce them to toupper() and isalnum() ? How hard can it be to write 3 lines of web form validation code instead of wasting the time of a million humans?

[F0rdPrefect]

But ..

Which banks?

All of them?

Only in USA? Australia? UK?

Names should be named.

And there should have been a link to the CAST report so that we could judge it for ourselves.

[Milo Tsukroff]

COBOL Forever!

People trust banks because the back-end language for handling money is, and always will be, COBOL. COBOL is written to be clear and as bug-free as over 50 years of development can make it. Any language that's less than 10 years old and still in development is a guaranteed bug-house. COBOL Forever!!

[Andy Davies]

'an analysis of 705 million lines of code as used by 1,316 enterprise applications carried out by software analysis and measurement firm CAST'

they analysed 705 million lines of code?

no, they didn't.