25

I sometimes want to run untrusted JavaScript, mainly for CTFs. It can be obfuscated JavaScript code or something like JSFuck. The point is, I know nothing about the code and just want to quickly see its output.

Of course, I don't want the JavaScript code to affect the other open pages/tabs. We can assume no exploit is available for the JavaScript interpreter/compiler/browser. Of course, I can do static analysis on the code, but that takes a lot of time and I may prefer to do dynamic analysis and just look at the output.

What's a good way to run arbitrary JavaScript code?

Peter Mortensen
  • 895
  • 5
  • 10
ChocolateOverflow
  • 3,482
  • 4
  • 18
  • 35
  • 2
    The answers below by mentallurg and CBHacking do a good job of describing some of the possible threats (more-or-less in increasing order of paranoia) and what you can do to mitigate those threats. As expected, the more paranoid you are, the more effort it takes to mitigate. If you are really paranoid, you might be best off firing up a spare computer using a Ubuntu (or the distro of your choice) live-bootable USB, and opening the web page using the browser there. – mti2935 Dec 28 '20 at 13:38
  • 1
    Fire up a virtual machine and run it in a browser. Beware though, the JS might seem innocuous because you haven't triggered the correct environment for it to misbehave so it could very well behave differently in your main browser. – MonkeyZeus Dec 28 '20 at 15:00
  • Put a breakpoint on the script and step through it line by line with a debugger if it's reasonably short and you just want to understand what's going on. – Bergi Dec 28 '20 at 21:40
  • In this case, I'm not really paranoid. Since I already do CTFs in a VM anyway, I'm just looking for ways to easily untrusted JS while containing it within a single tab, meaning I just don't want it trying to grab data from other tabs or cookies. The answer(s) I'm looking for should only concern the browser and not containerizing technologies like docker & VMs. – ChocolateOverflow Dec 29 '20 at 07:04
  • 7
    What is CTF? Capture the flag? Cut-through forwarding? The undocumented Windows protocol involved with the Microsoft Text Services Framework? Counter-terrorist financing? Or something else? – Peter Mortensen Dec 29 '20 at 16:13
  • 2
    @PeterMortensen https://en.wikipedia.org/wiki/Capture_the_flag#Computer_security – Dan M. Dec 29 '20 at 16:45
  • My immediate thought for this question was "run it on someone else's server" – Mooing Duck Dec 29 '20 at 21:01

5 Answers5

33

It depends on what risks are acceptable for you. For some people running browser with a separate profile is sufficient. Some would run it within a separate Docker container. The others would run it within a virtual machine like VMware, Virtual Box or QEMU.

mentallurg
  • 12,418
  • 5
  • 36
  • 50
19

Assuming no exploits exist for the browser - which is a dangerous assumption in some ways, but is also kind of the default assumption any time we load a web page with scripting enabled - just use a private/incognito window and the browser's dev tools, on a page with no origin of interest ([[about:blank]] or similar usually works fine).

That way, the script can't leverage any stored tokens (cookies, etc.) to learn anything about your browsing or to attack any sites you're signed into with XSS or CSRF or similar. It already couldn't read responses or page content from other sites; the dev tools are still subject to same-origin policy. It can send requests (potentially exposing your IP address, user-agent string, and similar), but they will be otherwise anonymous and it can't access the responses.

CBHacking
  • 48,401
  • 3
  • 90
  • 130
  • 3
  • private/incognito does not make much difference for script analysis. 2) "it can't access the responses" - this is not quite correct, it can be true only for web sites that require same origin. Many web sites allow intentionally arbitrary origins.
    • – mentallurg Dec 28 '20 at 17:11
  • 2
    @mentallurg 1) private/incognito prevents cookies and saved data change/read. 2) That's true for every website. – not my real name Dec 28 '20 at 19:16
  • 1
    @mentallurg ACAO:* isn't that common. It also just does not work for authenticated requests (which these of course aren't going to be if you use incognito). But yes, the script would (probably) be able to see those responses (unless using an About page as the origin means the origin is treated as null in which case even * might not match). That's almost certainly not a security threat, though; the attacker could make the same request (and get the response) from their own machine, differing only in source IP. – CBHacking Dec 28 '20 at 19:21
  • 4
    Thea ability to make requests is a powerful tool. For example, it may scan your local subnet for potentially vulnerable devices accessible over http(s) (e.g. printer, router or IoT device admin pages) and send the outputs of the scan to an attacker, thus providing them access to things that aren't accessible from public internet because the network connections are running from your workstation. It's plausible to spray default credentials at such devices (often unsecured because they are accessible only from "inside") and automatically exploit them from such javascript. – Peteris Dec 29 '20 at 08:59
  • A "throw away" profile on Firefox would be better. But a low depends on what sort of output and interaction OP expects from the script... zhe doesn't explicitly say that it requires a browser-like DOM. – Mark Morgan Lloyd Dec 29 '20 at 19:46