Keep Your Site Safe with the OWASP Top 10 List
Learn How the OWASP Top 10 Can Help Protect You from the Most Dangerous Security Threats
Web security is an ever-changing field, and the threats never end. If one threat is stopped, it’s only a matter of time until another takes its place. For developers of web applications and sites, the target is always moving as far as what you need to protect against. Whether you’re creating your next big idea or are working to maintain your existing product or business, you’ll certainly want to keep the fruits of your labor protected.
But with the sheer number of threats lurking in cyberspace, how do you know which are the most critical and most common? Wouldn’t it be nice if there was a simple list out there that laid them all out for you? Well, today’s your lucky day. That’s because the Open Web Application Security Project (OWASP) has created just that, the OWASP Top 10 list of the biggest threats facing your website.
Updated every few years, the list is a widely accepted industry document that is a must-read for anyone running a website. Without it you could be leaving yourself exposed to the most dangerous vulnerabilities, rather than mitigating the risks during development and deployment.
What are the top 10 vulnerabilities and how can you properly protect yourself against them? And what is your best course of action if you fall victim to one of them?
Let’s hash it out.
What is OWASP?
Before we get to the OWASP Top 10, let’s talk about OWASP themselves. The OWASP foundation was founded on December 1, 2001, and they were incorporated as a non-profit organization in the United States on April 21, 2004. In the nearly two decades since their launch, they’ve grown to consist of nearly 32,000 volunteers worldwide. They’re a well-recognized and trusted name in the industry, with over 275 local chapters around the globe.
OWASP’s mission since launch has been to improve the security of software. They use an “open community” model, which means that anyone can contribute to their projects, events, webinars, and more. They provide materials and information free of charge, which can be accessed via their website. They produce a wide array of media, including videos, software tools, forums, live and virtual events, and learning resources.
Basically, OWASP is a repository for anything related to web application security, powered by the diverse knowledge and experience of their open community membership. The group is committed to helping organizations create, develop, deploy, operate, and maintain websites and applications that are safe. In addition to providing an array of articles, methodologies, documentation, and technologies, OWASP’s membership also performs security assessments and research.
What they’re best known for, however, is the OWASP Top 10 list.
What is the OWASP Top 10?
The OWASP Top 10 list outlines security concerns for websites and web applications. It was first published in 2003 and is usually revised every three to four years as the AppSec market changes and evolves. The list has seen updates in 2004, 2007, 2010, 2013, 2017.
The focus of the OWASP Top 10 list is on the most critical vulnerabilities, examining their risks, impacts, and the best countermeasures to combat them. Compiled by a team of security experts from around the world, the list aims to create awareness of the biggest threats facing organizations. OWASP recommends that all companies incorporate the findings of the report into their security processes and practices so they can minimize the presence of these vulnerabilities in their products.
As for the vulnerabilities themselves, they are judged based on four different criteria:
- Prevalence – how well known is this vulnerability to threat agents (eg. hackers)?
- Detectability – how easy is it for threat agents to discover the vulnerability within an application?
- Ease of exploitation – how easy is it for threat agents to actually exploit the vulnerability once they’ve found it?
- Business impact – how severely will the company operating the application be affected by the exploitation?
When the list was originally created, vulnerabilities were grouped by type so that the authors could cover the most ground. However, that made it more difficult for readers to determine which vulnerabilities were actually the highest priorities since there weren’t any statistics included to quantify them. It thus became a subjective task for the audience since there’s wide variation in application types and threat models depending on the organization. Ultimately, after much debate, OWASP decided to offer a more straightforward top 10 list that they believed was relevant to the widest set of companies (although it’s important to note that the entries are in no particular order).
The Importance of the OWASP Top 10
The most useful aspect of the OWASP Top 10 list lies in the actionable information given within, which helps company focus their security efforts on the most important and effective areas. This has led to the list being adopted as a standard requirement by many of the world’s largest companies (including the PCI-DSS payment processing standards). The failure of an organization to address the items within the OWASP Top 10 is a strong indicator to auditors that they are falling short when it comes to compliance standards.
Web application attacks have become the most common cause of confirmed data breaches, per the 2018 Verizon Data Breach Investigations Report. Unfortunately, many organizations still struggle when it comes to creating and maintaining an effective application security program because they just don’t know where to begin. The OWASP Top 10 list can help fill that void, acting as a great starting point since it covers the vulnerabilities that are the most likely to be exploited (and potentially creating data breaches that will be very unpleasant for both your business and customers). By remediating them, you’ll greatly decrease your risk of a costly breach.
And research shows that sort of action is desperately needed. As you can see below, the passing rate of applications when it comes to OWASP Top 10 policy is still alarmingly low. Perhaps even more worrying is the fact that there is only a slight increase in compliance after an initial OWASP Top 10 vulnerability scan occurs, indicating that most companies aren’t taking the scan results seriously.
Most of the items on the OWASP Top 10 list aren’t super complicated to find and fix, but a disconnect often occurs within organizations because developers are often not well trained in cybersecurity or secure coding practices. Conversely, security teams don’t always have the most accurate idea of what application security actually entails. A one-time scan or pen test of a few critical apps is just not good enough. There must be continuous assessments in place of everything an organization develops or buys, and it must occur in all stages of the lifecycle for it to be effective. Running scans to cover the OWASP Top 10 list is important, but it’s not a magic bullet either. It needs to be an element of a greater company-wide security strategy.
Now that we’ve covered what the list is and how it should be used, let’s take a closer look at those pesky vulnerabilities!
The OWASP Top 10 Vulnerabilities
#1 – Injection
What is it?
Injection attacks can happen on things such as databases (SQL, noSQL), operating systems, or servers (via protocols like LDAP). They occur when hostile data is sent to an interpreter as part of a query or command. This data then tricks the interpreter into executing commands that would otherwise be off-limits to an outsider. It can also be used to access private data without proper authentication.
Example
Say you run an ecommerce store, and the way to access a particular item is by entering the following into your browser’s address bar:
- http://www.yourstore.com/catalog/item.asp?itemid=999
Where “999” generates an SQL query to display whatever item “999” corresponds to. An attacker could manipulate this by entering something like this:
- http://www.yourstore.com/items/item.asp?itemid=999 or 1=1
The SQL query generated would be:
But since 1 always equals 1, every product name and description will be returned (even ones that the owner may not want you to see).
You could go a step further by entering:
- http://www.estore.com/items/iteam.asp?itemid=999; DROP TABLE
The SQL query would now be:
The end result? The deletion of your table!
How to Protect Yourself
- Validate and/or sanitize user-submitted data (validation rejects suspicious entries, and sanitization cleans up the suspicious parts of it)
- Set controls to minimize the amount of information that is exposed
- Use a safe API that avoids the use of an interpreter
- Use SQL controls like LIMIT and others to prevent mass disclosure of records
#2 – Broken Authentication
What is it?
Broken authentication refers to instances when authentication and session management functions are implemented incorrectly. Credentials like passwords, keys, or session tokens can be compromised, and flaws can also be used to assume the identities of other users. Attacks can even gain access to an admin account that could compromise the entire system.
Example
Credential stuffing is an example of a broken authentication attack. This is when attackers use lists of known passwords (like those obtained in data breaches) to try and gain access, with the application acting as a validation mechanism for each password attempt.
How to Protect Yourself
- Use multi-factor authentication
- Implement rate limiting to restrict the number of failed login attempts
- Don’t use system default credentials
- Choose passwords based on the NIST 800-63B section 5.1.1 standard
- Use a built-in server-side session manager
#3 – Sensitive Data Exposure
What is it?
Sensitive data exposure occurs when web applications and APIs fail to properly protect sensitive data like financial or healthcare information. This weakly protected data can be easily stolen by attackers to conduct fraud, identity theft, and other crimes.
Example
If a website doesn’t use SSL/TLS for all pages, then an attacker could monitor traffic, change connections from HTTPS to HTTP, and then steal the session cookie to gain access.
Another example is unsalted hashes. If simple hashes are used to store passwords and an attacker gains access to the database, the hashes can be easily cracked.
How to Protect Yourself
- Identify sensitive data and apply appropriate controls
- Encrypt all sensitive data, both in-transit and at rest
- Disable the caching of any sensitive information and do not unnecessarily store any of it
- Store passwords using strong, salted hashing functions such as scrypt, bcrypt, and Argon2
#4 – XML External Entities (XXE)
What is it?
This sort of attack targets web applications that parse XML inputs. Older or improperly configured XML processors can end up evaluating external entity references (such as a hard drive) in XML documents. This can fool the XML parser into sending data to an unauthorized external entity, which can then send sensitive data straight to a hacker.
Example
The following XML code can be used to pull data from a server:
But an attacker could get information about a private network by changing the ENTITY line to the following:
How to Protect Yourself
- Patch any old XML parsers
- Disable the use of external entities in XML applications
- Only allow web applications to accept less complex types of data (like JSON)
- Avoid serialization
- Validate XML using XSD or other validation tools
- Whitelist and sanitize server-side XML inputs
#5 – Broken Access Controls
What is it?
This is when restrictions on what authenticated users are permitted/not permitted to do are improperly enforced. Attacks can then take advantage to gain unauthorized functionality, including accessing and modifying user accounts, sensitive files, user data, access rights, and more.
Example
Say you have a web application that can accept SQL calls for account information without verification:
The “acct” parameter could then be changed to allow access to any account of their choosing:
How to Protect Yourself
- Deny access by default for everything but public resources
- Create strong access control mechanisms and use them everywhere
- Don’t allow users to create, read, or delete any record
- Disable server directory listing, and don’t store metadata in the folder root
- Log failed access attempts and create alerts
- Rate limit API access
#6 – Security Misconfiguration
What is it?
This is the most common vulnerability on the OWASP Top 10 list and is usually the result of using default configurations/credentials or displaying unnecessarily lengthy error messages. These messages can potentially reveal vulnerabilities within the application.
Example
One example would be a database deployed with the vendor-default user credentials. You can’t make it much easier for attackers by having a username of “admin” and a password of “password.”
Another example would be displaying an error message like the one below:
As you can see, details of the application code are revealed, which could be exploited by a nefarious third party. A much simpler error message in plain English would suffice.
How to Protect Yourself
- Remove any unused features in the code
- Only display general error messages that don’t reveal too much information
- Use a Static Application Security Testing (SAST) program to identify information exposure risks from error messages
#7 – Cross-Site Scripting (XSS)
What is it?
This type of vulnerability is ultimately a result of weak session management and occurs when web applications let users add custom code to a URL or site that will be displayed to others. A malicious JavaScript code can then be run on their browser.
Example
A hacker could email someone pretending to be from a trusted bank, including a link to the bank’s website within the email. The link, however, could have malicious code appended to the end of the URL. If the bank’s site isn’t properly secured, then the malicious code will be run in the victim’s browser after they click on it.
How to Protect Yourself
- Use a web application firewall (WAF), which will employ signature based filtering to identify and block requests from attackers
- Use frameworks that escape XSS by design and learn the limitations of their XSS protection so you can handle the cases that aren’t covered
- Apply context-sensitive encoding when performing client-side browser document modification
#8 – Insecure Deserialization
What is it?
Serialization is when objects from the application code are converted into a format that can be used for another purpose, like streaming it. Deserialization is the reverse, and it allows hackers to execute malicious code on a server. Even if the vulnerability doesn’t result in remote code execution, attackers can still use them to perform actions such as replay attacks, injection attacks, and privilege escalation attacks.
Example
An analogy would be when you’re moving. The serialization is when you pack up the boxes with all your possessions. Deserialization would be when you unpack it at your new place. Insecure deserialization would be if the movers added, removed, and re-arranged items before they were unpacked.
As for a real-world example, say a PHP forum uses serialization to save a cookie containing the user’s ID, password, and account level:
A hacker could change the serialized object to make themselves an admin:
How to Protect Yourself
- Monitor deserialization
- Implement type checks
- Prohibit the deserialization of data from untrusted sources
#9 – Using Components with Known Vulnerabilities
What is it?
Web developers often use existing components in the applications to avoid redundant work while providing needed functionality. Attackers will look for vulnerabilities within these components that they can leverage to perform attacks on the application itself. Popular components can be used on hundreds of thousands of sites, and a single vulnerability could leave all of them at risk.
Example
The Equifax breach in 2017 is the perfect example of this type of vulnerability. It was caused by using an Apache Struts version that had an existing vulnerability that was discovered six months before the attack. If only they had read the OWASP Top 10 list first, that could’ve saved them $700 million!
How to Protect Yourself
- Always make sure to have the latest security patches and updates for your components
- Remove unused components from your project
- Only get components from trusted sources
- Use software composition analysis (SCA) tools to identify outdated or insecure components
#10 – Insufficient Logging & Monitoring
What is it?
Logging and monitoring should be performed routinely to help ensure a website is secure. Failure to do so increases the risk that attacks can occur and can hinder your response time when they do. The average discovery time for a breach is roughly 200 days. This in turn gives attackers quite a bit of time to tamper, extract, or destroy data, move on to other systems, and generally run amok.
Example
We talked earlier about credential stuffing, where attackers repeatedly attempt to use leaked username and password pairs. Let’s say after 100 attempts, they finally hit the correct combination for a particular account. Since there was no logging or monitoring in place, no one was ever alerted about the alarmingly high number of login attempts on the account. Otherwise, the activity would’ve been noted as suspicious and the breach could’ve been easily prevented.
How to Protect Yourself
- Implement logging and monitoring for all aspects of your web application
- Create an incident response plan that includes alerts so you are immediately aware of any attacks
- Make sure your logs are in a format that can be easily used by centralized log management solutions
- Set up your logs so that they contain sufficient context to identify the suspicious accounts
Coding Against the OWASP Top 10
First off, your team needs to fully understand the vulnerabilities on the OWASP Top 10 list and avoid coding tools and techniques that could leave you exposed. Coding frameworks that enable developers to find and fix vulnerabilities as they code are your best bet.
The best coding practices and tools can’t always protect from human error though, so it’s always good to have extra measures in place such as automated website protection with a WAF. It should ideally be part of a mix of technologies and services at the application layer, which should also include dynamic and static analysis. Static analysis is performed in a non-runtime environment, looking at the application from the inside-out via source code. Dynamic analysis is the opposite and involves manipulating the application during run-time in an effort to locate vulnerabilities.
After you have the right coding practices, tools, and security software in place, it all comes down to organizational best practices.
Organizational Strategy to Protect Against the OWASP Top 10
Many companies still employ aspects of waterfall development methodology, which leads to the pitfall of waiting until the end of the cycle to perform security checks. This often results in a long list of vulnerabilities being presented to the dev team at the last minute. Time is needed to fix them, which delays releases, creates friction between the dev and security teams, and hurts the business’s bottom line.
In response to this, many companies have looked for ways to keep their code secure every step of the way, starting from the very beginning (and not only do they want to prevent cyberattacks, they also want to prevent the security and dev teams from literally attacking each other). A popular and effective method of accomplishing this is by including security staff in the earlier stages of product development. This sort of cross-pollination lets both sides give their input and learn from the other. Issues with the OWASP Top 10, for example, can be brought up in a lower-stress period where the stakes aren’t as high as they are right before release.
What to Do if an OWASP Top 10 Vulnerability is Exploited?
All the protection measures and strategies we’ve discussed sound great in theory, but they’re not always the easiest thing to achieve in practice. Security incidents can of course still occur no matter how careful you think you’re being. So, what do you do then if a breach does occur? Time is money, and you’ll be losing both for every second your site is down. Not to mention the negative effect any sort of outage can have on customer trust.
One of your best bets to get back up and running as fast as you can, with as little impact as possible, is to be using a website backup service. Having a backup of your website handy allows you to simply undo any hacks, crashes, malware infections, bad updates, etc.
Automatic backups are best, as its easy to forget to perform manual ones. You’ll also want a service that’s not on your side of the fence. If a hacker gets into your system, there’s a good chance they’ll be able to simply delete your local backups as well. Web hosts often offer backup services, but their functionality is often clunky and limited because it’s focused on server-level backups, not website-level backups. You have to submit a ticket, wait for them to respond, and you can’t select from specific dates or files.
Sectigo’s CodeGuard is an example of a website backup solution that ticks all of the above boxes. It tracks all of your website changes and automatically backs up your site’s files and databases every day, as seen below:
Then, if something does happen, it’s literally a one-click restore process. All you have to do is login and select your latest backup (or whichever you want to use), and you’re back up and running instantly.
The other nice thing about a service like CodeGuard is that it isn’t simply just a backup program. You also get:
- MalwareGone scanning, which automatically detects and removes malware before it becomes a problem
- Email backup service
- WordPress plugin for creating automatic backups of WordPress sites
- Website Migration Tool to quickly and easily move your site
- Staging servers to test old backups
- Full-Featured API to customize the CodeGuard experience for you or your customers
It works with any major website platform and its easy-to-use interface lets you configure it all in less than 5 minutes. First, you set the root directory of your site (or if you’re using the WordPress plugin, you simply install it and enter a one-time key):
Then, you set your backup preferences:
And CodeGuard does the rest. Then, if you need to restore later on, it’s a fast and straightforward process:
Within seconds, your website will be back to it’s previous state.
Protect Your Site With CodeGuard Backup
It’s like an undo button to reverse damage done by a mistake, cyber attack, a bad update, or other issues.
The OWASP Top 10 – A Valuable Tool in Your Security Arsenal
As we’ve seen, the OWASP Top 10 acts as an excellent baseline for your security measures. Protecting against the items on the OWASP Top 10 should be the bare minimum really, and ideally the first step to a more comprehensive security framework for your company. By protecting yourself against the most common vulnerabilities, you’re drastically and immediately lowering your risk.
Then, combine that with proper AppSec and organizational best practices to set yourself up for the long term. No matter where you’re at in the process though, breaches are always possibility. You’ll want to have a contingency plan in place, such as CodeGuard, that will get you back online as soon as possible. Like a security system for your house, it’s the sort of thing you hope will never be called in to use. But if it is, you’ll be very glad you had it!
5 Ways to Determine if a Website is Fake, Fraudulent, or a Scam – 2018
in Hashing Out Cyber SecurityHow to Fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chrome
in Everything EncryptionRe-Hashed: How to Fix SSL Connection Errors on Android Phones
in Everything EncryptionCloud Security: 5 Serious Emerging Cloud Computing Threats to Avoid
in ssl certificatesThis is what happens when your SSL certificate expires
in Everything EncryptionRe-Hashed: Troubleshoot Firefox’s “Performing TLS Handshake” Message
in Hashing Out Cyber SecurityReport it Right: AMCA got hacked – Not Quest and LabCorp
in Hashing Out Cyber SecurityRe-Hashed: How to clear HSTS settings in Chrome and Firefox
in Everything EncryptionRe-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithms
in Everything EncryptionThe Difference Between Root Certificates and Intermediate Certificates
in Everything EncryptionThe difference between Encryption, Hashing and Salting
in Everything EncryptionRe-Hashed: How To Disable Firefox Insecure Password Warnings
in Hashing Out Cyber SecurityCipher Suites: Ciphers, Algorithms and Negotiating Security Settings
in Everything EncryptionThe Ultimate Hacker Movies List for December 2020
in Hashing Out Cyber Security Monthly DigestAnatomy of a Scam: Work from home for Amazon
in Hashing Out Cyber SecurityThe Top 9 Cyber Security Threats That Will Ruin Your Day
in Hashing Out Cyber SecurityHow strong is 256-bit Encryption?
in Everything EncryptionRe-Hashed: How to Trust Manually Installed Root Certificates in iOS 10.3
in Everything EncryptionHow to View SSL Certificate Details in Chrome 56
in Industry LowdownA Call To Let’s Encrypt: Stop Issuing “PayPal” Certificates
in Industry Lowdown