Fraud teams are mainly focused on discovering fraud by reviewing historical data, examining flagged transactions that need human analysis and rolling them back or canceling them if fraud is identified. In contrast, security teams are generally forward-looking, seeking to defend their environment from every future attack, which necessitates removing the human element from the process and acting automatically in real-time.
The JS model works by inserting a script into your web application that “fingerprints” the user’s browser to differentiate between legitimate user activity and bot activity. When security solutions attempt to pinpoint anomalies across entire populations of large users or trends over extended periods of time, it’s common for them to use a combination of JS and a cookie to attempt to detect an automated attack. This mechanism requests that the client provide browser information so it can evaluate the user behavioral data from the session, such as whether mouse behavior is within the parameters of ‘human-like,’ in order to identify malicious automated activity or unwanted traffic.
Use Cases: Fraud vs. Security
The two primary use cases for JS-based detection are fraud prevention and bot detection solutions. In many cases, these activities often come down to verifying a known user is who they say they are vs. identifying a new user or a new device.
Limitations: Web Application Security
The biggest challenge with a JS-based approach to security is its practicality in the real world. Deploying it requires coordination across at least three organizations; development (build the integration), operations (ensure performance and availability) and security (monitor attacks). Sometimes, marketing and fraud teams are involved as well. The required coordination for a single remediation between multiple departments with differing priorities can take weeks, leaving websites, mobile applications, and APIs vulnerable in the meantime.
Lastly, browser makers are in the best position to address the bot detection problem, particularly since the bots are masquerading as their products, and we are seeing an increased amount of R&D in this area. For example, Google’s Invisible reCAPTCHA is a milestone in bot detection. The question then becomes: why do web app security vendors need to duplicate this functionality and execute the same detection twice on one client?
Limitations Mobile, IoT & API Attacks
In addition to the pitfalls of long remediation cycles mentioned above, solutions that rely on client-side code commonly provide a mobile SDK that the organization’s development team needs to test for behavior, performance, and compatibility with its host application. As with any mobile application, each CPU cycle and MB of memory consumed impacts the smartphone’s performance, data usage, and battery life. The organization must then build the integration, roll it out to each of its users through Google Play and Apple App Store, and make its best attempt to get customers to keep their mobile clients up to date. This is not a simple endeavor.
For IoT (including gaming stations) and API-based attacks, all of these points are moot. The good news is that there is no client-side code to integrate, and the bad news is that there is no client-side code to detect. All of the organizational and integration challenges mentioned above go away, but the security product’s server-side detection must be powerful enough to detect an attack without impacting your normal partners’ usage of your API.
And if the server-side code is smart enough to provide protection against botnet attacks, that warrants the question: “Why do we need to rely on client-side code for security in the first place?”