It's easy to paint a mental picture of the less-than-savory characters that make application security measures necessary, but you have to admit: they're clever. Security experts on the good-guy side often refer to efforts against their faceless antagonists using terms like "chess" and "cat and mouse." As soon as they fix the source of one exploit, they find another and the game begins anew.
That said, don't make the game easy for hackers. While there'll likely never be such a thing as an unexploitable product, protecting these three well-known areas of attack is a great proactive step:
Think of your software as a perimeter fence: Some areas are well-protected by bright lights and snarling guard dogs, while others are less secure by design. After all, you have to leave some space for people to get in — guests don't like to bring grappling hooks and doggie treats just to pay their friends a visit.
Here, user input forms represent those less-secure areas. Like your fence's points of entry, you can't exactly do away with them, but they can represent a huge application security problem all the same.
Take SQL injection, arguably the most well-known security flaw out there today. The "injection" part of its name comes from the way attackers use forms to feed malicious code to servers; after a successful attack, they can access usernames, passwords and all sorts of other critical information.
Many forms of Cross-Site Scripting, another all-too-common attack, also make use of forms. For example, attackers may use an unprotected "comments" section to run a script that infects a page and, thus, users who visit it.
The lesson here? It's critical to stay on top of all input forms. The strongest fence in the world is worthless if your gates are wide open, after all.
It isn't just new code you have to look out for. Unchecked (and often forgotten) legacy sites can cause serious headaches, too. If you remember the Bell Canada breach, you know exactly what that means: After discovering parts of the business's site were written in a long-retired coding language, attackers were able to access all kinds of private, sensitive data, including usernames, encrypted passwords and partial credit card info.
The problem, as the above-linked article states, is keeping on top of the unwieldy number of sites a business can create over time. Many legacy sites are simply left where they are after they outlive their usefulness, with no action taken to delete or secure them from potential attacks. From there, it's easy for businesses to forget the sites ever existed — at least until a breach occurs.
Securing a perimeter is often a combined effort, with the primary company and all third parties keeping in-use legacy sites secure and removing old or unused ones. To quote the same article, "covering the entire perimeter is the new application security challenge" — and shrinking that perimeter when possible is one good way of having less to cover.
You have to encrypt sensitive data — that's a no-brainer. Thus we have the group of problems commonly called insecure cryptographic storage, the gist of which is this: When you implement encryption incorrectly, you may think your data is protected when it's really not. If an application needs to decrypt credit card information before it can use the data it contains, that data becomes more susceptible to SQL injection exploits. If hackers gain access to passwords, they also get entry into the systems those passwords protect.
Like the other issues listed here, preventing crypto issues boils down to a combination of good code and good practices. Restrict access to crypto-related information (such as proprietary algorithms or encryption keys) — even for system administrators. Make sure to use encryption from trusted sources, not internally developed crypto. And if you have never checked your software for insecure cryptography issues before, strongly consider outsourced scanning solutions that can identify and eliminate them.
It's vital that you handle data properly from storage to encryption to access. When information is as valuable as physical goods, not even internal actors can always be trusted. Make sure your policies and practices reflect that mindset.
These are just three examples of how proactivity is always better than reactivity in the world of application security. If you'll forgive yet another analogy, it's like fixing a busted lock: Sure, you could do it after thieves come, but you'll have a much bigger mess to clean up. Reach out to trusted sources to improve your security before it becomes a larger issue — you'll be glad you did.
Photo Source: Wikimedia Commons