OWASP Top 10 cheat sheet for startup CTOs

In recent times, hacks seem to be increasingly prevalent , not to mention severe.

What’s more, it doesn’t matter whether you’re a small player or a big name corporation such as LinkedIn or Yahoo!

If you develop web-based applications, there’s the strong possibility that your application is vulnerable to attack.

Not sure why someone might attack your application?

Attacks can have wide-ranging motivations; from something as simple as getting a product or service for free, to corporate espionage and industrial-scale blackmail.

Attackers can be seeking to acquire greater security access, steal some, or all, of your users’ access credentials or financial details.

They may be looking for compromising information, or to steal trade secrets.

Regardless of motivation, what’s important is that your application may be vulnerable.

So, in this post, I want to help you be better prepared.

To do that, I’ll first step you through the anatomy of an application vulnerability, so that you know what can go wrong.

Then, I’m going to step you through several ways in which you can reduce your application’s vulnerability.

In doing so, we’ll also reduce your application’s level of vulnerability.

What Is An Application Vulnerability?

An application vulnerability is a weakness that can be exploited to compromise an application. These attacks target the confidentiality, integrity, or availability (known as the “CIA triad”) of an application, its developers, and users.

There are a large number of web application weaknesses. But, the best source to turn to is the OWASP Top 10 .

1. Injection

The first vulnerability relates to trusting user input.

A typical attack from unverified data is an SQL Injection attacks against your database.

If successful, this can lead to discovery and leakage of store information, the ability to change sensitive data, or to side-step authentication measures.

Data can come from form submissions through your web-based forms and API requests.

It can also come from internal users.

Regardless, if the data come from anywhere outside of your application, it can never be trusted.

There are several ways to mitigate this kind of attack.

Survive The Deep End: php Security recommends the following :

Always perform data filtering and validation Escape data Use parameterised queries Enforce the Principle of Least Privilege 2. Broken Authentication and Session Management

The second vulnerability covers the ability of users to manipulate, or workaround authentication mechanisms and sessions within an application.

For example, is a user able to log in at one privilege level, yet elevate their privileges above and beyond what they should have?

OWASP lists several ways in which this attack can happen, including:

User authentication credentials aren’t protected when stored using hashing or encryption. Credentials can be guessed or overwritten through weak account management functions Session IDs are exposed in the URL Session IDs are vulnerable to session fixation attacks. Session IDs don’t timeout or aren’t rotated after successful login Passwords, session IDs, and other credentials are sent over unencrypted connections

To mitigate this kind of attack:

Implement strong password policies and storage mechanisms Ensure that sessions, regardless of language: Timeout Are not able to be fixated Are rotated Use secure connections 3. Cross-Site Scripting (XSS)

This vulnerability occurs at the browser-level when user data is rendered without being escaped or validated.

This type of attack often results in:

Hijacked sessions Defaced websites Users redirected to unintended destinations

To prevent this type of attack, again, remember the golden rule:

Nevertrust data from outside your application

With that in mind, Sitepoint recommends three key ways to prevent XSS attacks :

Data validation Data sanitization Output escaping 4. Insecure Direct Object References

This vulnerability occurs when the way that data is referenced within an application, such as in a query parameter, directly relates to the underlying data.

For example: fields in the database are used as query parameters or form field names.

To prevent this kind of attack, don’t directly reference an underlying object or resource.

One of the simplest ways is to map what the user sees and can request, to the information which the application requires to access the requested resource.

Then, once a user has requested a given resource, be that a file on the filesystem, or a record in a database, have validation in place to ensure that they should be allowed to access it.

This might be filtering records before or after they’ve been requested from a database or blocking access to requested file.

5. Security Misconfiguration

This vulnerability occurs when configurations have not been security hardened.

This can include:

Using outdated or insecure configurations of PHP and Ruby Not protecting files and directories from being served by a web server Not removing default or guest accounts in a database Leaving unnecessary operating system ports open Using outdated software libraries

To protect against this kind of attack, for every part of your application, be that a server, language runtime, or operating system, ensure that it is suitably hardened, based on recommended best practices.

If it is an external service, refer to their documentation and other material to ensure that they provide a hardened service and stay up to date.

6. Sensitive Data Exposure

This vulnerability relates to any access to information by anyone who shouldn’t have access to it.

This includes data rendered in a browser or API response, data in logs and regular backups, and data sent between the client and the server.

OWASP has five excellent recommendations for protecting against this kind of attack:

Make sure you encrypt all sensitive data at rest and in transit Don’t store sensitive data unnecessarily Ensure strong standard algorithms and strong keys are used, and proper key management is in place Ensure passwords are stored with an algorithm specifically designed for password protection, such as bcrypt , PBKDF2 , or scrypt Disable autocomplete on forms collecting sensitive data and disable caching for pages that contain sensitive data 7. Missing Function Level Access Control

Related to vulnerability number 2, this vulnerability covers the ability of users to access application functionality which they shouldn’t be able to.

For example, a user can alter an URL to gain access to other functionality.

To protect against this type of attack, ensure that applications have a strong access control mechanism in place.

Across most languages, there are mature implementations of Role-based access control (RBAC) and Access Control Lists (ACL) .

Make use of the one for your language, mapped out according to the needs of your application.

8. Cross Site Request Forgery (CSRF)

Borrowing from Coding Horror , This vulnerability :

…occurs when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action. The key to understanding CSRF attacks is to recognize that websites typically don’t verify that a request came from an authorized user. Instead, they verify only that the request came from the browser of an authorized user.

To protect against this type of vulnerability, the article strongly recommends ensuring that all form submissions contain a field with “a (cryptographically strong) pseudorandom value.”

Then, the minimum requirement before a submission can be considered valid is that the pseudo-random value is validated as being correct.

A working example of this is Zend Framework’s Csrf form field .

9. Using Components with Known Vulnerabilities

This vulnerability , as the name says, is where one or more components upon which an application depends, has a known vulnerability.

This can include a third-party software library, a version of the web server or even in the operating system itself.

To protect against this kind of vulnerability:

Always ensure that the components which you use are the most recent available Implement a security scanner which looks for known issues in your application and its related components 10. Unvalidated Redirects and Forwards

This vulnerability involves users being tricked into making requests and in the process being either redirected or forwarded to somewhere else.

To protect against this vulnerability, OWASP recommends:

Avoiding using redirects and forwards If they’re used, don’t involve user parameters in calculating the destination If parameters are required, ensure that the supplied value is valid, and authorized for the user In Conclusion

That concludes our discussion on the OWASP top 10 vulnerabilities and how CTOs can protect their applications against each of them.

If this is your first time considering application vulnerability, it’s just the beginning of your journey.

However, you now have a good understanding of what makes an application vulnerable, as well as how to create ones which are more secure.

Moreover, like any other skill, security takes time to master.

What’s more, given that the internet’s protocols were never designed with security in mind, security needs to be as fundamental to your applications as testing.

However, by doing so, the possibility of your applications suffering a security breach is greatly reduced.

Shameless plug: Check outSqreenif you don’t have time to protect your application against each individual OWASP top 10 vulnerability. Get real-time security monitoring and protection for your apps.

About the Author

Matthew Setter is an independent software developer and technical writer . He specializes in creating test-driven applications and writing about modern software practices, including continuous development, testing, and security.