Cyber attacks have steadily become more frequent and sophisticated.
Gartner reports that the frequency and severity of cyber-attacks have increased over the past year, with Deloitte reporting that 75% of organizations experienced a cyber attack in the past 12 months.
Organizations that followed modern digital trends – such as the move to Cloud and API-enabled system interoperability – have increased their supply chain dependence, and accordingly must move beyond traditional perimeter-based security.
Today, organizations running multiple websites and online applications must proactively manage resilience toward four types of cyber-security threats:
- Distributed Denial of Service (DDoS) attacks
- Input-based attacks such as injection attacks, cross-site scripting, and file uploads - for example, malware or ransomware
- Attacks on vulnerable dependencies and supply chains
- Data exfiltration and theft
Let’s take a look at each of these threats below, and recommend best-practice defense approaches.
DDoS attacks
According to the firm Kaspersky, “The number of DDoS attacks in Q4 2022 increased by 22% compared to Q3 2022. Additionally, in 2022, the largest DDoS attack was 2.4 terabytes per second, which is 54% larger than the previous record.”
And DDOS attacks can have a real impact on the bottom line of any business.
A 2022 DDoS Attacks and Protection Report by Neustar shows that “the average cost of a DDoS attack for businesses is $2.3 million, and the average downtime is 5.6 hours.”
According to Cloudflare, the top current DDoS threats are:
- Hyper-volumetric DDoS
- Ransom DDoS attacks facilitated by high-performance botnets.
DDoS attacks can target a web application’s transport/network layer, or its application layer (on the Open Systems Interconnection (OSI) model of layers that computer systems use to communicate over a network):
- Attacks on the transport or network layer – are relevant for web applications due to servers and protocols being exposed to the Internet.
- Attacks on the application layer (your website, portal, or app) comprise of:
- HTTP GET floods: making a significant amount of requests to web pages within an application, either adding no, random, or targeted values as attributes to the pages
- HTTP POST floods: overloads web pages by submitting significant amounts of values to forms exposed to the Internet.
What makes DDoS attacks difficult to defend against, is that threat actors use a widely distributed network of source devices or a BotNet to make the requests, rendering the traditional defense of blocking the requesting IP via a firewall ineffective. The emergence of Botnet-as-a-Service makes it easier for bad actors to target more organizations at lower cost, and with lower risk of being caught.
So how can you protect your business against a DDoS attack?
Secure configuration is the first line of defense against attacks on the transport/network layer. For web applications, this ensures that only HTTP and HTTPS are exposed to the Internet, reducing the attack surface or the number of points an attacker can target.
Second, most organizations running web applications (like Squiz DXP) have outsourced this task to security behemoths such as Cloudflare to protect themselves against all forms of DDoS attacks.
At Squiz, this solution works with a combination of:
- default Cloudflare DDoS protection capabilities, like global rate limiting and known bad actor lists
- Squiz-managed rules, like advanced rate limiting, and rules to block certain behavior and patterns within the context of the traffic
Input-based attacks
In order to provide a digital experience, web applications need to be exposed to the Internet, and receive data and instructions from users. Attackers try to use these legitimate inputs – typically web forms – and sometimes vulnerabilities within a web application, to inject malicious code.
A well-known example is SQL injection, where a malicious user will try to submit SQL code through the web form of an application in the hope of getting unauthorized access to its database.
A 2022 Data Breach Investigations Report by Verizon indicated that “injection (Input-based) attacks were the second most common type of web application attack, accounting for 21% of all such attacks.”
Input-based attacks (also known as injection attacks) can be used to steal sensitive information such as usernames, passwords, credit card numbers, and other confidential data. In some cases, they can also be used to gain access to an organization's network or servers.
Attackers can use automated tools to launch input-based attacks on multiple targets simultaneously. Attackers can use passive reconnaissance tools to crawl the web for vulnerabilities within web applications. Once these vulnerabilities are known, attackers may build up a library of methods to use in an attack, or cause widespread automated attacks.
This means that even small-scale attackers can cause significant damage. But most of these threats are avoidable.
Organizations can take steps to mitigate the risk of attacks by detecting and blocking malicious input at the web application level through various means:
- OWASP (Open Worldwide Application Security Project) Top 10: adopt more secure developing practices and check their application against the OWASP top 10 web application security risks.
- Control what’s exposed: use good security practices to decide what information should be freely available:
- Sensitive, personal, or private information should only be accessible after authentication.
- Don't expose unnecessary APIs to the internet.
- Ensure all APIs use authentication before granting the ability to create, modify or delete records.
- Ensure that information stored in cookies is not sensitive, or personal.
- Properly protect usernames and passwords, and decide how tokens are used to persist sessions on the application
- Automate testing within your CI/CD pipeline: best practice recommends using automated dynamic applications security tests on applications when changes are made. This should occur before moving web applications to production and on a regular basis, even if no changes occur to the application.
At Squiz, we enable dynamic testing within a CI/CD pipeline to ensure code does not include the basic vulnerabilities expressed by OWASP. This practice closes a wide range of common web application vulnerabilities.
- Validate inputs: all input into web applications should also be of known types and patterns. For instance, if a field in a web application expects an email address, the input should validate as an email address before processing that information on the server. Additionally, Squiz DXP provides default sanitation over a broad range of inputs to negate any obvious malicious input – defending your service against SQL and code injections.
- Employ a WAF: Squiz DXP SaaS is protected by Cloudflare’s Web Application Firewall (WAF). A set of base-managed rules is constantly updated for the changing range of attacks aimed at web applications. For Squiz DXP on Squiz (private) Cloud, this service is optional.
- Add BOT protection: adding Bot protection to any public-facing form remains the best practice – typically through a CAPTCHA challenge. CAPTCHAs are added to forms to differentiate between real and automated users – bots – by setting a task that is relatively easy for humans. Failing to make sure whatever is interacting with your form is a real person leaves web applications more exposed to input-based, as well as DDoS attacks.
Attacks on vulnerable dependencies and supply chains
Web applications use a wide array of third-party components. These components then use their own third-party components to provide the rich digital experiences we know today.
Exploitable vulnerabilities may exist within any of these components (built and maintained by third parties), and attackers may use any of these vulnerabilities to target your web applications.
These attacks are becoming more common, increasing by a whopping 430% between 2019 and 2021, and can have far-reaching consequences. Supply chain attacks can affect not only the targeted organization but also your customers and partners.
The first step to take to protect yourself is to reduce the risk of using vulnerable software components with secure dependency repositories.
Secure dependency repositories only include components that have been thoroughly vetted for security vulnerabilities. By using these repositories, you can reduce the risk of using software components with known vulnerabilities that can be exploited by attackers.
At Squiz, all known vulnerabilities within widely-used software components are centrally tracked as common vulnerabilities and exposures (CVEs), and this information is fed back to repositories where web applications get their dependencies.
Moreover, when our customers use Squiz DXP to build components, they also access automatic protection from vulnerabilities and exposures. Our secure dependency repository also tracks key information about which version of components contain new and known vulnerabilities. This practice reduces the risk that a third-party component used within the Squiz DXP could be exploitable.
Data exfiltration and theft
Security misconfigurations occur when security settings are not properly configured or managed, leaving vulnerabilities that attackers can exploit to gain unauthorized access to an organization's systems or data. This account for 20% of all data breaches.
For example, this could happen if an administrator leaves default passwords unchanged, fails to apply patches, or misconfigures firewall settings.
Both security misconfigurations and poor access controls can put an organization's data at risk, as they can allow unauthorized individuals to access or manipulate sensitive information. This can lead to unauthorized access to sensitive data, data loss, and data leaks. These incidents could result in significant financial losses, reputational damage, and legal liabilities.
Thankfully, security misconfiguration is preventable with proper controls and security hygiene practices. Security-aware companies implement secure hardening practices like AWS Well-Architected, AWS Config, and other best practices like CIS benchmarks.
Organizations can also avoid the main misconfiguration opportunities by outsourcing this task to a partner (like Squiz!) to configure their application according to their own unique requirements.
Your staff should also be provided training resources and best-practice guidance on how to use your application securely, including configuration guidance to ensure your internal users have the correct access permissions.
Another common misconfiguration is the use of Content Security Policies (CSP) on web applications.
This application design level requirement must be included for each web application created, whether on the DXP or anywhere else. As an example, if CSPs are too loose, content might be allowed from unknown sources – making the web application vulnerable to scripts being injected, and loading content from malicious external servers. It is important to set up CSPs early in the application design process, as they are harder to implement after the fact.
To top it off, Squiz also implements further controls on behalf of its customers, including Squiz health checks to identify any accidental misconfigurations made in implementations of the DXP. This visibility is important to monitor changes to the privacy of assets within the DXP.
Why use Squiz DXP SaaS?
At Squiz, security is of the utmost priority, and our DXP SaaS is designed to make all the heavy lifting for you.
In short - you are outsourcing your security to an expert.
Our Platform Engineering and Security teams continually review, revisit, improve, and analyze existing and potential security threats on your behalf. All our security enhancements are constantly updated and automatically applied to all customers via behind-the-scenes upgrades, so you don’t even have to think about it.
Every customer can have the assurance that their web platform is always up to date, without any effort required by your team, freeing you time and resources for other tasks.