Connections to remote sites cannot be intercepted

• Component: WebKitGTK
• Status: NEW ---

[Albrecht Dreß]

Created attachment 467194 [details]
sample application and HTML test input to reproduce the issue

OS version: Debian Bookworm/x86_64
Webkit GTK package: libwebkit2gtk-4.1 v. 2.40.3-2~deb12u2

Overview:
=========
Even if the request to access a remote site is intercepted in the WebPage::send-request signal handler, a socket connection is opened and –if applicable– the TLS handshake is performed.  If the access is triggered e.g. by malicious HTML content in an e-mail, this will already give the attacker valuable information, so this might (should?) be considered a security bug.

Steps to Reproduce:
===================
See the attached sample code package "sample.tar.gz" (note: tested on Debian Bookworm, should work similarly on other Linux systems):

(1) Unpack the sample
Unpack the package, cd into the folder “sample”, and say “make”

(2) Log network traffic
In an other terminal, start “tcpdump” or a similar tool to listen on ports 80/tcp and 443/tcp, e.g.:

  sudo tcpdump -vvv -K -X \( tcp port 80 or tcp port 443 \)

(3) Run test application
In “sample” run the application to display the included HTML file:

  ./samp-main Test.html

The application prints (time stamps omitted)

--8<-------------------------
webkit_web_extension_initialize: done!
web_page_created_cb: page 10 created for (null)
send_request_cb: uri 'http://ftp.de.debian.org/debian/doc/00-INDEX' caught, redirect to 'about:blank', stop event emission
--8<-------------------------

The HTML contains two “link” containers (preconnect, stylesheet) triggering this event without any further user interaction.  The tcpdump log shows a connect() to the remote site.

(4) Click link
Click on the link in the window.  The application prints

--8<-------------------------
send_request_cb: uri 'https://www.posteo.de/' caught, redirect to 'about:blank', stop event emission
--8<-------------------------

The tcpdump log shows that the connection opened in step (3) is closed, a new connect() to www.posteo.de is opened, and the full (!) TLS handshake is performed.

The sample package contains the tcpdump log in the file tcpdump.log:
* start the test application at 19:06:59
* click the link at 19:07:39

Expected Results:
=================
No connection to the remote site must be opened, and in particular no TLS handshake must occur if the WebPage::send-request signal handler redirects the request to a different location.

Speculation: the connection is established before the WebPage::send-request is emitted, resulting in this behavior.