Feature request: Detect CDP-driven browsers such as ZenDriver

Abierto
  • ¿Algo no está bien?
#4,687 7 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
28/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
go, python
Área
security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
15.1k
Forks
726
Merge medio
1 d 10 h
PR fusionados (30 d)
15

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de crowdsecurity/crowdsec

Todos los issues de crowdsecurity/crowdsec

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.