Web Application Attack Vectors Every Developer Should Know

With mobile functionality becoming increasingly crucial, many development teams are now delivering rich user experiences through web browsers. Native app development—while core to many business models—is conversely more complex, expensive, and occasionally superfluous when considering intended workflows. Web-based services have arisen to circumvent these disadvantages. They’re typically browser agnostic, easily discoverable, adaptable during development, and require no client downloads.

Key vulnerabilities often stem from core application code. Image courtesy of Ferenc Almasi, via Unsplash.

However, it’s important to remember how *open* the web is compared to a controlled ecosystem—a la Windows, macOS, iOS, and others. Internet usage is through the roof these days. Attackers have therefore realized that their pool of potential targets has grown exponentially. 

Applications must evolve to counteract these dangers; accordingly, web application attack vectors pose a threat to lightweight services everywhere. Sound coding and feature implementation are critical. You should also consider Edgescan’s 2021 Vulnerability Statistics Report, which found the following: 

• 32% of vulnerabilities within internet applications are considered “critical” or “high” risk

• 50% of internal application vulnerabilities carry the same threat level

Additionally, the U.S. government’s National Vulnerability Database contains over 150,000 listings. Given that mean time to remediation (MTTR) averages about 60 days—and that 75% of 2020’s exploited vulnerabilities were over two years old—developers have a responsibility to deliver quality code. These problems also underscore the rising DevOps tide in recent years. 

Best practices are invaluable when creating secure web applications. This article will assess common web application attack vectors, and explain how to combat them. 

What’s an attack vector?

Fundamentally speaking, an attack vector is a method or path through which hackers can inflict damage on a software-based system. This can take many forms within a web application. Attack vectors can also negatively impact users, applications, or both depending on their exploitation. For example, many attackers seek only to gain unauthorized access to guarded systems, and steal proprietary information. 

You may hear security flaws referred to as “holes” or “backdoors”—as they grant attackers unintended access to underlying systems. If a metaphorical castle’s walls form a protective barrier, then we might envision a vulnerability as a partial collapse, a secret tunnel, a well-placed ladder, or even a sleeping guard at the gates. 

Image courtesy of Markus Spiske, via Unsplash.

Like many flaws, web application attack vectors are either known or unknown. For example, a Ponemon Institute report revealed that 62% of breached organizations were unaware of their exploited vulnerability’s existence. Last year, nearly one-third of companies detected an attempted breach—stemming from key system vulnerabilities. Both edge and internal security are critical to thwarting bad actors. 

 Vulnerabilities usually afflict simpler web applications less prominently. Fewer lines of code and basic content—often seen within static applications—have a smaller attack surface. Every application has a footprint. Applications built using just CSS, HTML, and some JavaScript will be lower-maintenance than those dynamically leveraging PHP or Express (aka Node.js). Additionally, eCommerce platforms and portals have their own woes with encryption and authentication. 

There’s an interesting give and take with modern microservices—which consist of numerous moving parts. While packaging these fragmented features is challenging, each compartmentalized code base is easier to test and maintain. The good news is that isolation and decoupling provide security advantages. One compromising incident can’t do as much damage as it would within a monolith. That’s not something to take for granted, however. Threats are continually evolving. 

Common Attack Vectors

When it comes to security, tackling the lowest-hanging fruit is necessary before drilling down into the obscure. Similarly, developers should spend the lion’s share of their time hardening applications against today’s leading attack vectors. The following are most prominent vectors currently being exploited:

Distributed Denial of Service (DDoS)

Modern web applications are supported by networks and an underlying server infrastructure. These pieces ensure application availability, connectivity, and access to essential information (like Reddit posts, banking details, or store inventory). Applications have to support multiple user sessions in tandem in order to work effectively. Accordingly, they must typically share a finite pool of computing, memory, and networking resources to make this happen. 

DDoS attacks aim to overwhelm these resources with artificial traffic spikes. Real, human users aren’t enlisted for this task. Instead, an attacker utilizes a network of remote machines, often called a “botnet,” to overwhelm an application’s backend. Servers become choked by requests. Load balancing goes out the window, and available bandwidth quickly diminishes. 

Responses sent back to legitimate users slow to a crawl—or are rejected altogether. This is where the “denial” part of the equation comes into play. It’s extremely frustrating for the average user, as their workflows are interrupted without much feedback as to why.

A great number of web applications are built using APIs, or connective interfaces which allow services to communicate back and forth. Apps use APIs to unlock core features or grab data that users find useful. Unfortunately, specialized “layer 7” DDoS attacks specifically impact the mechanisms behind REST API functionality. The servers that process HTTP requests like `GET` and `POST` are interrupted. When one API powers the bulk of a web application, a singular attack can be crippling. 

Man in the Middle (MITM)

Two-way communication is central to how web apps function. End users send requests and other information to a destination server. That server subsequently fetches something useful and sends it back. A man-in-the-middle (MITM) attack places another nefarious party between Points A and B, who then attempts to intercept those messages. There’s also a form of social engineering involved in these attacks—since email phishing and imposter websites may occasionally be used.

From a web-browsing standpoint, the MITM attempts to inject malware or spyware onto a host device via an active internet connection. They might prompt users to download infected files or click on certain links to deliver the payload. Typically, the user has little reason to believe these resources are illegitimate. From that point onward, the malicious software can also record browser data as it’s transmitted between user and recipient. Attackers automatically gather these logs. 

An attacker may also download software tools on compromised networking hardware, like routers, which can accomplish this same task. Bad actors may also spoof IP addresses or DNSes, perform SSL hijacking, or steal browser cookies. 

Cross-Site Scripting (XSS)

One of the most prevalent attack vectors across the web, cross-site scripting (XSS) involves the inclusion of untrusted, invalidated data across new webpages. An application uses this vector to essentially track or hijack user sessions. These injected scripts can also cause malicious redirects or deface websites—all thanks to user-supplied data. 

A browser API typically employs a combination of HTML and JavaScript to enable this. XSS attacks can even lead to credential theft, data exfiltration, and remote access to protected machines.

SQL Injection

Untrusted data has contaminated many applications. Accordingly, SQL injections occur when this data reaches an interpreter—or mechanism that makes sense of user requests. This type of attack typically involves an SQL database matched with unsanitized user inputs. These inputs aren’t cleansed, filtered, or otherwise checked for malicious inputs—introducing notable risk.

Hostile data from external attackers, impersonating legitimate data, can make this interpreter execute problematic commands. Bad actors can even access sensitive data without proper authorization, thus piggybacking off of a user’s own set of application privileges. 

Brute-Force Logins

Web application authentication systems use a number of mechanisms to improve login security. Password expiry (more controversially), enforced delays, and fine-grained password policies aim to shield systems against unwanted access. Brute-force attacks are essentially large-scale guessing games, in which attackers utilize password dictionaries in rapid succession to compromise user accounts. It’s common for malicious tools to test hundreds or even thousands of passwords in mere minutes. 

This is a game of attrition—one where security teams aim to outrace attackers and stonewall any intrusions before they succeed. There are only so many combinations that one can try. Hackers who succeed can spread malware, steal personal data, hobble your application, and even change backend configurations. There’s a good reason why admin accounts are so valuable on the dark web. 

Common Mitigation Strategies

Thankfully, developers have plenty of options in their toolboxes when it comes to battling attackers. Consider implementing one or more of these to tip the security scales in your favor: 

Penetration Testing

Quite often, there’s no way to know how deeply an attack might impact your application without simulating one yourself. Often synonymous with chaos engineering, penetration testing involves breaching one or more application systems, APIs, servers, or networking endpoints—then evaluating the blast radius. This radius essentially describes how widespread an attack’s impacts are on your infrastructure and users. You can also evaluate the effectiveness of your web application firewall (WAF) using these methods. 

While penetration testing can be performed during development, you won’t extract its full potential without testing in production. This impacts a certain number of everyday users, yet is essential to understanding how afflicted systems might behave in the wild. 

Such processes are key to uncovering vulnerabilities and patching them as quickly as possible. Even though shift-left testing is non-negotiable today for sound operations, “pen-testing” gives developers a way to bolster security at multiple stages in the pipeline. 

Using Trusted Libraries

Existing web applications are functioning collections of self-developed and boilerplate components—including SDK contents—that coexist seamlessly. These components originating from external sources must be verified to ensure authenticity and safety. 

With open-source development being so integral to numerous projects today, it’s become that much more important to vet all pieces of an application effectively. Using code blocks and APIs from trusted sources can prevent malicious code from running rampant. Accordingly, code that’s functional yet improperly tested can cause vulnerabilities. Trusted libraries can even bypass application security managers, per the developer’s request or configuration. This can prevent build conflicts.

Static Code Analysis

While an application might be described as “in motion,” static application code is inactive and typically undeployed within a given system. This pre-production portion of your application can be tested without running. Static code analysis thus allows you to inspect code for flaws, understand its functionality, and flag any discovered issues for development teams.

Static analysis can help find programming errors, standards violations, syntax issues, security holes, and undefined values. Any of these issues can cause unforeseen problems if they sneak into production. Automated testing tools and component inspection processes are useful for accelerating what might otherwise be tedious. 

Fingerprinting

Image courtesy of George Prentzas, via Unsplash.

Crucially, the fingerprinting process can help prevent brute-force attacks and fraudulent access attempts. It involves distinguishing genuine human traffic from bot traffic—which accounted for over one third of all internet traffic in 2020.

Fingerprinting can help you identify the malicious bots known for stealing user data or spam proliferation. Accordingly, the process helps you track known users by associating legitimate requests with IP addresses. No cookies are required for this. On the flip side, it allows you to detect false requests. 

Typically, a fingerprinting mechanism involves hardware specifications, browser extensions, plugin behavior, and associated factors in assigning each user a unique ID. Their subsequent sessions are tied to this identity. 

Holistically Strengthening Application Security

As you can see, many factors influence the overall security of your web application. Attack vectors likely aren’t going anywhere, and adjusting our combat strategies against them is paramount to development success. End users deserve strong security, just like they deserve exceptional experiences from one session to the next. By keeping up-to-date on these vectors and adjusting accordingly, you can prevent glaring vulnerabilities from multiplying.

Fingerprinting.js remains a leading vendor for thwarting many common attack vectors across the web. Our solution empowers developers to solve fraud at the source—boosting security, compliance, and authentication-authorization procedures within your web application. 

Want to learn more? Give our documentation a read, or start your free trial today. 

Banner image courtesy of FLY:D, via Unsplash.