How to Defend Against WebRTC Skimmers Bypassing CSP in E-Commerce

Cybersecurity researchers have identified a sophisticated evolution in the web skimming landscape (often associated with Magecart-style attacks). A new malware strain has been observed utilizing WebRTC (Web Real-Time Communication) data channels to exfiltrate payment information.

This technique is particularly concerning for defenders because it bypasses Content Security Policy (CSP), a standard defense mechanism designed to restrict the resources a browser can load and the data it can send to unauthorized destinations. By leveraging peer-to-peer data channels inherent in the WebRTC API, attackers can bypass traditional HTTP-based security controls, creating a covert tunnel for stolen credit card data.

Technical Analysis

WebRTC is a standard feature in modern browsers that enables real-time communication (audio, video, and data) directly between browsers and devices. While essential for legitimate applications like video conferencing, it exposes a surface area that attackers are increasingly exploiting.

The Attack Vector:

1. Initial Compromise: Attackers compromise an e-commerce server (via supply chain attack, credential theft, or plugin vulnerability) to inject a malicious JavaScript skimmer.
2. Bypassing CSP: Traditional skimmers use XMLHttpRequest or fetch to send data to a rogue domain. Defenders block this using CSP headers like connect-src 'self'. However, this new skimmer utilizes the RTCPeerConnection API. Since data channels are often treated differently than standard HTTP requests, they can slip through loosely configured CSP policies that focus strictly on HTTP/S traffic.
3. Data Exfiltration: The skimmer captures payment details from input fields and establishes a WebRTC data channel to a receiver controlled by the attacker, effectively tunneling data out under the nose of security filters.

Affected Systems:

• E-commerce platforms utilizing checkout pages (Magento, WooCommerce, Shopify custom builds, etc.).
• Browsers with WebRTC enabled (modern Chrome, Firefox, Safari, Edge).

Severity: High. This leads to direct financial loss, PCI-DSS compliance violations, and reputational damage.

Defensive Monitoring

Detecting WebRTC skimmers requires a shift in strategy. Since the exfiltration may not appear as a standard HTTP POST to a suspicious domain, defenders must hunt for the presence of the code or analyze network traffic anomalies.

1. Web Server Code Scanning

The first line of defense is identifying the malicious script on the server. Use the following Bash script to scan your web directories for suspicious usage of the WebRTC API, which is rare in standard payment processing libraries.

#!/bin/bash

# Define the web root directory
WEB_ROOT="/var/www/html"

# Search for WebRTC API calls in JS files
echo "Scanning for WebRTC API usage in $WEB_ROOT..."

grep -r -i -n "RTCPeerConnection" "$WEB_ROOT" --include="*.js"
grep -r -i -n "createDataChannel" "$WEB_ROOT" --include="*.js"

echo "Scan complete. Review the results for unauthorized payment-related scripts."

2. KQL for Microsoft Sentinel (Network Traffic Analysis)

While WebRTC traffic is difficult to classify via HTTP logs, you can hunt for high-entropy data leaving the network or connections to known STUN/TURN servers that are unexpected in your environment. The following query hunts for network connections that might indicate P2P or tunnelling behavior originating from your web servers.

kqln DeviceNetworkEvents

| where Timestamp > ago(7d)

// Focus on the web servers or specific devices hosting e-commerce

| where DeviceName in ("WebServer01", "WebServer02") 

// Look for UDP traffic common in WebRTC or connections to non-standard ports

| where NetworkProtocol == "UDP" or RemotePort in (3478, 5349, 19302, 19303)

// Exclude known legitimate CDNs or STUN servers if necessary

| where RemoteUrl !contains "google.com" and RemoteUrl !contains "cloudflare.com"
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteUrl, RemotePort, SentBytes, ReceivedBytes
| summarize Count=count(), TotalSentBytes=sum(SentBytes) by RemoteUrl, RemotePort, InitiatingProcessFileName
| order by TotalSentBytes desc

Remediation

To protect your organization from WebRTC-based skimmers, a multi-layered approach is required.

1. Implement Strict CSP and Permissions Policy CSP is still effective, but it must be configured correctly. Ensure your CSP headers explicitly block WebRTC if it is not required for your business function.

• CSP Configuration: Ensure connect-src is strictly limited to your payment gateway and necessary API domains.

• Permissions Policy (formerly Feature-Policy): Use the HTTP Permissions-Policy header to explicitly disable WebRTC for your checkout pages if it is not needed.

  http Permissions-Policy: interest-cohort=(), camera=(), microphone=(), geolocation=(), display-capture=(), "encrypted-media"=(), "picture-in-picture"=(), "autoplay"=(), "payment"=(), "usb"=(), "serial"=(), "bluetooth"=(), "sync-xhr"=(), "idle-detection"=(), "focus-without-user-activation"=(), "clipboard-read"=(), "clipboard-write"=(), "gamepad"=(), "magnetometer"=(), "accelerometer"=(), "gyroscope"=(), "vr"=(), "speaker-selection"=(), "xr-spatial-tracking"=(), "direct-sockets"=(), "screen-wake-lock"=(), "hid"=(), "window-management"=(), "web-share"=(), "compute-pressure"=(), "interest-cohort"=(), "publickey-credentials-get"=(), "run-ad-auction"=(), "join-ad-interest-group"=(), "attribution-reporting"=(), "browsing-topics"=(), "private-aggregation"=(), "shared-autofill"=(), "local-fonts"=(), "execution-while-out-of-viewport"=(), "execution-while-not-rendered"=(), "form-submit"=(), "document-domain"=(), "pointer-lock"=(), "fullscreen"=(), "user-select"=(), "encrypted-media"=(), "picture-in-picture"=(), "autoplay"=(), "payment"=(), "usb"=(), "serial"=(), "bluetooth"=(), "sync-xhr"=(), "idle-detection"=(), "focus-without-user-activation"=(), "clipboard-read"=(), "clipboard-write"=(), "gamepad"=(), "magnetometer"=(), "accelerometer"=(), "gyroscope"=(), "vr"=(), "speaker-selection"=(), "xr-spatial-tracking"=(), "direct-sockets"=(), "screen-wake-lock"=(), "hid"=(), "window-management"=(), "web-share"=(), "compute-pressure"=(), "interest-cohort"=(), "publickey-credentials-get"=(), "run-ad-auction"=(), "join-ad-interest-group"=(), "attribution-reporting"=(), "browsing-topics"=(), "private-aggregation"=(), "shared-autofill"=(), "local-fonts"=(), "execution-while-out-of-viewport"=(), "execution-while-not-rendered"=(), "form-submit"=(), "document-domain"=(), "pointer-lock"=(), "fullscreen"=(), "user-select"=(), "webrtc"=()

2. Enforce Subresource Integrity (SRI) Use SRI for all third-party scripts (payment gateways, analytics, tracking pixels). This ensures that if a script is modified, the browser will refuse to load it.

<script src="https://code.jquery.com/jquery-3.6.0.min.js" 
        integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4=" 
        crossorigin="anonymous"></script>


**3. Client-Side Monitoring**

Deploy Client-Side Defense solutions that monitor the behavior of JavaScript in the DOM. These tools can detect when a script attempts to access payment inputs or establish unauthorized network connections, regardless of the protocol used.

4. File Integrity Monitoring (FIM) Ensure strict FIM is enabled on your web servers. Alert immediately if any JavaScript files within the document_root are modified or if new files are created unexpectedly.

Related Resources

Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub