Summary: A recent study find that 96% of all web applications contain at least one ‘serious vulnerability.’ As cyber attacks rise, how can your company better protect your web applications and confidential data from a security breach?


Target. . . . Ebay. . . . Monsanto.

What do those companies have in common? Each one suffered a massive security breach in the last few months. They’re not alone. Cyber attacks are on the rise, and will only get worse.

The bigger problem: Most web applications are still vulnerable. This study from last year estimates that 96% of all web application contain at least one ‘serious vulnerability.’

Security is a problem that will keep growing if not made a priority. It’s a problem that can compromise your customer’s sensitive data. It’s a problem that can cause irreparable damage to your company’s reputation.

Today, let’s focus on security from a web application standpoint. How can you strengthen your web application security, and minimize your risk of a data breach? While the list could go on, here are 10 great tips for you:

1. Understand how you will be attacked

In his military treatise, The Art of War, Sun Tzu explains the importance of “knowing your enemy.” If you do not know your enemy’s strengths, weaknesses, tactics, etc…, you cannot win. The same is true for web application security. If you don’t understand a hacker’s strategies, your applications will be insecure. To truly create secure web applications, you must understand how they will be attacked.

“Developers should take the time to learn the techniques that attackers use to hack into applications (OWASP is a great resource for this),” says Chris Camejo, Director of Assessment Services for NTT Com Security. “I know that when I started coding there was very little information on how to write secure code, all the books I read and the classes I took focused on how to make things work and neat little algorithms to make things more efficient. I shudder to think about all the vulnerabilities that I likely wrote in my days as a coder for a long-gone dot com company simply because I didn’t know any better (back then none of us did). Understanding the techniques that the attackers use and actively writing code that will foil these techniques is the first step.”

2. Keep your servers and software patched and up-to-date

Last year, we saw a string of security breaches stemming from the same problem: Unpatched versions of the ColdFusion application server software. With web application security, every little vulnerability opens the door for a security breach. You might build impenetrable applications…but if you put those applications on an unpatched server, your data is still vulnerable.

“Security loopholes are always being found and Microsoft and other software companies release patches and security fixes on a regular basis,” says Matt Boaman, Programmer at EZSolution. “Having a website that’s hosted on an unpatched or out-of-date server could lead to vulnerabilities can make files and private database information an easy target for hackers that know these exploits. Use a third party scanning tool that can be used to run against a website, especially if you are choosing to be PCI compliant.”

3. Trust, but verify user input

“The mantra of ‘trust but verify’ applies to application input,” says Dwayne Melancon, Chief Technology Officer for Tripwire. “Many of the common web application attacks exist because web applications don’t validate the requests they receive. When you design applications, it is important to design them to include functions that verify that all requests to the application – whether they come from a user-filled form, or from an API call over the network. SQL injection attacks, buffer overrun attacks, information disclosure attacks, such as Heartbleed, and similar security holes can be substantially mitigated by ensuring that the application never acts on invalid or malformed requests.”

While this advice might sound obvious, I include it for a very good reason: Despite the repeated warnings over the years, these types of attacks still happen far too often. Developers still aren’t properly validating user input, leaving their data wide open to attackers. The good news: As explained below, frameworks for protecting against these attacks are improving.

“Sanitizing user input is the number one requirement for preventing Cross-site scripting and SQL Injection vulnerabilities,” says Elliott Frantz, Founder/CEO of Virtue Security. “The good news is by now there are many well tested frameworks that can be easily deployed to common web application frameworks. It’s important to understand that properly validating input is more complex than filtering a few ‘dangerous’ characters.”

4. Use a security-focused QA process

When testing new web applications, what do you check for? In most cases, testers looks for bugs in the interface and ensure the application does what it’s supposed to do. But, is that enough? As explained below, your QA process should also ask this question: Does the application do anything it’s not supposed to do?

“Businesses need to focus more on having a thorough and effective QA process that takes security into consideration rather than just checking to make sure the application does what it’s supposed to,” says Camejo. “From a security perspective we should be more concerned about whether or not an application can do things it’s not supposed to do rather than whether or not it does what it should. Vulnerabilities are simply the result of programmers making mistakes and, fortunately for QA, programmers tend to make the same kinds of mistakes over and over again regardless of what language or platform they’re using. For example, if you show me any application that interacts with a database I would bet that I could show you a SQL Injection vulnerability. QA teams should be looking for these common types of vulnerabilities and, helpfully, the Open Web Application Security Program (OWASP) has compiled a Top Ten list that they update periodically. If a business can test for and eliminate these vulnerabilities before code is published they’re ahead of the game.”

5. Don’t rely entirely on tools for security testing

One interesting note about the now infamous Target Breach: The malware used to steal data was completely undetectable to security products. Many companies make the same mistake. They put security tools in place, and assume they don’t need hands-on testing.

“Many of the worst vulnerabilities are difficult or impossible to detect via automated scans alone,” says Camejo. “Tools have their place but should not completely replace hands-on testing. An example of a nasty vulnerability that a tool wouldn’t detect is what OWASP calls an “Insecure Direct Object Reference”; this is where an application provide some sort of pointer to a record in a database, such as an account number. As an attacker I could potentially change my account number to someone else’s and if the application isn’t checking for authorization I would be able to access another user’s account. Tools generally don’t have the logic capabilities to realize that this is a problem; they don’t know if “User ABC” should be able to access “Account 421” or not.”

6. Don’t collect too much information

What’s the best way to protect confidential user data from a security breach? Don’t collect it in the first place. Now, I realize that you must collect some user data, but many companies make the mistake of collecting too much. As explained below, this mistake only increases your risk.

“Another thing developers also tend to forget is that the easiest way to secure customer information is to not collect it in the first place,” says Ken Westin, security researcher and mobile privacy advocate at Tripwire. “In a world where it seems like we collect everything we possibly can, it’s a good idea to sit back and identify the information you really need from the customer. Every bit of additional information you collect increases the risk exposure for both you and the customer.”

7. Offload sensitive security tasks

Going one step further–what happens if your applications must collect sensitive data (like payment information) from customers? As explained below, offloading these tasks not only reduces your risks–as you don’t collect their credit card information–it simplifies your job.

“If you collect payments from customers it is better to offload this to a secure payment processor who specializes in securing and managing transactions,” says Westin. “This not only helps you protect your customers’ information, but offloads a great deal of development work and liability.”

8. Make security part of the business

Shortly after the Healthcare.gov website went public, a “white hat” hacker discovered that security was never properly built into the site. It was composed of multiple insecure pieces that left user data wide open to attackers.

Now, while most businesses aren’t creating applications on this scale, it brings up an important point. Security should never be an afterthought. It can’t be something that’s added after the application is built. It should be a critical component of the entire development process, as well as the business as a whole.

“When it comes to any aspect of security in organizations, it comes down to including security as part of the business,” says Jimmy Vo, Security Consultant at VioPoint. “In other words making security a business requirement. Security requirements need to be explicit and validated during quality assurance or even User Acceptance Testing. For example, a security requirement would be interoperability with two-factor authentication. Organizations simply cannot have security requirements that are vague and unmeasurable. In addition, security requirements must have equal importance as functional requirements.”

9. Don’t do it all yourself/re-invent the wheel

Some developers make the disastrous mistake of creating their own algorithms–assuming they can make something better than the readily available open source options. Why is this such a bad idea? As the famous security specialist, Bruce Schneier, says: “Anyone can invent an encryption algorithm they themselves can’t break; it’s much harder to invent one that no one else can break.”

“While Open Source may be getting some knocks for letting innocent bugs slip through to widespread production (e.g. Heartbleed) it almost certainly gets more review than your custom code hidden behind your firewall,” says John Locke, Principal at Freelock. “Open Source software that reaches widespread use gets widespread attention, and this almost always translates to code that gets tested and hardened to a much greater degree than most proprietary software. Don’t try to do security yourself in a vacuum. People doing this end up releasing code that can be easily compromised. At a minimum, use libraries for your platform that are in widespread use and have undergone security reviews.”

10. Use the principle of least privilege

Oftentimes, a business worries so much about outside attackers, they completely forget about inside risks. Namely, uneducated users with too many privileges. An uninformed user can potentially cause just as much (if not more) damage as a hacker if given free reign over a system.

“If an application is protected by login, each user should have a role in the system that defines what they are allowed to do, and more importantly what they are not allowed to do,” says Mark Huss, Senior Consultant with SystemExperts. “Each user should only have sufficient privileges to perform tasks they need to do – and no more. This principle is called least privilege, and is very important to embrace in order to keep your application and infrastructure secure. At minimum, a normal role and a supervisor or administrator role should be defined and enforced, so that normal users cannot accidentally or intentionally view, change or delete data they should not have access to.”

So, what do you think? Is there anything you would add to this list? If so, please share your thoughts in the comments.