Good programmers write good code, but great programmers DO steal. And reuse. And recycle. And this can often include recycling the bad along with the good.
Bad example: Let’s look at some (in)famous virus examples. We all know that Stuxnet, DuQu, Flame, and Gauss were related in core code elements. All four have been described as being “nation-state sponsored cyber-espionage toolkits,” according to security software company Kaspersky. Flame was based on a different platform from Stuxnet and DuQu, but contained chunks of the same code in the guts. In these four instances, code was reused and recycled on purpose because it got the job done.
Not-so-bad examples: Niantic produced Ingress, and now Pokémon Go with many of the same data points–an international sensation of a GPS-based mobile game/app. However, the app requests more permission than it needs, though it has not accessed any user information directly. In addition, because of its popularity, people started looking for locations to download it before the game was available in their region. Black market DroidJack (backdoor infected) versions of the app were made available and lured many innocent gamers into downloading a malicious version of the app, and may have had their usernames and passwords compromised. In response to security concerns being raised, Niantic issued a statement that they will release an update to the app to request fewer permissions, while Google is pushing a fix at their end to reduce the app’s permissions. It is closing the barn door on the remaining horses, but let’s face it, more than a few got out.
Programmers are paid to make their deadlines and produce results. In this process, there is too often room to ignore the permissions offered via mobile applications, or other cross- or federated-identity based web applications. The logical outcome illustrates how insecure coding practices are used in one application, they can be repeated and magnified and abused in future applications based on the same code.
So what to do? Be a great coder and continue to cut and paste code, but know how the code works, not just that it seems to work. Write code that reveals intent, which allows for a maintainable code base.
Leave each bit of code better than you found it, like camping, clean up after the mess of others as well as yourself.
This is where source code testing is really going to make a difference. Constantly ask yourself (and your team) the important questions: Are all my data calls necessary and appropriate? Do the right permissions exist? Have I authorized and authenticated using the very best practices? Static application security testing tools are out there. If you lack the experience in finding and using them, or require a third-party test for governance or compliance, there are options.
I’m not sure which coding guru first coined the phrase, “The code to hell is paved with good intentions,” but the application security practice owes that programmer a drink.
