CISSP 9.4 - Client-Based Systems

This episode of the ISC2 Certified Information Systems Security Professional (CISSP) exam prep series turns the spotlight from the server to the endpoint, continuing Domain 3. Users click all day, and their browsers run other people’s code with every page they open — this session looks at how that code is delivered, why it deserves caution, and how the endpoint is hardened against it.

Frequently Asked Questions

What is a client-side attack?

It is any attack that targets the client itself rather than the server. Most people picture the server as the prize, but here the client, or a process running on it, is the bullseye — a classic example is a malicious website that pushes harmful code into a vulnerable browser. These attacks can ride any communication protocol, and even the client’s local caches can be poisoned.

What is mobile code, and why do applets cut both ways?

Mobile code is a small, self-contained program sent from a server to run on the client, and an applet is exactly that — code that executes independently on your machine. Offloading work to the client frees the server, speeds up the response, and can keep the user’s input private by processing it locally. But any time you run someone else’s code, you risk it being malicious or flawed, and short of reading it line by line, you cannot be sure it hides no trojan or backdoor.

Why does JavaScript deserve special caution?

JavaScript is the most widely used web scripting language, embedded directly inside the pages you visit and downloaded automatically with them. Because the script arrives inside the page delivered to your browser, a threat actor can build a convincing fake site and tamper with that code to steal or clone your credentials. Attackers have also found ways to break out of the protections meant to contain it, so any script from an untrusted source is a genuine risk to your system.

How do browsers contain JavaScript?

Browsers run scripts inside a sandbox that limits them to web-related actions, and they enforce a same-origin policy that blocks a script from reaching content from a different origin — the combination of protocol, domain, and port. On top of that, you keep browsers updated, lean on hardened script libraries on the server side, and deploy a content security policy that rigidly enforces those origin rules. Turning JavaScript off entirely would break most of the web.

How do local caches get poisoned?

A browser stores downloaded files in a local cache for reuse, and certain attacks can trick the client into saving content that was never part of the page you asked for. Once a cached item is poisoned, even a legitimate page that calls on it will trigger the malicious content. Since cache defaults favor speed over safety, tighten them: shorten retention, shrink the cache size, disable content preloading, and clear cookies and cache on exit or on a schedule.

Reference: This article is based on concepts discussed in CISSP 9.4 - Client-Based Systems.