Feature request: Detect CDP-driven browsers such as ZenDriver

Aperta
  • Qualcosa non va?
#4,687 7 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
28/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
go, python
Ambito
security

Direzione di ricerca

Start by reproducing the reported bypass with Python 3.13 and zendriver==0.16.0 against a CrowdSec-protected endpoint using the default crowdsecurity/appsec-bot-challenge. Then read the existing browser fingerprinting and challenge behavior; the issue names no source files or tests. Done means a defined CDP-aware detection approach that identifies automation reliably while accounting for false positives from legitimate DevTools use.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area/bot-detection kind/enhancement needs/triage
What would you like to be added?

CrowdSec's browser bot protection (using default crowdsecurity/appsec-bot-challenge) can currently be bypassed by a browser controlled through the Chrome DevTools Protocol (CDP), for example using ZenDriver.

The important point is that this is not a simple HTTP-client or User-Agent spoofing scenario. ZenDriver launches a genuine Chromium browser and controls it through CDP. As a result, the resulting requests contain what appears to be a legitimate Chrome browser fingerprint and normal browser navigation headers.

For example, accessing a protected endpoint with ZenDriver currently reaches the application behind CrowdSec, is being challenged, succeeds the challenge and accesses the web page.

Reproduction

Using Python 3.13 and zendriver==0.16.0:

virtualenv venv
source venv/bin/activate
pip install zendriver

Then create a simple test script:

import asyncio
import zendriver as zd


async def main():
    browser = await zd.start()
    page = await browser.get("https://your.url.behind.crowdsec.bot.protection.com")
    await asyncio.sleep(10)
    await page.save_screenshot("browserscan.png")
    await browser.stop()


if __name__ == "__main__":
    asyncio.run(main())

When accessing a CrowdSec-protected endpoint, the request reaches the origin/application instead of being identified as an automated browser.

Observed request

The request looks essentially like a normal Chromium navigation:

Sec-Fetch-User: ?1
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br, zstd
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Upgrade-Insecure-Requests: 1
Priority: u=0, i
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Ch-Ua-Platform: "Linux"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36
Sec-Ch-Ua: "Not/A)Brand";v="99", "Chromium";v="148"
Sec-Fetch-Dest: document

Therefore, blocking based on individual request headers does not appear to be a viable solution.

Why this is interesting

ZenDriver differs from traditional Selenium/WebDriver automation because it communicates with Chromium through CDP.

This means that:

  • the browser is a real Chromium instance;
  • the HTTP request headers look like those generated by a real browser;
  • the browser can execute JavaScript normally;
  • ordinary User-Agent and Sec-Fetch-* checks do not reliably identify it;
  • the automation layer is not necessarily exposed through the traditional navigator.webdriver signal.

This appears to be a more general issue than ZenDriver specifically: CDP-controlled Chromium can potentially defeat a bot-detection mechanism that primarily relies on browser-side fingerprinting and conventional automation indicators.

Feature request

Would it be possible to add stronger detection for CDP-controlled or otherwise externally automated Chromium browsers?

In particular, it would be useful to investigate signals that remain observable from the browser despite the use of a genuine Chromium instance, rather than relying exclusively on HTTP headers or navigator.webdriver.

Potential areas to investigate could include:

  • CDP/DevTools-related browser-side signals
  • inconsistencies between the main document, iframes and workers
  • browser automation artifacts that survive in Chromium despite CDP control
  • timing/interaction characteristics associated with automated navigation
  • browser capability and API consistency checks
  • correlation between browser-side signals and server-side request behavior
  • mechanisms for detecting automated browsers that deliberately avoid traditional WebDriver fingerprints

Ideally, this would also cover browsers/tools that intentionally try to avoid automation detection, rather than only standard Selenium/Playwright configurations.

One may also check out https://github.com/cdpdriver/zendriver/issues?q=state%3Aopen%20label%3A%22bot-detection%22

Security impact

The practical impact is that an attacker can use a relatively small Python program to operate a full Chromium browser and access the application behind the CrowdSec protection without apparently triggering the browser challenge.

This is particularly relevant for:

  • scraping
  • credential-stuffing automation
  • automated account creation
  • application-layer abuse
  • vulnerability scanning
  • automated interaction with protected web applications

The attacker does not need to implement a custom HTTP stack or reproduce browser headers manually. A real Chromium instance is sufficient.

Expected behavior

A CDP-controlled Chromium session that exhibits characteristics of browser automation should ideally receive the same treatment as other automated clients, or at least contribute sufficiently strong signals to the bot score that additional verification/challenge is triggered.

At the same time, false positives are obviously important here, since legitimate users can have Chrome DevTools open or use browser extensions and other software that interacts with Chromium.

I'd therefore be interested in whether there are plans for CDP-aware bot detection, or whether the recommended approach is to combine the existing browser fingerprinting with additional server-side behavioral signals.

Why is this needed?

The practical impact is that an attacker can use a relatively small Python program to operate a full Chromium browser and access the application behind the CrowdSec protection without apparently triggering the browser challenge. The attacker does not need to implement a custom HTTP stack or reproduce browser headers manually. A real Chromium instance is sufficient.

Lingua principale
Go
Stelle
15.1k
Fork
726
Merge medio
2g 51m
PR unite (30g)
18

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di crowdsecurity/crowdsec

Tutte le issue di crowdsecurity/crowdsec

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.