Today, we delve into the ongoing development of the Application Security Verification Standard (ASVS). If you’re new to ASVS, it serves as a foundational guideline for evaluating the technical security measures of applications. The ultimate goal? To rigorously safeguard the confidentiality , availability and integrity of platforms.

I’m excited to share that, in our ongoing efforts to improve application security, we’ve successfully introduced 9 new elements to the ASVS. These updates account for the changing threat environment and target newly-identified vulnerabilities crucial for maintaining strong application security.

Let’s examine these inclusions more closely:

Zip Slip

Zip Slip is a vulnerability that can occur when extracting files from a compressed archive, like a ZIP file. Imagine you download a ZIP file that contains a bunch of folders and files, and you use a software program to “unzip” it, which means you’re taking the files out of the ZIP container and putting them on your computer.

The danger with Zip Slip is that a hacker could sneak in a harmful file into the ZIP and trick your software into placing this harmful file in a location outside of where you expected it to go. In doing so, the hacker might be able to overwrite an important file or even execute harmful code on your computer.

So, in simple terms, Zip Slip is like receiving a package that you think contains just clothes, but it also has a sneaky trap hidden inside that could mess up your house when you open it.

You can see a vulnerable Go code in the following figure:

Link to the issue: https://github.com/OWASP/ASVS/issues/1222

Arbitrary File Read via Malicious Symlink

It refers to a situation where attackers can exploit a feature in computer systems known as “symbolic links” to deceive the system into accessing a file it shouldn’t be reading. This could result in the exposure of confidential or sensitive information stored on the system.

To break it down further: In computer systems, a “symbolic link” (often shortened to “symlink”) is like a shortcut that points to another file or directory. It’s a way to access that target file without having to navigate to its actual location. Normally, this is a convenient feature for accessing files more easily.

However, in the case of this vulnerability, attackers can craft malicious symbolic links that, when followed by the system, point to files that are not intended to be accessed. For example, an attacker could create a symbolic link that points to a confidential document or a system file containing sensitive data.

When the system follows this deceitful symbolic link, it ends up reading the unintended file, thinking it’s accessing something legitimate. In doing so, the system could disclose information that should have been kept secure, such as passwords, personal data, or proprietary business information.

In essence, this vulnerability takes advantage of the system’s trust in symbolic links to manipulate it into revealing data that should remain protected. The system is tricked into

thinking it’s performing a safe operation, while it’s actually exposing sensitive information to unauthorized individuals.

Link to the issue: https://github.com/OWASP/ASVS/issues/1424

Incomplete Hostname Regex

It refers to a situation where the programming code designed to verify website names or URLs is not rigorous enough, thereby creating an opening for malicious actors to exploit the system. Imagine this as akin to a security guard at an exclusive event who merely glances at the first few characters of your invitation code and waves you through, without checking the complete code. This lapse could allow someone with a partially matching, but ultimately fake, invitation to gain entry.

In the example code that is provided, the aim is to redirect users only to websites that are either directly under ‘example.com’ or are subdomains like ‘www.example.com’ or ‘beta.example.com.’ The code uses something called a “regular expression” (regex for short) to perform this check. A regular expression is a pattern that the computer uses to compare against the website name to see if it’s a match.

However, the regular expression used in the code is incomplete or not specific enough. This means a savvy hacker could craft a URL that partially fits the pattern the code is looking for, thereby bypassing the check. For instance, a hacker could use a URL that looks like ‘www.example.com.badguy.com,’ and the incomplete regex might see the ‘www.example.com’ part and incorrectly validate it, while missing the ‘badguy.com’ portion. As a result, the code would mistakenly redirect you to this malicious site, thinking it’s legitimate.

So, in essence, because the code that checks the website name isn’t comprehensive or fully thought-out, it could inadvertently let hackers reroute you to a website that you never meant to go to, potentially exposing you to various risks such as malware or phishing attacks.

Link to the issue: https://github.com/OWASP/ASVS/issues/1600

Regular Expression DoS (ReDoS)

The vulnerability known as “Regular Expression Denial of Service” (ReDoS) involves the exploitation of certain patterns in regular expressions, which are sets of characters that form search patterns. These exploitable patterns can lead to a denial-of-service (DoS) attack on an application. In such an attack, the application becomes unresponsive because it gets caught up in an endless loop of attempts to match the regular expression pattern, consuming all of its computational resources and effectively bringing its operations to a halt.

To offer a more detailed explanation: Regular expressions are widely used in software programming for tasks like searching, matching, and manipulating text. They are highly flexible and can be crafted to match very specific patterns within a string of text. However, some regular expressions are particularly complex or poorly designed, making them susceptible to exploitation by attackers.

In a ReDoS attack, an attacker sends a specifically crafted text string to the vulnerable application. The complexity of matching this string against the regular expression pattern forces the application to enter into an extremely lengthy or even infinite process of trying to find a match. This results in a massive consumption of the application’s CPU and memory resources, effectively freezing it and making it unavailable to legitimate users.

This form of denial-of-service attack is particularly insidious because it does not necessarily require a large volume of network traffic, unlike other types of DoS attacks. A single well-crafted string can be sufficient to induce the application into a state of paralysis, making it a highly effective and low-cost method for attackers to disrupt services.

In summary, the Regular Expression Denial of Service (ReDoS) vulnerability exploits the intricacies of regular expressions to overburden an application’s resources, making the application unresponsive and unavailable for use. This jeopardizes both the functionality and the availability of the application, creating significant issues for both users and administrators.

Link to the issue: https://github.com/OWASP/ASVS/issues/1562

Type Juggling

The concept of “Type Juggling” refers to a particular behavior in some programming languages, notably PHP, where variables can automatically change their data type depending on the context in which they’re used. This feature, known as “weak typing,” can lead to unpredictable and unintended outcomes when executing code. Exploiting this aspect of weak typing can allow attackers to manipulate the logic of an application, thereby causing it to behave in ways not originally intended by the developer.

To elaborate further: In strongly typed languages like Java or C++, variables must be declared with a specific data type, and any attempt to change the type will result in a compile-time or runtime error. However, in weakly typed languages like PHP, a variable’s type can change dynamically during runtime. For example, a variable initially holding a string can seamlessly transform into an integer or a boolean (true/false value) depending on the operation it’s involved in.

While this flexibility can make programming easier, it also opens the door for inconsistencies and security vulnerabilities. For instance, when comparing two variables using weak typing, a string like “1” and an integer 1 may be considered equal, even though they are of different types. An attacker can exploit these kinds of weak comparisons to, say, bypass password checks or manipulate application logic.

To put it into an everyday context: Imagine you have a lock that can be opened with a metal key but also, due to a design flaw, can accidentally open if you use a plastic toy key. While the lock is more “flexible,” it’s also far less secure than it should be. Similarly, the flexibility of weak typing in languages like PHP can inadvertently lead to “loose locks” within the code, making it easier for attackers to exploit these weak points to gain unauthorized access or manipulate the application in malicious ways.

In summary, Type Juggling is a phenomenon linked to the weak typing capabilities of certain programming languages. Although it can make coding simpler and faster, it can also produce unpredictable results and create potential security vulnerabilities. Exploiting this behavior can lead attackers to manipulate an application’s behavior, causing unintended and often harmful outcomes.

Link to the issue: https://github.com/OWASP/ASVS/issues/1539

Formula Injection (Latex Injection)

The vulnerability known as “Formula Injection” or “Latex Injection” is a security risk where attackers have the ability to insert harmful formulas or Latex commands into a document. Once the compromised document is opened by an unsuspecting user, these injected formulas or commands are automatically executed. This can lead to a range of malicious outcomes, such as unauthorized data access, manipulation of document content, or even executing malicious scripts on the user’s computer.

To provide a more extensive explanation: Documents, especially those related to spreadsheets or mathematical publications, often have the capability to execute formulas or Latex commands for various functionalities. This feature is intended to make it easier for users to perform complex calculations or format mathematical text automatically. However, if the application that reads these documents does not properly validate or sanitize the incoming data, it opens up the potential for abuse by malicious actors.

In the case of Formula Injection, an attacker crafts a document containing harmful formulas or Latex commands that are designed to perform actions not intended by the user. For example, a malicious formula could be crafted to read files from the user’s computer and send them to an external server. Alternatively, a Latex command could be manipulated to download and execute malicious software when a user opens a seemingly benign academic paper.

This is akin to receiving a letter in the mail that contains a hidden mechanism; when you open the letter, the mechanism activates, executing actions that you did not anticipate, such as spraying ink on your face or emitting a foul smell. In a digital context, the consequences could be far more severe, ranging from unauthorized data exposure to potential identity theft or system compromise.

Therefore, Formula Injection or Latex Injection is not just a matter of a simple document behaving unexpectedly. It’s a serious security vulnerability that leverages the inherent trust users place in documents and the applications that open them. The exploitation of this vulnerability can lead to severe and wide-ranging repercussions, making it critical for applications to implement proper validation and sanitization processes to protect against this type of attack.

Link to the issue: https://github.com/OWASP/ASVS/issues/1559

JNDI Injection

The security vulnerability known as “JNDI Injection,” short for Java Naming and Directory Interface Injection, presents a significant risk in Java-based applications. Under specific circumstances, notably when coupled with deserialization vulnerabilities, this flaw can enable attackers to execute arbitrary Java code within the targeted application. This poses a considerable threat, as it can result in unauthorized access, data breaches, or potentially giving attackers control over the affected system.

To delve deeper into the issue: The Java Naming and Directory Interface (JNDI) is a Java API that allows Java applications to interact with naming and directory services, like DNS, LDAP, or RMI. Essentially, it helps Java programs locate and invoke objects, data sources, or even other programs over a network. In a secure and well-configured environment, JNDI plays a crucial role in facilitating these operations smoothly.

However, if not properly managed and secured, JNDI can become a point of vulnerability. The issue arises when an application fails to adequately validate or sanitize external input before it is processed by JNDI functionalities. Attackers can exploit this lapse in security to inject malicious JNDI references into the application. These malicious references, when processed by the JNDI, can lead to the loading of arbitrary Java classes or the execution of unintended Java methods.

In summary, JNDI Injection is a serious security vulnerability in Java-based applications. It exploits inadequacies in the validation and sanitization of external inputs, particularly when these inputs are processed in the context of deserialization operations. When successfully executed, it allows attackers to run any Java code of their choosing within the application, leading to a wide array of potential security breaches and unauthorized activities. Given the severity of the potential impact, it is imperative to secure applications against this kind of vulnerability.

Link to the issue: https://github.com/OWASP/ASVS/issues/1533

Prototype Pollution

The security issue known as “Prototype Pollution” is a specific type of vulnerability that occurs predominantly in JavaScript applications. This flaw can give attackers the ability to modify an

object’s prototype, and such manipulations can result in the unintended execution of code within the application. The consequences of this can be severe, ranging from application malfunction to data breaches, unauthorized system access, or other types of security incidents.

To elaborate in greater detail: In JavaScript, objects have prototypes, which are essentially parent objects that provide properties and methods for the objects derived from them. In a well-designed application, these prototypes are structured to maintain data integrity and to provide functionalities that are secure and predictable. However, if the application is not carefully coded to prevent unauthorized modifications, attackers can manipulate these prototypes, altering their properties or behaviors.

When an attacker successfully pollutes a prototype, those changes can propagate to all objects that inherit from that prototype. This is particularly dangerous because these modified properties or methods can then be leveraged to change the application’s behavior in ways that benefit the attacker. For instance, the attacker could manipulate object prototypes to override security checks, change user permissions, or even execute arbitrary code.

Imagine, if you will, a scenario in which a master key mold at a key-making factory is subtly altered without anyone’s knowledge. Every key subsequently made from that mold would inherit the changes, potentially unlocking doors they were never intended to open. Similarly, Prototype Pollution in JavaScript is like tampering with that master key mold; any object that inherits from the polluted prototype could potentially ‘unlock doors,’ leading to unexpected and often dangerous behavior within the application.

The risk is amplified when you consider that JavaScript is one of the most widely used programming languages and serves as the foundation for numerous web applications, server-side technologies, and more. As a result, the attack surface for Prototype Pollution is quite extensive, making it a pressing concern for developers and security professionals alike.

In conclusion, Prototype Pollution is a serious security vulnerability specific to JavaScript applications. It targets the fundamental architecture of objects within the language, allowing attackers to manipulate object prototypes. These manipulations can then cascade down to every object that inherits from the polluted prototype, leading to unintended consequences such as unauthorized code execution, data leakage, and other forms of security compromise. Given its potential for widespread impact, it is critical for developers to implement proper security measures to mitigate the risks associated with this vulnerability.

Link to the issue: https://github.com/OWASP/ASVS/issues/1563

Cache Deception

The security vulnerability known as “Cache Deception” pertains to the abuse of caching mechanisms within web applications to potentially disclose sensitive information to users who

are not authorized to access it. This flaw represents a significant concern, as caching is a widespread practice used to speed up content delivery on the Internet. However, if not implemented with stringent security measures, caching can serve as an avenue for attackers to exploit and compromise the confidentiality of information.

To provide more comprehensive insight: Caching is a technique employed by web services and browsers to store copies of web content temporarily. This is done to reduce the load on servers and to offer quicker content delivery to users. For example, once you visit a webpage, the images, text, and other elements might be stored in a ‘cache,’ so the next time you or someone else visits that page, it loads faster. While generally beneficial for performance, this practice can be perilous if sensitive information is inadvertently stored in a cache that is accessible to multiple users.

The Cache Deception vulnerability occurs when an attacker tricks the caching system into storing content that should, under normal circumstances, remain confidential and protected. Once the data is cached, any user who subsequently accesses the cached resource might be exposed to the sensitive information that was deceptively stored. In this context, ‘sensitive information’ could range from user passwords and private messages to confidential corporate data.

To create a real-world analogy: Imagine a public library where some shelves are supposed to contain only general reading materials, but an individual manages to place a confidential document among those books. Unwittingly, the library staff includes this document when making photocopies for public distribution. Now, anyone who receives these copies will also get access to the confidential document, violating its intended restricted access.

The danger is exacerbated by the omnipresent nature of caching across modern web infrastructure. From content delivery networks (CDNs) to server-side caches and browser caches, the opportunities for Cache Deception attacks are numerous. This makes it imperative for organizations and developers to be vigilant in how they configure their caching mechanisms.

In a nutshell, Cache Deception is a substantial security vulnerability that takes advantage of the inherent risks associated with web caching. Through manipulating these caching mechanisms, an attacker can force the system to store and serve sensitive data to unauthorized users. Given that caching is an integral part of the current web architecture for enhancing performance, the potential reach of this vulnerability is vast. Therefore, meticulous attention must be given to the security aspects of caching configurations to mitigate the risks associated with Cache Deception effectively.

Link to the issue: https://github.com/OWASP/ASVS/issues/1560

These new additions to the ASVS not only showcase its ability to adapt and improve but also highlight the proactive approach of Forward Security in driving this change. Our commitment at Forward Security remains steadfast – to advance and fortify the application security landscape.

I am deeply grateful that the ASVS committee for recognizing the significance of these items. The world of application security is a constantly shifting landscape, but with each enhancement to the ASVS, we take a significant leap forward in ensuring safer digital interactions for all.

To learn more about these vulnerabilities and how Forward Security can assist you in ensuring your applications remain secure, do get in touch. Here’s to a safer, more secure digital future!

Stay secure and stay updated!