JSDom improperly allows the loading of local resources. Modern browser best practices dictate that the loading of local resources should be disallowed by default.
From documentation, JSDom does not, by default, load any subresources. Users must enable the loading of resources/subresources. For example, when creating a new JSDOM object, the resources item can be set to "usable" to allow the loading of external resources:
const dom = new JSDOM(source, {url: "http://localhost:8080/", resources: "usable"});
The issue here is that this setting also enables the loading of local resources. For example, the following code snippet verifies that JSDOM is attempting to access a local resource by using a non-existent file to throw an error:
const jsdom = require("jsdom");
const { JSDOM } = jsdom;
source = '<iframe src="file:///does_not_exist" />';
const dom = new JSDOM(source, {url: "http://localhost:8080/", resources: "usable"});
console.log(dom.window.document.body.parentElement.outerHTML);
Output when running the above:
~/r/b/u/pocs ❯❯❯ node -v; npm -v; npm list | grep jsdom;
v15.8.0
7.5.1
pocs@ /Users/user/research/browser/jsdom/pocs
└── [email protected]
~/r/b/j/pocs ❯❯❯ node local_resources.js
<html><head></head><body><iframe src="file:///does_not_exist"></iframe></body></html>
Error: Could not load iframe: "file:///does_not_exist"
at onErrorWrapped (/Users/user/research/browser/jsdom/pocs/node_modules/jsdom/lib/jsdom/browser/resources/per-document-resource-loader.js:38:19)
at Object.check (/Users/user/research/browser/jsdom/pocs/node_modules/jsdom/lib/jsdom/browser/resources/resource-queue.js:72:23)
at /Users/user/research/browser/jsdom/pocs/node_modules/jsdom/lib/jsdom/browser/resources/resource-queue.js:124:14
at processTicksAndRejections (node:internal/process/task_queues:94:5) [Error: ENOENT: no such file or directory, open '/does_not_exist']
{ errno: -2, code: 'ENOENT', syscall: 'open', path: '/does_not_exist' }
While this issue alone is not terribly severe, when paired with having scripts enabled (runScripts parameter being set to "dangerously"), this could allow these local resources to be acted upon in malicious ways, such as exfiltrating sensitive information. We understand that the documentation warns against enabling this feature on untrusted input, but many downstream libraries and applications depend heavily on this feature (such as zombie.js). In other substantially more complex applications, it's possible that other exfiltration vectors could be possible without the addition of enabling scripts, such as side channel attacks via CSS requests. We understand this latter scenario is highly unlikely, but bring it up to illustrate that simply leaving scripts disabled is not necessarily a mitigation.
We highly recommend adding an additional parameter such as "localResources" to enable this functionality alongside the existing "resources" parameter. For example, to enable local resources in Google chrome, it must be launched using the "--allow-file-access-from-files" flag.
Note: The maintainer(s) of JSDom dispute this finding and disagree that it is a security concern. From the maintainer: " When you explicitly opt in to loading of data via resources: "usable", you are opting in to exfiltration. And when you explicitly opt in to script execution with runScripts: "dangerously", you are opting in to running arbitrary Node.js code on your machine. "