There is a common, yet dangerous, tactic used by some of the biggest legacy vendors in the Salesforce ecosystem. Even Salesforce themselves have been guilty of leveraging it at one time or another within internal add-on products such as Salesforce DevOps Center! 😱

It’s called Session Hijacking, and it’s likely happening in your org right now without you knowing it.

The Problem: Grabbing Session IDs & Sharing Them Externally

Many legacy managed packages bypass modern security protocols by grabbing a user’s Session ID via a Visualforce page and sending it to an external server. This allows the vendor to hit Salesforce APIs later on the user’s behalf.

While usually not done with malicious intent, it creates a massive vulnerability: if that external server is compromised, your Salesforce data is wide open.

Moreover, within login history the requests will appear to come directly from an individual user rather than through the vendor on behalf of a user.

How to Detect It

First, if you entrust a vendor with API access to infrastructure as critical as Salesforce, you should certainly request they provide documentation on their architecture to ensure they are not engaging in session hijacking.

Beyond that, you can audit vendors’ managed packages on your own, searching specifically for Visualforce pages containing this specific syntax:

{!$Api.Session_ID}

The logic will be visible because, unlike with Apex, Visualforce code in a managed package isn’t hidden from subscribers.

This is a clear sign the vendor is employing session hijacking instead of leveraging industry-standard OAuth flows.

Even if this appears to be a Visualforce page you never visit, be warned that Apex can render Visualforce pages in memory, so you are still at risk.

It’s also worth mentioning that vendors can leverage Apex directly to get a user’s session id through:

UserInfo.getSessionID()

However, since Lightning session ids are (by design) not API-enabled they will most likely be leveraging Visualforce in some capacity–if not using the syntax noted above directly, at least in order to initiate the transaction so that the session id grabbed via Apex will be API-enabled.

If you find a vendor’s Visualforce page that looks to be engaging session hijacking, reach out right away to encourage them to move to more secure methods of enabling API access.

How to Block It (The 60-Second Fix)

The good news? You don’t have to wait for vendors to update their code. You can kill this vulnerability in your Session Settings right now.

1. Go to Setup > Session Settings.
2. Look for either: Lock sessions to the IP address from which they originated or Enforce login IP ranges on every request
3. Enable either of those settings and hit Save.

Why this works: Once enabled, even if a vendor (or a hacker) steals a session it, it becomes useless the moment they try to use it from a different IP address (like their own external server).

Warning

Although enabling either of the settings listed above would prevent session hijacking, they should NOT be enabled without first understanding their impact. If you enable Lock sessions to the IP address from which they originated it would break integrations from vendors that rotate their server’s IP address and it would also cause significant issues for mobile users. Enforcing login IP ranges on every request is a better long-term strategy, especially if you have already set up profile-based IP restrictions. It is important to first undergo significant testing within a sandbox before enabling either of these settings in production.

Deeper Dive

Salesforce recognizes the dangers of session hijacking and has taken steps to prevent it.

Salesforce users browser fingerprinting to identify devices and if they notice a significantly different fingerprint using the same session id they will lock it down.

This is done for all orgs, but for those with Salesforce Shield or Event Monitoring additional investigation into hijack attacks can be made by querying the SessionHijackingEvent and SessionHijackingEventStore objects.

By the end of Februrary, Salesforce will also remove the ability to send session ids in outbound messages.

In the following video I provide a walkthrough of blocking session hijacking by enabling the Lock sessions to the IP address from which they originated.