web-dev-qa-db-fra.com

Traiter avec CloudFlare: cf_chl_jschl_tk & cf_chl_captcha_tk?

Le problème:

Lorsque mon site Web est défini sur mode "Je suis attaqué" , une fois qu'un utilisateur passe l'écran CloudFlare, il est redirigé vers mon site Web avec un paramètre de requête volumineux et plutôt long:

?__cf_chl_jschl_tk__=63c51316f61a63e46f1639d6cf43f9d9b536adea-1587754610-0-AV-peahelegQeMeSrc_4ZJBUq47gdkX_QiS2eERoRTEODUjwbib2MM_73nQDAhukLbkspNpj01mv-Z-JteR4MpY4LUMm-yLJrPQKTX74DGYbZIs2utbp3_q4uozgzKpqcax10YESVKDhZgaWQYHGqBL9koIoasVOzKyvU7VQuKT1Nieo-i8DdXrV0IQf-nyI8KgWnxhYSVBOc-4WNrZzHQlEXFOpV45AGs10aMJyrs376HLRhNdV05MCj8oqMrexuQDtY7B3p7riHByYdB7GIgc

enter image description here

Pourquoi c'est mauvais:

  • Lien laid partagé en ligne - (J'ai déjà vu cela se produire plusieurs fois)
  • Je ne peux pas rediriger les paramètres get - (Ils ne sont pas accessibles pour vérifier s'ils sont configurés pour rediriger)
  • URL laides - (Nous passons beaucoup de temps à écrire des URL propres/jolies pour nos applications)
  • Les données POST sont définies sur la page - (vous ne pouvez pas actualiser sans 'resoumettre' l'authentification CF)

Solution proposée:

La façon dont je vois pour éviter cela serait de vérifier si les paramètres get sont définis, puis de rediriger vers la même page avec les paramètres supprimés. (Assurez-vous de ne perdre aucun autre paramètre de requête si défini)

J'ai écrit une fonction pour y parvenir:

function checkAndRemoveCloudFlareParams() {
    if (isset($_GET['__cf_chl_jschl_tk__']) && ! empty($_GET['__cf_chl_jschl_tk__'])
     || isset($_GET['__cf_chl_captcha_tk__']) && ! empty($_GET['__cf_chl_captcha_tk__'])) {

        $new_uri = '?';
        $uri = explode('?', $_SERVER['REQUEST_URI']);
        $uri = $uri[0];

        // Get any other params to put back on later
        foreach ($_GET as $key => $var) {
            if ($key !== '__cf_chl_jschl_tk__' && $key !== '__cf_chl_captcha_tk__') {
                $new_uri .= $key . '=' . $var . '&';
            }
        }

        if ($new_uri !== '?') {
            $new_uri = rtrim($new_uri, '&');
            $uri .= $new_uri;
        }

        header('Location: ' . $uri);
        die;
    }
}

Lorsque je teste cela localement en entrant manuellement les paramètres _GET, cela fonctionne. Cependant, lorsqu'ils sont déployés sur mon site en ligne, les paramètres de requête _GET ne sont pas là ou disponibles pour accéder lorsqu'ils sont chargés directement à partir de CloudFlare. Je crois que CloudFlare ajoute les paramètres après le chargement de la page? Peut-être par le biais d'états Javascript Push (?) Est-ce que quelqu'un d'autre a déjà traité de cela?

J'ai déjà parlé à CloudFlare de cela et ils ont dit que c'est ainsi que cela fonctionnera à partir de maintenant car il y avait des problèmes avec leur ancien système. Malheureusement, ces paramètres de requête sont très laids et me font commencer à Twitch par ennui de le voir tout le temps;)

Des conseils sur la façon de gérer ces paramètres et de s'en débarrasser? Sincères amitiés

phpcloudflareddos
5
Jack

Cloudflare est un proxy inverse distribué. Toutes vos demandes et réponses sont transmises via le proxy inverse de Cloudflare en texte clair. Le __cf_chl_jschl_tk__ ( [~ # ~] c [~ # ~] fort f lare ch a l lenge/ [~ # ~] j [~ # ~] ava s cript ch a l longueur t o k fr) est ajouté aux URL d'emplacement de redirection au niveau du proxy et serait supprimé au niveau du proxy avant qu'il n'atteigne votre site Web.

Vous pouvez essayer de vous débarrasser du jeton avec Javascript, cependant, il est important de comprendre les conséquences. Si un jeton est manquant dans une demande, Cloudflare serait plus susceptible de faire subir à vos utilisateurs des défis anti-bot encore et encore, conduisant à une mauvaise expérience utilisateur.

La probabilité exacte de le faire reste cependant un mystère, car les services d'atténuation DDoS ne documentent généralement pas ouvertement ces détails.

1
ximaera