Which website security risks do you really need to worry about in 2022?

How to truly secure your website or applications, once and for all. 

With all the different threats out there, securing a website in this day and age is certainly a difficult task. It sounds a little scary, and the truth is - it can be. That’s why we’re here to break down the top ten most common security threats for you: What they are, why they matter, and which risks your team *actually* needs to be concerned about on a daily basis and why. 

The Open Web Application Security Project (OWASP) is a non-profit foundation that helps improve software security across the entire internet by publishing a list of the most common threats to websites, known as the OWASP Top 10. 

In true open source spirit, OWASP operates under a free contribution model, so everyone can participate in community conversations and reporting. The OWASP Top 10 are considered by the open source community and cybersecurity experts alike to be the most serious, critical, and imminent web application security risks to be concerned about, and are regularly updated every three years.

How are they determined?

Because OWASP has a large open source community of contributors and experts, they are able to leverage this worldwide expertise to compile the list based on real-world reports, conversations within the community, and decisions made by security experts globally.

These risks are presented in the order of both exploitability (how easy a weakness is to be exploited) and the gravity of their potential impact on an organization, website, or app. The OWASP Top 10 list is compiled in an effort to help security teams everywhere improve their own safety and security practices, and techniques, and place their focus on the most urgent and imminent risks.

Ultimately, the goal of the OWASP Top 10 is to help teams protect their own sites, apps, and software in the most efficient way possible. Technically, there are *hundreds of thousands* of security risks known to sites and applications in 2022, but it would not be feasible to strategically plan for every single one.

Instead, it’s best to focus on the risks that are most likely to impact your site and your business. 

The OWASP Top 10 list gives security teams a tangible, real-world view of the security issues that are most likely to happen to their sites, apps, and software. The list doesn’t always remain the same, either, for obvious reasons - it changes frequently based on real risks and new trends in the cyber world. The OWASP Top 10 list was last updated in 2021, with three new categories added to the list and additional details about pre-existing threats further fleshed out.

Are all 10 categories considered serious risks for my organization? 

The OWASP Top 10 risks are all very serious risks. The reason these specific risks have been selected for the top 10 list is that they are serious enough, happening frequently enough, and have negative enough consequences to be worth preventing. But they’re not necessarily all very serious threats to your organization - some might rank higher than others for your organization, which depends on a multitude of factors. It is always important to be aware of your own organization’s known vulnerabilities and risk appetite. 

Your organization may be more vulnerable to certain categories of risk than others. This entirely depends on the controls in place and the risk landscape surrounding your organization; organizations dealing with medical patient information, for instance, would have a very different landscape of risks than an organization dealing solely with corporate financial data. 

Despite the best-laid plans, no security posture is ever foolproof; even air-gapped infrastructure can be accessed under the right conditions if an attacker is determined enough. This is where the OWASP Top 10 can prove truly invaluable, by helping organizations to understand which weaknesses are being commonly exploited so that your team can focus their efforts on preventing, discovering, and mitigating the most serious risks affecting websites, web apps, and APIs in today’s cyber world.

We’re going to start from the very bottom of the list and work our way up to number one - OWASP’s number one security risk. 

Here’s number 10: 

10. Server-Side Request Forgery (SSRF). This category was added in 2021. A server-side request forgery occurs when a web application uses a resource without validating the URL supplied by the user. It allows an attacker to force the application into sending a specially crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL). This can provide the opportunity for an attacker to manipulate the web application into sending a request to an inaccurate or unintended location, even with the appropriate system protections in place otherwise. 

In an SSRF attack, the attacker might tell the server to connect somewhere it shouldn’t, like an external system, which can lead to exposure of sensitive information like personal data or private administrative credentials. An attack of this type could take place in the actual vulnerable application or on the backend system that the app communicates with. 

An SSRF attack can have a significant impact on an organization since leaked private data and credentials could be disastrous for your team, your leaders, your customers, and your reputation. Any connection to unintended third-party systems could also result in the attacker gaining a foothold into the system, from which they could pivot to other systems within your organization. 

SSRF attacks can also occur against the server itself, wherein the attacker would prompt the app to make a request back to the server. Adept attackers can make it seem as though the request is legitimate, which could result in the attacker obtaining full administrative access to the server; all without triggering any alarms, because the request doesn’t seem to be from an untrusted third party. 

SSRF attacks were added to the list in 2021 because the incidence of reports has been steadily rising over time due to the increased use of cloud services and the varying different types of infrastructures used to build and host apps. 

This is a *big* concern for you if: Your organization runs any type of website, web application, or API which makes calls to other services (whether external or internal).

How to protect yourself now: The number one way to prevent SSRF attacks is to ensure any user (or browser) supplied data is sanitized and validated before use and that the responses from these calls are not returned directly to the user or browser in raw format. Additionally, segmenting your network so that a compromised server cannot be used to reach other servers and implementing “deny by default” firewall policies with IP whitelisting can provide yet another layer of security to help prevent these types of attacks. 

9. Security logging and monitoring failures. This category used to be known as “insufficient logging and monitoring,” and it moved up one spot this year from number ten on the list. OWASP has also expanded this category to include more types of failures. 

Your sites and apps should have continuous logging and monitoring services configured for them wherever practical. Without them, you may be missing important information which could help to identify vulnerabilities along with Indicators Of Compromise (IOCs) - leaving your organization at risk for a litany of high-risk attacks or breaches. 

As a rule of thumb, anything that could be audited should be logged. This should include successful and failed login attempts, DNS queries, and HTTP request logs. Logging this data is only half the battle, as monitoring must also be put into place to detect anomalies.

This category emphasizes the importance of detecting, monitoring, escalating, and responding to high risks or active breaches in an appropriate manner and timeframe. In the event that security monitoring and logging fall to the wayside, breaches cannot be detected and dealt with in a timely manner. 

Logging, monitoring, and detecting are considered “insufficient” within an organization anytime any of the following occurs: 

• Your application and API logs are not monitored 
• Any suspicious activity in the aforementioned app or API is not reported (due to lack of monitoring)
• Warning and errors don’t generate a clear log message 
• Alerts and response escalation processes haven’t been set up, or they’re not working 
• Your security testing tools don’t trigger alerts 
• Your app isn’t detecting or altering the risk of breaches when they occur 
• When something, anything, auditable is not logged 

This is a *big* concern for you if: Logging and monitoring are the cornerstones of any security program. If you run any sort of public or semi-public web application/site/API, you should be thinking about how you would gather IOCs to first detect an intrusion as well as better understand the depth and breadth of access an attacker might have gained to your system(s).

How to protect yourself now: Simply monitoring for higher than usual memory/CPU/network/disk usage on your servers and for increased traffic towards your website/app/API can often provide a big picture overview of the health of your services, but this is not enough information to reliably link a specific user account or IP to a specific request. Each service that processes logins, controls access, or provides server-side validation must log enough information about a request to ensure that the source of such a request can be reliably identified.

Once your logging and monitoring systems are in place, tested, and working, you can add even more layers to the security onion by adding an Intrusion Detection System (IDS) to automatically detect and alert on anomalous activity or an Intrusion Prevention Service (IPS) to automatically block and alert on any detected malicious activity.

8. Software and data integrity failures. 2021 was a bad year for cybercrime. As a result, several new categories were added to the OWASP Top 10 list - including this one. In a nutshell, a software and data integrity failure is related to code and infrastructure that is left open to vulnerabilities relating to data integrity. 

An example of this might be using software from sources you don’t trust or haven’t used before, which can leave you vulnerable to attacks like code injection, command execution, denial of service, and more. This can be most commonly attributed to updating components without testing newer versions. As was shown with malicious NPM packages earlier this year and the SolarWinds attack last year, private credentials can easily be stolen via malicious package updates.

The Software and Data Integrity Failures class also include insecure deserialization instances. 

A successful deserialization attack can allow attackers to remotely execute their own code within your systems. Deserialization opens your organization up to significant risk and vulnerability, as it allows attackers to reuse and access existing code in malicious ways, possibly even allowing for Remote Code Execution (RCE) where an attacker gains the ability to run arbitrary code of their choosing in your application. 

These types of attacks are now more possible than ever before due to the vast number of dependencies utilized by a typical modern website. Dependencies often each have their own dependencies, which are challenging to oversee and protect 100% of the time. 

This is where attackers can find loopholes and find the weak areas in an organization. There’s no “one size fits all” solution here, since internal infrastructure can look so different between different organizations. Cybercriminals know this, and they count on it to find the weak spots. 

This is a *big* concern for you if: This risk applies to basically the entire internet, as every modern web app/site/API is built upon some set of dependencies, however small; all of which can be a potential avenue of compromise for a talented attacker.

How to protect yourself: Whenever possible, make use of signed packages, modules, and updates. These digital signatures serve to prove that the same maintainer deployed both the current version and the latest version. An additional layer to this security onion could be the use of a trusted repository or even the creation of an internal repository that only hosts known-good modules, packages, and updates.

As for the other 7 OWASP security risks… 

We will discuss the remainder of the OWASP Top 10 in part two of our three-part security post. Stay tuned for the second installment, and in the meantime, assess your current risk status for these first three categories. Now is always a good time to do so.

A hosting platform designed for enterprise-grade security 

Your first line of defense for your site and app should be a trusted hosting partner - one that takes the OWASP Top 10 list of security risks into consideration every day. amazee.io’s platform team can help to provide the peace of mind you need for your sites and apps - complete with constant monitoring, logging, reporting, and alerting. Our secure infrastructure, based on decades of security best practices and decades of combined experience, safeguards your data from day one.

The amazee.io platform offers enterprise-grade security in several ways - one of them being our container-based infrastructure. Containerized hosting can provide a secure platform for your applications to run in while also providing substantial cost savings due to the ability of multiple containers to share a single physical node while still remaining logically separated using things like Pod Security Policies and Network Policies.

Our automated site monitoring systems alert us immediately if there’s an issue with a site, and we also place a heavy focus on proactivity by monitoring for many potential issues before they cause trouble.

Every organization’s security needs can be complex and unique, so we invite you to schedule a free 15-minute consultation with one of our security experts if you would like to learn more about how amazee.io keeps our infrastructure secure.