Micro Focus is now part of OpenText. Learn more >

You are here

You are here

The 3 deadly sins of insecure programming

public://pictures/erez_yalon_headshot.jpeg
Erez Yalon Head of Security Research, Checkmarx
 

Over time, experienced security professionals see the same programming mistakes occur over and over again. In application security, these are usually found either in the design of the software or in the way that this design is implemented—in how the code is written.

In either scenario, these mistakes result in risky software vulnerabilities that allow malicious users to take advantage of the program and abuse it.

In fact, by 2018, nearly 70% of businesses had experienced some form of cybersecurity attack, according to the Ponemon Institute, and over half of them had experienced a data breach. That's why it's important to generate greater awareness around these common, insecure practices, the "three deadly sins of programming." The goal is to take a preventative, proactive approach to more secure software throughout the entire SDLC (software development lifecycle).

Because DevOps environments create demanding timelines, it's tempting to take the easy way out when it comes to security in order to relieve pressure. Unfortunately, this "sinful" approach to security will only set organizations up for failure.

Here are the three deadly sins every dev team should watch out for.

1. Client-side validation

Client-side validation, as the name suggests, is controlled by the client or end user. You can perform input validation on the client side for user experience purposes—for example, making sure an email or phone number is in the right format. But this exercise cannot be used for security validation of the input—say, making sure the email field does not hold a malicious payload.

But trusting users' client-side validated input in security-related decisions is the equivalent of a security guard asking a person, "Are you supposed to be here?"and taking their word for it. Relying on client-side validation for authentication/authorization and ignoring malicious payloads are critical mistakes, since they can be easily bypassed by a user.

Even when the input choices seem limited, as in the case of a dropdown with a set of values, or when the web page sends a parameter that is not presented clearly to users, these can all be easily manipulated and changed by a malicious user.

Not taking client-side validation into consideration when designing and implementing an application creates an opportunity for catastrophic consequences.

[ Also see Chris Romeo: How to do app sec on a budget ]

2. Reinventing the wheel

Sometimes security is simple, while at other times it's complex. The problematic cases are those that seem simple but are not trivial at all. The need to secure a random number/string, encrypt data, or sanitize user input can be the difference between a safe application and one that is vulnerable to attacks.

Believing that your freshly invented solution is better than existing, mature, and well-vetted solutions will almost always result in developers creating substandard cryptography and sanitization methods, leaving your application completely exposed

3. Security by obscurity

The origin of this sin is in believing that if you hide something well enough, it won't be found, and if you obfuscate something well enough, it won't be unraveled. This is simply untrue, and it puts your software in grave danger.

Hiding something and securing it are not equivalent. While adding obscurity as a layer of security is acceptable, implementing security solely through obscurity is not. Relying on an attacker not knowing something such as the address of an important server or the logic flow of a system does not mean it cannot be found or that it is secure.

[ Also see: 5 best practices from the app sec front lines ]

There's no forgiving these sins

While easily overlooked, these three deadly sins of programming must be overcome. Cybersecurity threats will only continue to grow in frequency while their costs increase. The average cost of a data breach has risen to $3.86 million, with the cost of each data record breached weighing in at $148.

The key to successful application security is to think about it from the very beginning. Whether it's the programmer's first few strings of code or an update to the overall security policies within your organization, it should all uphold the same standards and protect the end users who trust that their data is being safeguarded.

Keep learning

Read more articles about: SecurityApplication Security