In part 1 of this series we covered various techniques for stealing session data from the Chrome (and Chromium-based) browsers. In this part we will cover how you can defend against these techniques using a combination of managed policies and endpoint monitoring.

If you’re in an enterprise environment, consider using Chrome Device Trust Connectors for further coverage by restricting access to sensitive applications to a single managed browser.

Hardening Chrome with Enterprise Policies⌗

In enterprise environments, Chrome (and Chromium variants) can be hardened using Chrome Enterprise Policies, making it possible to significantly reduce the browser’s attack surface.

By enforcing the policies described here, you can mitigate many of the previously described attack vectors.

Disable Developer Mode⌗

Threat actors and malware frequently abuse Developer Mode to side-load malicious extensions. These extensions don’t undergo the security vetting of the Chrome Web Store and can be designed to steal session cookies, log keystrokes, or inject malicious scripts into web pages.

Disabling developer mode, by settings ExtensionDeveloperModeSettings to 1, allows you you shut down a primary vector for installing persistent, hard-to-detect malware within the browser itself.

Setting this policy can also help to guards against the Silent Chrome extension installation technique.

If you’re feeling extra paranoid you may also want to disable the use of Developer Tools entirely by setting DeveloperToolsAvailability to 2.

Disable Remote Debugging⌗

Remote debugging creates a significant attack vector. Though designed for developers, threat actors and red teamers alike have widely abused this feature, using readily available tools to trivially extract sensitive data and inject malicious code into the browser.

Setting RemoteDebuggingAllowed to false disables use of the remote debugging feature in the browser.

Restrict Extension Permissions⌗

The ExtensionSettings policy makes it possible to control not only which extensions are allowed, but create granular policies to define which extensions can interact with which domains and with what permissions irrespective of what may defined in the extension manifest.

By setting the blocked_permissions option with an the ExtensionSettings policy, risky permissions such as those accessing the clipboard can be globally disabled.

Domain interaction can also be selectively controlled, either globally or per extension, by using the runtime_blocked_hosts and runtime_allowed_hosts options. This is typically done by globally setting runtime_blocked_hosts to include all sensitive domains, followed by per-extension use of runtime_allowed_hosts to whitelist a specific extension for one or more sensitive domains.

Disable Command-Line Extension Installs⌗

This policy gives you control over how extensions can be installed, going a step beyond simply blocking individual extensions, it allows you to block installations based on their type.

By setting ExtensionInstallTypeBlocklist to command_line it is possible to block command-line installations of extensions, via the --load-extension argument, while still allowing those installed from the Chrome Web Store.

This can serve as a reasonable middle ground between blocking the installation of all extensions, irrespective of their source, and allowing extensions from any source.

Policy Precedence⌗

Setting policy precedence correctly is critical to preventing policies from simply being overridden by having a platform policy take precedence over the cloud policy.

By default platform policies, which may not exist by default, will take precedence over a cloud policy - as a result any user able to write a correctly formatted policy to ~/Library/Application Support/Google/Chrome/Policy (or the Windows/Linux equivalent locations) can silently override any settings enforced by the Enterprise Policy.

Policy precedence can be controlled by setting the CloudPolicyOverridesPlatformPolicy policy to true

Other Policies to Consider⌗

Here are a few other high-impact policies for hardening Chrome against session theft and other attacks:

  • SafeBrowsingProtectionLevel: Setting this policy to 2 provides the most proactive protection against phishing, malware, and malicious downloads by sharing more security data with Google in real-time. Note that by enabling “Enhanced Protection” more data must be shared in Google, which may violate privacy policies.

  • PasswordManagerEnabled: Setting this policy to disabled disables the built-in password manager. In an enterprise setting this may be a way to encourages users to rely on a corporate password management solution that is often better suited for security and auditing and can prevent passwords being synchronised to personal devices.

  • SyncDisabled: Set to true to disable Chrome Sync. This can prevent a compromise on one device from automatically propagating to all other devices logged into the same Google account, e.g. via a malicious extension, and contains the blast radius of a stolen password or session token. This this is too aggressive, consider selectively disabling synchronised items via SyncTypesListDisabled.

  • SharedClipboardEnabled: When set to false, clipboard data cannot be shared between the browser and Android devices. If left unset this feature defaults to being enabled.

  • DefaultCookiesSetting: Set to 4 (Delete cookies when the session ends). This is an aggressive but effective measure against session token theft. It forces re-authentication for every browser session, ensuring that even if a token is stolen, its useful lifespan is extremely short.

  • RestrictSigninToPattern: This policy lets you define an approved pattern, using a regular expression, for Google accounts that are allowed to sign into the Chrome browser profile. If a user tries to sign in with an account that doesn’t match the pattern, the sign-in will be blocked.

Device Bound Session Credentials (DBSC)⌗

The foundation of authentication in web applications typically relies on some form of token, most commonly in the form of session cookies. The concept is simple; whoever possesses the token is trusted as the authenticated user - however this simplicity is also its greatest weakness. If an attacker can steal that token they can impersonate the owner of the token.

Device Bound Session Credentials (DBSC) are an evolution in browser security designed to solve this exact problem. Instead of a simple token, a DBSC is a “proof-of-possession” credential that is cryptographically locked to the specific device it was issued to.

How Do They Work?⌗

At a high level, the process uses public-key cryptography, often leveraging secure hardware already built into modern devices like a TPM (Trusted Platform Module) or Secure Enclave.

  1. Key Generation: When a user logs in, their device generates a unique pair of cryptographic keys: a public key and a private key. The private key is securely stored and never leaves the device.

  2. Binding at Authentication: The device sends its public key to the server during the login process. The server then issues a session credential (like a cookie) that is cryptographically bound to that specific public key.

  3. Proof of Possession: For every subsequent request to the server, the device uses its secret private key to sign a piece of the request.

  4. Verification: The server uses the public key it has on file to verify this signature. If the signature is valid, it proves the request is coming from the original device. If there’s no signature, or it’s invalid, the server rejects the request—even if the session token itself is correct.

This effectively renders most forms of session hijacking and cookie theft obsolete, however it is still an evolving area and has been subject to a number of bypasses (1, 2, 3).

Santa⌗

As an accompaniment to hardening the browser via policies, Santa FAA rules can also be created to further restrict access to processes reading sensitive browser data.

This post provides an example rule to protect the cookie database, however other locations including Secure Preferences, extension data, history, and bookmarks should ideally be protected.