Part 2: How secure are you in 2022?

We teach you how to secure your web apps and sites, once and for all.

In our last security blog, we introduced you to the OWASP Top 10 - a list of the most common threats and risks to websites and apps in 2022. Open source community members and cybersecurity experts alike consider this list to be the most serious and critical web security risks to worry about, and we’re breaking them down one by one. We know it seems like there are endless things to be concerned about when it comes to site and app security, so hopefully, this series of articles will help you decide which vulnerabilities are the most critical to your website or web app. 

The OWASP Top 10 are presented in order of severity and likelihood, and in our last security blog, we explored risks number 10, 9, and 8: Server Side Request Forgery, Security Logging, and Monitoring Failures, and Software and Data Integrity Failures.

Today, we continue with OWASP threats number 7, 6, and 5. 

7. Identification and Authentication Failures 

This category was previously referred to as “Broken Authentication,” sliding down from #2 in 2021. It has since been expanded to include Common Weakness Enumerations (CWEs) which are more related to identification failures. So how does a risk category move down from number 2 on the list to number 7, you ask? That seems like kind of a big jump, but the increased availability of standardized Identity and Authentication Management (IAM) frameworks seems to be helping to prevent these failures from occurring, which is good news for everyone using one. Verification of an entity’s identity is crucial to prevent attacks related to authentication, as you are surely aware. Many organizations struggle with weaknesses in their applications that leave them more vulnerable to these types of attacks, like: 

• Credential stuffing, an attack where a malicious actor uses passwords found from breaches of other sites in an attempt to gain access to your resources if a user managed to reuse the same password across multiple sites 
• Weak and/or easily guessable passwords, leading to easy brute force attacks 
• Insecure password recovery techniques 
• Failure to utilize Multi-Factor Authentication (MFA) wherever possible
• Improper validation of session IDs and failure to automatically log out users after a period of inactivity

This is a big concern for you if: Your organization runs any type of services that require authentication prior to access (ie: services which are not public).

How to protect yourself now: 

Whenever possible, it’s best to use MFA to prevent credential stuffing and the use of stolen credentials. MFA makes it significantly more difficult for attackers to force their way in, but it is not a panacea; weak MFA methods like text messaging and voice calls are still themselves vulnerable to SIM swapping attacks, vishing, and smishing. It may also be wise to check for weak passwords, because, shockingly, some of the most predictable passwords are also the most common (here’s looking at you, “hunter2”). 

Set stringent standards for passwords you’ll accept to make sure they’re secure. You can reference the federal guidelines on password length and complexity in NIST Special Publication 800-63B if you need help setting a reasonable standard for your organization. In addition to setting a strong password policy, enforcing user lock-outs after a specific number of failed login attempts can prove exceptionally useful, as this greatly aids in the prevention of any brute-force attempts. 

We also highly recommend logging all failures and setting up an alerting pipeline for these failures so your admins can take appropriate and timely action. Last but not least, make sure that your site or app signs users out after a certain amount of inactivity and sets session cookie expiration times correctly (no more than 30 minutes). This way, attackers can’t slip in undetected simply because someone didn’t log out. 

6. Vulnerable and Outdated Components 

Vulnerable Components are considered known issues that are challenging to test and assess risk for. This is the only category not to have any Common Vulnerability and Exposures (CVEs) connected to CWEs. Many organizations can be vulnerable to this risk if they aren’t aware of all the versions of components they use on both the client and server sides. This definition of “components” unfortunately includes all languages, modules, packages, libraries, and environments you (and your users) actually use, along with their various interconnected dependencies. 

The bottom line is this: You need to be scanning for vulnerabilities regularly so you can identify them. You need to be fixing and upgrading your underlying platform and systems. Additionally, you need to be testing the compatibility of patched, updated, or upgraded libraries, and you need to be securing your component configurations.  If you aren’t doing these things regularly or within the recommended time frame, then you are increasing your risk. 

This is a big concern for you if: Supply side attacks and outdated/vulnerable dependencies affect everyone on the Internet today; users and providers alike. Ensuring that systems and components are up to date is critically important for everyone.

How to protect yourself now: 

Two words: Patch management. 

It’s best to remove any unused dependencies from your systems to remove any potentially vulnerable areas. We also highly recommend performing a thorough inventory of your client and server-side assets, like frameworks, libraries, and every single one of their dependencies. Identifying vulnerabilities within individual components is also critical, and you can utilize container scanning software like Syft to create a Software Bill Of Materials (SBOM). 

The bottom line is that you need to be aware of any security vulnerabilities in the components you use so you can monitor and catch them before anything bad happens. It’s far easier to prevent an attack than to deal with the fallout of a breach, so keep that in mind when checking off all those little boxes starts feeling tedious. 

Ask yourself this: Does your organization currently have a thorough plan in place for monitoring and applying updates to your apps? If the answer is no, that needs to change - today. Vulnerabilities could be slipping through the cracks and you’d never know it. Be aware and monitor proactively. 

5. Security Misconfiguration 

This category has moved up a place this year, previously occupying the number 6 spot on the OWASP top 10 list. Why? Because 90% of applications were tested for any form of misconfiguration, and the average incidence rate was 4%. More than 200k instances of Common Weak Enumeration (CWE) occurred in this category. Although these numbers are technically on the lower side, that’s still simply too high for comfort. As the modern technological world moves toward more highly-configurable software, this type of vulnerability and attack are becoming more common - hence the bump up the list.

Your application is considered vulnerable if you’re missing any piece of the security hardening puzzle across your stack, or if your permissions aren’t configured correctly on cloud services. Ask yourself whether or not all the features you’re utilizing are strictly necessary. If not, it may be best to remove some of them to minimize opportunities for vulnerabilities.. 

Here are some other ways to know if this risk applies to you: 

• Default accounts and their passwords remain the same 
• Error messages might accidentally reveal sensitive information to users
• Your latest security features are disabled or not configured properly 
• Your security settings for application servers, frameworks, libraries, and databases are not secure 
• Your software is out of date or vulnerable 
• You lack a repeatable, consistent security configuration process

This is a big concern for you if: Though legacy systems are at a somewhat greater risk for a Security Misconfiguration due to the nature of such services to only receive limited additional development and/or package/module updates, a Security Misconfiguration can affect practically any system or service.

How to protect yourself now: 

Now is the time to either implement or strengthen security installation processes, like:

• A repeatable, predictable hardening process that can be used any time you want to deploy an environment that needs to be locked down. We recommend automation here to minimize the time it takes to secure environments. 
• Remove unnecessary or unused features, services, and components. The fewer things you’re using, the less you have to secure. 
• Keep configurations up to date for all security notes, updates, and patch management tasks.
• Automated processes to make sure your configurations and settings are all updated in every environment.

An application delivery platform designed for enterprise-grade security 

The best and easiest way to protect yourself from the OWASP top 10 security risks? We’ll tell you: A trusted application delivery partner that takes your own unique situation into account every day. amazee.io’s team helps provide this peace of mind for you and your team: Our security offering includes monitoring, logging, reporting, and alerting. Our infrastructure is incredibly secure, based on decades of experience and expertise. 

The amazee.io platform offers enterprise-grade security from day one, and one of our greatest assets is our container-based infrastructure. Containerized hosting can provide the most secure environment for your applications to run, while also providing substantial cost savings. Our platform has an automated system that alerts us immediately to any issues with your sites and apps, but more than that, we focus very heavily on proactivity so we’re never surprised by any new issues that pop up.

To learn more about how we can help your team by handling all your security needs, schedule a free 15-minute consultation with us today. Our security experts are happy to chat with you about how we keep our infrastructure totally secure.