Enhance your Application Security using Client-side signals – Part 2
Building upon the previous article, we'll now explore essential real use-case scenarios where leveraging Client-side signals can significantly bolster your application's security. But before we delve into these scenarios, let's look at the technical concepts underpinning them.
1) How can Client-side signals be collected?
Collecting Client-side signals can be achieved through various methods. In this article, we'll focus on the approach used at F5, which seamlessly gathers signals from web browsers and mobile applications without requiring additional software installations.
Web browsers are seen these days as a modern OS on their own. They work like a sandbox to protect the actual operational system from potential threats presented by web applications. This sandboxing approach limits what a web application can “see and touch” at the operational system level; however, through the use of purposed created Javascript, lots of small pieces of data can be collected from the three different vectors I mentioned in part one, which are Behavior, Environment, and Network.
A similar approach is used for mobile applications, where if the application is native for iOS or Android, an SDK must be used to collect these pieces of data.
Here's how the process unfolds: When a person accesses the application via a browser or mobile device, the browser or mobile app loads and executes the JavaScript or SDK to initiate session monitoring. Subsequently, real-time data is gathered as the individual interacts with the application.
2) How can you guarantee the signals are not spoofed while they are collected?
In today’s world, most business decisions are based on data, and the same applies to mitigation decisions. If the client-side signals collected during a session are spoofed or altered somehow, this could compromise anomaly detection and mitigation efforts, ultimately hindering the goal of enhancing application security. Compounding this challenge is the inherent accessibility of JavaScript code within browsers, making it relatively easy for adversaries to inspect and manipulate the signals being monitored.
To safeguard these signals, F5 has developed and patented a pioneering technology centered around code obfuscation, rendering reverse engineering virtually impossible. This technology is based on the idea of virtualization obfuscation, where a source program is compiled into a bytecode program for a bundled custom virtual machine. This virtualization mechanism ensures that an attacker cannot interpret the JS or SDK code and spoofs the signals in an attempt to circumvent detections.
Figure 1. Obfuscated Bytecode VM3) How is the telemetry transmitted safely?
Before the JS or SDK reaches its limit buffer, there must be a mechanism to send this data out to a backend to be analyzed and used for anomaly detection. There are different methods to send the data out.
On-Click: This method involves attaching the signals collected by the JavaScript (JS) or SDK when the user initiates specific transactions, such as logging in, checking out, or adding items to the cart. The attachment typically occurs in the form of an encrypted HTTP payload or within HTTP headers. By associating the data directly with user actions, this approach provides transaction-specific insights.
Out-of-Band Transmission: Alternatively, the JS or SDK can be configured to transmit telemetry data out-of-band as the user interacts with the application. This method enables continuous monitoring over an extended period, as the backend receives and normalizes session-related data in real time. By tracking the entire user journey, anomalies can be flagged even before specific transactions are triggered.
Both methods require hashing and encrypting the signals using an asymmetric encryption mechanism to protect the content of the data, as well as TLS for transport protection.
Figure 2. Traffic Flow4) What if no signals were collected?
The absence of client-side signals associated with a transaction indicates potential anomalies within the session. Let's delve deeper into this logic:
When designing a web application or mobile app for human interaction, it typically requires a software client, such as a web browser, to load the front end. This front end serves as the interface through which users interact to fulfill the intended use case of the application, and it's where client-side signals are collected.
Most tools used by malicious actors to exploit or abuse applications are command-line interface (CLI)-based. Examples include curl, python-requests, and others, which employ thin HTTP clients to craft custom HTTP requests in an attempt to bypass security measures on target web applications.
A critical limitation of these CLI-based tools is their inability to render JavaScript. Consequently, they cannot execute the JavaScript code responsible for collecting client-side signals, thereby preventing the appending or transmission of these signals to the backend for validation.
A checking mechanism that looks for client-side signals on all transactions should be configured to reject requests without the signals linked to them. This proactive approach helps mitigate potential threats from unauthorized or anomalous activities on the application.
5) What practical improvements will you get when you start leveraging client-side signals?
Leveraging client-side signals yields several practical improvements for application security and operational efficiency:
Noise Reduction: By discerning transactions initiated by genuine users from automated or malicious traffic, you can effectively eliminate noise generated by scanners, bots, and other non-human entities. This reduction in unwanted traffic optimizes resource utilization across your application stack, including computing resources, internet bandwidth, and database cycles.
Reconnaissance Protection: Identifying and distinguishing genuine user requests enables robust protection against reconnaissance techniques employed by malicious actors to probe for vulnerabilities. By confidently differentiating between legitimate users and potential threats, you fortify your application's defense mechanisms, safeguarding valuable assets and customer data.
Defense Against Denial of Service (DoS) Attacks: Client-side signals play a crucial role in mitigating certain forms of DoS attacks, such as GET Floods. Traditional security controls like Web Application Firewalls (WAFs) or Intrusion Prevention Systems (IPS) may struggle to differentiate between legitimate and malicious traffic, particularly when originating from diverse source IP addresses. Client-side signals provide a more reliable mechanism to identify and mitigate such attacks effectively.
Automated Fraud and Abuse Prevention: Malicious bots often target valuable assets within your application, including customer accounts, payment endpoints, inventory, and reward programs. By proactively leveraging client-side signals to detect and block these bots, you bolster application security and prevent fraudulent activities orchestrated by bad actors leveraging harvested data. This proactive approach helps safeguard both your business and your customers' interests, reinforcing trust and integrity within your ecosystem.
6) How can F5 help with your Client-Side Signals strategy?
As outlined in parts 1 and 2, using Client-Side Signals for Application Security is an effective strategy; it can prevent several types of threats to web and mobile applications that are targeted daily. It can also improve the efficacy of different security tools, and ensure that a real person is using your application, with a plus that you could even detect if this person is good or bad intended.
F5 has a range of solutions built around the concept of Client-Side Signals. These solutions are available to our customers as a self-managed or managed service.
F5’s Bot Defense solution comes in two tiers: Bot Defense Standard and Bot Defense Advanced. Both tiers rely entirely on collecting Client-Side signals to determine whether a request is automated or not. The primary distinction lies in the inclusion of managed services within the Advanced tier. The managed services team is responsible for proactively analyzing the signals and creating countermeasures to block the more advanced automation. This is a highly tactical and valuable service.
Figure 3. F5 Bot DefenseYou can find more details about Bot Defense solutions here.
Once your web application is protected against bad automation, the next step is to harness Client-Side signals to protect against bad intended persons. Enter F5 Data Intelligence, a solution designed to provide real-time access to dozens of the signals gathered from your customer’s journeys. These signals are made readily available to you either as a file feed or streamed directly to your data lake, offering visibility into user interactions. By leveraging this rich dataset, you can train machine learning models to enhance your application security and bolster fraud detection.
Figure 4. F5 Data IntelligenceYou can find more details about F5 Data Intelligence here.
I hope reading this content was helpful for your research.
Thank you.