Enhance your Application Security using Client-side signals

In this two-part post, I’m describing the concept of Client-side signals and how they can be used to enhance your web and mobile application security strategy.

As is well known, API and application security are currently at the forefront of today's CISO agenda. These are real concerns, especially due to the accelerated digital transformation that has forced all companies to adapt and quickly build new applications to stay competitive and keep their relevance through the stormy times we have lived these past 3 years. According to the World Bank, over 40% of adults who made merchant in-store and online payments using a card, phone, or the internet did so for the first time since the start of the pandemic. This is an attestation of how much more people are consuming online applications.

Delving further into the “adapt and quickly build” of new applications, what transpired was the creation of numerous new APIs, Web and Mobile applications, and an entire ecosystem facilitating deep interdependency between them. When you visit any online application today, be it Web or Mobile, it is highly likely that this application is constructed using APIs and is leveraging a broad array of 3rd-party integrations in the form of APIs or other web components.

Below, you will find a simple example of a Web page calling external entities as it loads in a browser:

Figure 1. Waterfall

The figure above illustrates what we could characterize as an ecosystem comprising internal and external web components. These components provide the necessary services to enable the application to fulfill its intended purpose. A browser loading components of web applications isn’t something new; in fact, browsers are created to perform exactly this function; what is new is the fact that this application requires a whole set of external components that are fetched directly or indirectly by the browser, and, despite these external dependencies being transparent for the end-user, they represent a real challenge from the application security strategy point of view.

At F5, we embody what I personally refer to as the “web proxy mindset”. For the past 27 years, a substantial part of our work, of course, in an oversimplified way, has to do with proxying network communications between a client and a server; thereby, proxying these communications gives us the ability to guarantee that all requirements for an application or API are met, whether related to security or connectivity.

Figure 2. Typical client-server communication

If you search online for the definition of a proxy server, you will find that it is defined as “a server application that acts as an intermediary between a client requesting a resource and the server providing the resource, and it improves privacy, security, and performance in the process.”

The paradigm shift for protecting modern applications

To fight the new generation of attackers and fraudsters, the ones that usually sell the attack as-a-Service on the dark forums, F5 has enhanced its solutions by integrating our web proxy approach with the client-side signals. We will get into deeper details later in this post, but it could be seen as having a magnified glass to closely monitor the activities within the browser as a person interacts with the application prior to having the actual request sent to the application server. Combining both techniques is a strong strategy to enhance your application security.

When discussing the concept of client-side signals with CISOs and their teams, I often find that this methodology is not widely known and is largely underutilized by companies seeking to bolster their security detection capabilities.

What are the Client-side signals?

Client-side signals are the telemetry that can be pulled from the browser or mobile app while a person or an entity interacts with the application. These signals can typically be categorized into three main groups: a) human interaction signals, b) device environment signals, and c) network signals.

Human Interaction Signals

This category of signals will allow us to determine if what is using an application is a person or not and if this person is bad or good intended. But how and why is this relevant to your security strategy?

Is this a person or not? When this question is raised, how confidently can you answer that? It is well-known in the application security industry that bots are a real problem. These software entities are created for several different purposes; one of them is to “mimic” a person's behavior and, by doing that, imitate the steps and behaviors a human would do while interacting with a page or app. Distinguishing if an entity visiting your application is a Human or a Bot before having your application servers process an HTTP request will automatically improve the overall user experience, as you will offload the burden of processing noise from your servers.

It is important to emphasize that Bots are not typically created to overload your servers; they’re created to “mimic” humans with the intention of abusing a legit business logic your application provides and do not get caught as they do that.

The examples below were extracted from a real Login application and can give a visual perspective of how Bots can “mimic” humans:

Figure 3. - Bot

Figure 4. - Human

Is this person good or bad intended? I must admit that this is a very tricky question to answer; however, answering it at an initial stage of interaction can significantly enhance your security strategy. Determining intention is a typical methodology used by fraud prevention solutions, but having a glimpse of how a person behaves while interacting with the application and using it to either permit or deny a request is also applicable for the application security teams as it can help detect the initial stages of an attack, which usually involves reconnaissance techniques.

What distinguishes a human performing an attack reconnaissance technique from a regular human using your application? There are several factors at play here, and employing AI strategies can probabilistically determine the typical behavior of well-intended users on your application by analyzing things like:

How common is having users often leave the active browser tab while interacting with the application?
How typical is having users press unusual keys while filling out forms?
What is the average time a user spends on each step of your application?
How frequently does a user change or use different devices to access the application?
Is the mouse moving like an untrained human?
Is this person actively submitting any data while using the application or sitting there and clicking randomly, or, maybe, apparently doing nothing?

…and several others.

Device Environment Signals

This category of signals is based on fingerprinting techniques. Device fingerprinting isn’t something new, and there are known ways to get around fingerprinting. However, the goal here isn’t only to fingerprint a device but also to check if the collected signals are contradicting somehow, thus giving the signs that something has been spoofed to avoid real identification. Remember, we are looking for lies!

Application security teams should be looking for signals like:

Screen Size
Fonts
Plugins/Extensions
CPU/GPU capabilities
Graphic rendering capabilities
Canvas configurations
Browser configurations
Time zones

…and hundreds of others.

Figure 5. Emoji rendering

Examples of questions to help identify spoofed devices using these signals could be:

Why is this browser saying it is a certain version of Firefox for MacOS, but some properties are only found on Windows OS?
Why is this browser rendering a certain emoji as if it were for a different browser or OS?
Why is this mobile app showing properties as if it is an emulator?
Why is this session coming from a remote desktop?
Why is this a Virtual Machine?

…and several other questions that can lead to identifying a spoofed device and eventually trigger a security policy.

Network Signals

This category of signals will provide insights into where this request is coming from. Typically, security solutions rely on IP addresses to determine if a request is permitted or denied, but today, relying only on IP addresses is a very ineffective way of determining the real source of a request.

Numerous companies provide VPN and forward proxy services, commonly found in the attacker's toolkit, but the real danger lives on the Botnets. Today’s Botnets are comprised of regular end-users who willingly participate in the network and compromised devices acting as internet proxies without the owner's knowledge. In such cases, relying on a Geo-blocking or IP reputation database may not flag these requests as malicious since the source IP address is often associated with a regular ADSL or LTE/5G mobile network and is not necessarily engaged in malicious activities.

Additional effort is required to enhance your ability to identify the true source of a request. Collecting network-based signals, including IP addresses, HTTP headers, TLS fingerprints, and a portion of the request's payload, and combining these signals with device environment and human interaction signals can provide robust insights into the malicious or non-malicious nature of a request. It is important to note that these alone are not a solution to detect a malicious source. More advanced techniques like TCP handshake timing, TCP-related variances and others can also come into play and enhance the overall detection.

Also, every browser has its own way of crafting an HTTP request, so the goal here is to detect inconsistencies in the HTTP requests and enhance anomaly detection capabilities.

Now that you know some capabilities of the Client-side signals, the next questions might be:

How to collect Client-side Signals?
How can you guarantee the signals are not altered or faked while they are collected? Making decisions based on bad data leads to false positives and false negatives.
How can you confidently say that after collecting the signals, they are sent to your backend in a protected way and are not altered while in transit?
What happens when no signals are collected?
What practical improvements will you get when you start using the client-side signals?
What if you have a compromised 3rd-party component? How can you detect a potential supply-chain issue?

These are all interesting questions, and the answers are coming in the second part of this article. Please stay tuned, and thank you for your interest and time to read this article.