Wie man ("bad") Bots blocken kann - Neuer Versuch

[supervisior]

Was ist denn jetzt in dich gefahren?! Das ist doch eine legitime Frage. Die zielte auf eine Balance zwischen "zu viel blocken" und "zu wenig blocken" ab. Anders gefragt: Ist es dir wichtiger, dass alle Bots geblockt werden, oder dass kein menschlicher Nutzer geblockt wird?

In mich ist nichts gefahren, allerdings hat Deine letzte Reaktion (vor einigen Monaten) zu diesem Thema nicht wirklich die Bereitschaft erkennen lassen, dass Du bereit wärst das Thema wenngleich kontrovers zu diskutieren. Und das hindert mich daran speziell auf Deine Kommentare zu reagieren.

Ich gebe zu, dass mein ursprünglicher Lösungsansatz wenig praxistauglich war. Inzwischen habe ich diese Lösung aber so weit perfektioniert, sodass diese zumindest mir genügt. Die Frage ist nun, wie lässt sich ein Filter erstellen, der sich auch universell verweden lässt, so dass auch der vermeintliche "Dummy ihn anwenden kann?

Nehme daran TEIL oder lasse es.

[supervisior]

Es können auch schon lange keine HW Infos mehr ausgelesen werden. Und wenn du den ViewPort meinst, den gibt es in jeder erdenkbaren Auflösung.

Richtig, aber immer nur auf Basis dessen, was der Client liefert. Und wenn im Falle der Auflösung diese keinen logischen und v.a. realen Wert zurückliefert, dann ist das maßgebend. Also was ist (Dein) Problem?

[Hanzo2012]

Um das Ganze hier nochmal zu verdeutlichen, es geht nicht darum meine Lösung zur verhackstücken und und als Ganzes Frage zu stellen.

Das habe ich nicht getan. Ich habe geschrieben, dass das wahrscheinlich die allermeisten 08/15-Bots erwischt, und dass ich das selbst ausprobieren, hier berichten und ggf. auch meinen Code teilen werde.

Es geht wenn überhaupt hier eine Diskussion anzuregen, wie man meine Lösung entweder verbessern kann oder die Einschränkugen aufzuzeigen.

Einschränkungen habe ich aufgezeigt.
Mein Verbesserungsvorschlag war, nicht mit Ausnahmen für z. B. Safari zu arbeiten (da es zu viele Browser da draußen gibt, von denen ich noch nie gehört habe), sondern den Test auf diejenigen Browser zu beschränken, von denen man mit Sicherheit weiß, dass sie die Header senden, sofern sie echt sind. Genau das werde ich tun und Rückmeldung geben.

Wenn du meine Kritik als Angriff auf dich verstehst, dann sei versichert, dass dies nicht meine Absicht war. Schwamm drüber über diese alte Geschichte ...

[supervisior]

@Hanzo2012

Ich halte es für den falschen Ansatz nur Positivlisten zu verwenden. Der 0815 Webseitentreiber ist damit schlichtweg überfordert und ihm wird abverlangt etwas zu tun wovon er keine Ahnung haben kann und welche Auswirkungen es hat. Ich gehe vom worst case aus und dieser einen Webseitenbetreiber beschreibt, der maximal weiß, wie er seine Produkte/Inhalte im Internet veröffentlichen kann. Angesichts des Verbreitungsgrades von Wordpress sind das mind. mehr als als 50% aller Webseiten.

Mit Positivlisten zu arbeiten, würde bedeuten mit herkömmlichen Methoden zu arbeiten, also IP Adresse und User Agent. Letzeres ist in hohem Maße fehlertolerant, also warum damit arbeiten?!

[Hanzo2012]

Da hast du mich falsch verstanden.

Dein Vorschlag lautet:
Blockiere, wenn kein Sec-Fetch-Header gesetzt ist, außer wenn der User Agent in der Negativliste/Ausnahmenliste [Safari, Chrome < 76, Edge < 79, Firefox < 90, Opera < 63, ...] enthalten ist.
Diese Negativliste müsste idealerweise alle alten/obskuren Browser sowie alle erwünschten Bots aufführen, die keine Sec-Fetch-Header senden. Davon gibt es wahrscheinlich tausende, die schwer zu erfassen sind. Heutzutage hat doch jeder Toaster einen eingebauten Browser.

Mein Vorschlag lautet:
Blockiere, wenn kein Sec-Fetch-Header gesetzt ist, aber nur dann, wenn der User Agent in der Positivliste [Chrome >= 76, Edge >= 79, Firefox >= 90, Opera >= 63, ...] enthalten ist.
Diese Positivliste müsste idealerweise alle Browser enthalten, die Sec-Fetch-Header senden.
Eine zusätzliche Negativliste für bekannte "gute" Bots, die zwar sagen, dass sie Chrome >= 76 sind, aber trotzdem keine Sec-Fetch-Header senden (z. B. Googlebot, Bing-Bot), bräuchte man wohl trotzdem noch ...

Der Ansatz mit der Positivliste hat den Vorteil, dass es unwahrscheinlicher ist, dass ein legitimer Nutzer oder erwünschter Bot blockiert wird.

Wenn in deiner Negativliste etwas fehlt, dann führt das dazu, dass potenziell legitime Nutzer oder erwünschte Bots blockiert werden (nicht gut, im schlimmsten Fall existenzbedrohend, siehe unten). Wenn in meiner Positivliste etwas fehlt, dann führt das dazu, dass potenziell mehr Bots durchkommen (auch nicht schön, aber damit kann man leben).

Aber hier noch ein praktisches Beispiel, warum eine Negativliste gefährlich ist: Wer einen Shop betreibt und Zahlungen via PayPal akzeptiert, der hat ein Script auf seiner Seite, das von PayPal aufgerufen wird, wenn eine Zahlung eingeht. Damit wird dem Shop Bescheid gegeben, dass eine Bestellung bezahlt wurde. Ich hab's nicht getestet, aber ich würde darauf wetten, dass PayPal beim Aufruf des Scripts keine Sec-Fetch-Header mitsendet. Wenn du daran nicht gedacht hast und keine Ausnahme für PayPal in deiner Negativliste hast (oder wenn PayPal irgendwann mal den User Agent ändert), dann wird PayPal blockiert, was dann dazu führt, dass der Shop nicht mehr richtig funktioniert.

Weitere (wichtige/nützliche) Dinge, die man mit der Negativliste sehr leicht blockieren könnte, ohne es zu wollen:
- Aufrufe des LetsEncrypt-Bots bei der Ausstellung/Erneuerung von SSL-Zertifikaten
- Aufrufe der ads.txt von Werbe-Diensten (sehr wichtig für deine Werbeeinnahmen)
- Aufrufe deiner Seite, um zu prüfen, ob du einen Code zur Bestätigung der Inhaberschaft eingebaut hast
- Crawler von weniger bekannten Suchmaschinen
- Crawler von Preisvergleich-Seiten (sehr wichtig für Shops)
- Lokale Caches oder ModPagespeed, die deine Seiten aufrufen
- Monitoring-Tools, die auf Wunsch den Status deiner Seite überwachen, um dich zu informieren, wenn es ein Problem gibt
- SEO-Tools, die auf Wunsch deine Seite analysieren
- RSS-Feed-Fetcher (nützlich für Foren und Blogs)
- WordPress Trackbacks und Pingbacks
- URL-Preview-Renderer, die z. B. zum Einsatz kommen, wenn man in sozialen Netzwerken oder Messengern eine URL teilt

Das alles sind legitime automatisierte Aufrufe, die aus gutem Grund erfolgen, und bei den meisten davon werden wohl keine Sec-Fetch-Header mitgesendet. Die User Agents kann man kaum alle in einer Negativliste/Ausnahmenliste erfassen, einfach weil es so viele verschiedene davon gibt und immer wieder neue dazukommen.

[staticweb]

> Also was ist (Dein) Problem?

Kein Problem, aber ich halte eine 1024 x 1024 Viewport Größe nicht für ausgeschlossen.

[supervisior]

Kein Problem, aber ich halte eine 1024 x 1024 Viewport Größe nicht für ausgeschlossen.

Gänzlich für sich alleingestellt womöglich ja, aber im Ganzen betrachtet neben noch weiteren Faktoren dient es dann schon dazu festzustellen, dass sich dahinter kein natürlicher User verbergen kann.

[supervisior]

Da hast du mich falsch verstanden.

Habe ich das? Ich glaube nicht. Mit Deiner Methodik der Positivlisten machst Du den versuchten Einsatz der Sec-Fetch-* Header fast schon überflüssig. Am Ende entsteht dadurch ein riesiger Mehraufwand, ohne dass sich unterm Strich ein Vorteil durch diese Header ergibt.

Dein Vorschlag lautet:
Blockiere, wenn kein Sec-Fetch-Header gesetzt ist, außer wenn der User Agent in der Negativliste/Ausnahmenliste [Safari, Chrome < 76, Edge < 79, Firefox < 90, Opera < 63, ...] enthalten ist.
Diese Negativliste müsste idealerweise alle alten/obskuren Browser sowie alle erwünschten Bots aufführen, die keine Sec-Fetch-Header senden. Davon gibt es wahrscheinlich tausende, die schwer zu erfassen sind. Heutzutage hat doch jeder Toaster einen eingebauten Browser.

Mein Vorschlag lautet:
Blockiere, wenn kein Sec-Fetch-Header gesetzt ist, aber nur dann, wenn der User Agent in der Positivliste [Chrome >= 76, Edge >= 79, Firefox >= 90, Opera >= 63, ...] enthalten ist.
Diese Positivliste müsste idealerweise alle Browser enthalten, die Sec-Fetch-Header senden.
Eine zusätzliche Negativliste für bekannte "gute" Bots, die zwar sagen, dass sie Chrome >= 76 sind, aber trotzdem keine Sec-Fetch-Header senden (z. B. Googlebot, Bing-Bot), bräuchte man wohl trotzdem noch ...

Du denkst viel zu kompliziert. Ich mach Dir nochmal den Vorschlag, dass Du es einfach mal ausprobieren solltest. Also nicht gleich blocken, sondern die Requests einfach nur in ein, bzw. 2 separate Logfiles schreiben. Das eine mit und das andere ohne Sec-Fetch-* Header und dann schaust Dir mal die jeweiligen Request Header an.

Der Ansatz mit der Positivliste hat den Vorteil, dass es unwahrscheinlicher ist, dass ein legitimer Nutzer oder erwünschter Bot blockiert wird.

Wenn in deiner Negativliste etwas fehlt, dann führt das dazu, dass potenziell legitime Nutzer oder erwünschte Bots blockiert werden (nicht gut, im schlimmsten Fall existenzbedrohend, siehe unten). Wenn in meiner Positivliste etwas fehlt, dann führt das dazu, dass potenziell mehr Bots durchkommen (auch nicht schön, aber damit kann man leben).

Aber hier noch ein praktisches Beispiel, warum eine Negativliste gefährlich ist: Wer einen Shop betreibt und Zahlungen via PayPal akzeptiert, der hat ein Script auf seiner Seite, das von PayPal aufgerufen wird, wenn eine Zahlung eingeht. Damit wird dem Shop Bescheid gegeben, dass eine Bestellung bezahlt wurde. Ich hab's nicht getestet, aber ich würde darauf wetten, dass PayPal beim Aufruf des Scripts keine Sec-Fetch-Header mitsendet. Wenn du daran nicht gedacht hast und keine Ausnahme für PayPal in deiner Negativliste hast (oder wenn PayPal irgendwann mal den User Agent ändert), dann wird PayPal blockiert, was dann dazu führt, dass der Shop nicht mehr richtig funktioniert.

Weitere (wichtige/nützliche) Dinge, die man mit der Negativliste sehr leicht blockieren könnte, ohne es zu wollen:
- Aufrufe des LetsEncrypt-Bots bei der Ausstellung/Erneuerung von SSL-Zertifikaten
- Aufrufe der ads.txt von Werbe-Diensten (sehr wichtig für deine Werbeeinnahmen)
- Aufrufe deiner Seite, um zu prüfen, ob du einen Code zur Bestätigung der Inhaberschaft eingebaut hast
- Crawler von weniger bekannten Suchmaschinen
- Crawler von Preisvergleich-Seiten (sehr wichtig für Shops)
- Lokale Caches oder ModPagespeed, die deine Seiten aufrufen
- Monitoring-Tools, die auf Wunsch den Status deiner Seite überwachen, um dich zu informieren, wenn es ein Problem gibt
- SEO-Tools, die auf Wunsch deine Seite analysieren
- RSS-Feed-Fetcher (nützlich für Foren und Blogs)
- WordPress Trackbacks und Pingbacks
- URL-Preview-Renderer, die z. B. zum Einsatz kommen, wenn man in sozialen Netzwerken oder Messengern eine URL teilt

Das alles sind legitime automatisierte Aufrufe, die aus gutem Grund erfolgen, und bei den meisten davon werden wohl keine Sec-Fetch-Header mitgesendet. Die User Agents kann man kaum alle in einer Negativliste/Ausnahmenliste erfassen, einfach weil es so viele verschiedene davon gibt und immer wieder neue dazukommen.

Würde man eine Sicherheitslösung einzigst auf die Sec-Fetch-Header aufbauen, müsste man tatsächlich so verfahren, wie Du es beschreibst. Die Sec-Fetch-Header dienen, bzw. sollen aber nur dazu dienen eine Security Policy zu ergänzen. Ich muss nochmals darauf verweisen, was ich oben schon kommentiert habe. Mach einfach mal eine Trockenübung mit den Logflies.

[staticweb]

Mal ganz ehrlich. Wer als Shop-Betreiber ein ernsthaftes Problem mit Bots hat, sollte sich einen spezialisierten Dienstleister suchen mit dem er zusammenarbeitet. Das Thema ist dermaßen komplex und zeitintensiv, dass man sich vorher ausrechnen sollte was einem die eigene Zeit Wert ist.

Und am Ende ist es so, dass es auf der anderen Seite spezialisierte Crawling/Scraping Plattformen mit ausgeklügelten Mechanismen gibt, die solche Dienstleistungen für Kunden anbieten. Als Einzelkämpfer hat man kaum eine Chance sich dagegen zu wehren.

[Hanzo2012]

Da hast du mich falsch verstanden.

Habe ich das? Ich glaube nicht.

Ich glaube schon, da du etwas von IP-Adressen gesagt hast.

Mit Deiner Methodik der Positivlisten machst Du den versuchten Einsatz der Sec-Fetch-* Header fast schon überflüssig. Am Ende entsteht dadurch ein riesiger Mehraufwand, ohne dass sich unterm Strich ein Vorteil durch diese Header ergibt.

Wieso Mehraufwand?

Eben genau nicht, weil ich keine riesige Liste von Ausnahmen brauche, um zu verhindern, dass legitime menschliche Nutzer oder erwünschte Bots blockiert werden.

Ich erwische aber immer noch diejenigen Bots, die sich als ein aktueller Browser ausgeben.

Ich bin schon am testen und sammle Daten, aber derweil eine Frage an dich, rein verständnishalber: Angenommen du nutzt LetsEncrypt, um dein SSL-Zertifikat ausstellen zu lassen / PayPal, um Zahlungen in deinem Shop entgegenzunehmen. Der LetsEncrypt-Bot / PayPal-Bot ruft eine spezielle Seite auf deiner Website ab, um zu prüfen, ob sie wirklich dir gehört / deinem Shop mitzuteilen, dass eine Zahlung eingegangen ist. Dabei sendet er keine Sec-Fetch-Header. Wie, wenn nicht über eine Liste von Ausnahmen, verhinderst du konkret, dass das blockiert wird?

[supervisior]

Ich bin schon am testen und sammle Daten, aber derweil eine Frage an dich, rein verständnishalber: Angenommen du nutzt LetsEncrypt, um dein SSL-Zertifikat ausstellen zu lassen / PayPal, um Zahlungen in deinem Shop entgegenzunehmen. Der LetsEncrypt-Bot / PayPal-Bot ruft eine spezielle Seite auf deiner Website ab, um zu prüfen, ob sie wirklich dir gehört / deinem Shop mitzuteilen, dass eine Zahlung eingegangen ist. Dabei sendet er keine Sec-Fetch-Header. Wie, wenn nicht über eine Liste von Ausnahmen, verhinderst du konkret, dass das blockiert wird?

Dafür habe ich (noch) keine Lösung. Erstens weil ich kein LetsEncrypt verwende und zweitens, weil das cPanel etwas anders läuft. Da kommt kein Bot vorbei, der irgendwas prüft. Das geht bei cpanel etwas fortschrittlicher... Nichtsdestotrotz müsste man sich dafür etwas einfallen lassen, um auch LetsEncrypt bedienen zu können.

[Hanzo2012]

Wenn ich richtig verstanden habe, dann versuchst du, deine Lösung "massentauglich" zu machen, so dass sie jeder "08/15-Seitenbetreiber" ohne großartiges Fachwissen einsetzen kann ohne viel konfigurieren zu müssen. Der normale Betrieb der Seite sollte nicht beeinträchtigt werden.

Deine Lösung hast du erstmal für dich selbst entwickelt und an deinem persönlichen Einsatzzweck ausgerichtet. An Aufrufe durch PayPal oder LetsEncrypt hast du dabei nicht gedacht, schlicht weil du das nicht nutzt. Das sei dir verziehen, aber das zeigt doch das grundsätzliche Problem:

Wenn deine Lösung massentauglich sein soll, dann musst du an all diese Dinge denken, die für andere Seitenbetreiber vielleicht (lebens-)wichtig sein könnten. Die darfst du unter keinen Umständen blockieren. Sonst wundert sich der Shopbetreiber, warum plötzlich keine PayPal-Zahlungen mehr funktionieren. Sonst wundert sich der LetsEncrypt-Nutzer, warum SSL-Zertifikate auslaufen (beides wäre sehr schlecht und würde finanziellen Schaden verursachen).

Für dich persönlich mag der Googlebot der einzig nützliche Bot sein. Aber jemand, der mit Werbeanzeigen sein Geld verdient, muss auch die Bots durchlassen, die seine ads.txt-Datei abgrasen. Und das ist nicht ein einziger Bot, sondern zig verschiedene, und es kommen ständig neue dazu. Und jemand, der einen Shop betreibt, muss die Crawler von zig Preisvergleich-Seiten durchlassen. Und so weiter ... Da gibt es Dinge, von denen wir beide nie etwas gehört haben.

Mein Punkt ist, dass es extrem schwierig ist, das alles zu berücksichtigen. Und die Welt steht nicht still, d. h. du hättest die lebenslange Aufgabe, ständig neue Ausnahmen hinzuzufügen - genau das, was du eigentlich nicht willst.

Darum meine Empfehlung, nur diejenigen Zugriffe zu blockieren, bei denen sich der Bot z. B. als ein Chrome Version >= 76 oder Firefox >= 90 ausgibt, jedoch keine Sec-Fetch-Header mitsendet. In diesen Fällen kannst du sehr sicher sein, dass etwas faul ist. Damit lässt du die allermeisten guten, erwünschten Bots durch, da die sich zu erkennen geben und sich nicht als Browser tarnen. Du musst also nicht an jeden Bot denken, der für irgendjemanden wichtig sein könnte.

Und dann gibt's natürlich auch noch viele alte oder "obskure" Browser da draußen, die keine Sec-Fetch-Header senden. Die mögen für dich persönlich nicht wichtig sein, aber eine Lösung, die für alle funktioniert, sollte diese nicht blockieren. Wer weiß - vielleicht gibt's ja jemanden, der 50% seines Traffics über den eingebauten Browser der Nintendo Switch-Spielekonsole bekommt (der keine Sec-Fetch-Header sendet)?

[supervisior]

Wenn ich richtig verstanden habe, dann versuchst du, deine Lösung "massentauglich" zu machen, so dass sie jeder "08/15-Seitenbetreiber" ohne großartiges Fachwissen einsetzen kann ohne viel konfigurieren zu müssen. Der normale Betrieb der Seite sollte nicht beeinträchtigt werden.

Habe ich das geschrieben? Ich denke nicht und das geht auch gar nicht, weil jeder Server anders ist. Insbesondere was "Deine" Postivliste anbetrifft. Mir ging es in erster Linie nur darum eine Diskussion darüber anzuregen, aber nicht mehr.

[Hanzo2012]

Wenn ich richtig verstanden habe, dann versuchst du, deine Lösung "massentauglich" zu machen, so dass sie jeder "08/15-Seitenbetreiber" ohne großartiges Fachwissen einsetzen kann ohne viel konfigurieren zu müssen. Der normale Betrieb der Seite sollte nicht beeinträchtigt werden.

Habe ich das geschrieben? Ich denke nicht

Ich denke schon:

Die Frage ist nun, wie lässt sich ein Filter erstellen, der sich auch universell verweden lässt, so dass auch der vermeintliche "Dummy ihn anwenden kann?

Oder wie sollte man das verstehen?

Insbesondere was "Deine" Postivliste anbetrifft.

Deine Aussage lässt mich vermuten, dass es hier immer noch ein Missverständnis gibt ... Also jetzt mal Klartext (Code)! Ich schlage etwas wie Folgendes vor:

Code: Alles auswählen

if (isset($_SERVER["HTTP_USER_AGENT"]) &&
    !isset($_SERVER["HTTP_SEC_FETCH_DEST"]) &&
    !isset($_SERVER["HTTP_SEC_FETCH_MODE"]) &&
    !isset($_SERVER["HTTP_SEC_FETCH_SITE"]) &&
    !isset($_SERVER["HTTP_SEC_FETCH_USER"]) &&
    preg_match('@^Mozilla/5\.0 \([^);]+(; [^);]+)*\) AppleWebKit/\d+(\.\d+)* \(KHTML, like Gecko\) Chrome/(7[6-9]|[8-9]\d|\d{3,})(\.\d+)* Safari/\d+(\.\d+)*$@', $_SERVER["HTTP_USER_AGENT"]))
{
    // Angeblich ist es Chrome Version >= 76, aber es wurden keine Sec-Fetch-Header gesendet.
    // Ein echter Chrome in dieser Version würde Sec-Fetch-Header senden, also ist es ein Fake-Browser!
    // Tu hier, was immer du willst: loggen, blockieren, bannen, Malware ausliefern, DDoS-Angriff starten, ...
}

Das nutze ich aktuell für mein Experiment. Bis jetzt wird hier nur ein Fake-Chrome erkannt, aber das kann ganz leicht erweitert werden auf Fake-Firefox, Fake-Opera etc. - dazu muss man nur den einen regulären Ausdruck anpassen. Mein Code prüft bis jetzt nur, ob Sec-Fetch-Header gesendet wurden, aber nicht, ob diese auch gültige Werte aufweisen. Das ließe sich natürlich auch noch leicht ändern.

Das Ganze lässt sich auch als Regel in der .htaccess umsetzen, da nur reguläre Ausdrücke benötigt werden.

Beachte folgenden Teil des regulären Ausdrucks:

Code: Alles auswählen

Chrome/(7[6-9]|[89]\d|\d{3,})(\.\d+)*

Damit wird getestet, ob die erste Zahl der Versionsnummer größer oder gleich 76 ist. Denn erst ab Version 76 sendet Chrome die Sec-Fetch-Header. Einen Chrome älter als Version 76, der keine Sec-Fetch-Header sendet, blockieren wir damit also nicht.

[supervisior]

Wenn ich richtig verstanden habe, dann versuchst du, deine Lösung "massentauglich" zu machen, so dass sie jeder "08/15-Seitenbetreiber" ohne großartiges Fachwissen einsetzen kann ohne viel konfigurieren zu müssen. Der normale Betrieb der Seite sollte nicht beeinträchtigt werden.

Habe ich das geschrieben? Ich denke nicht

Ich denke schon:

Jetzt letztmalig, nein! Wieso beharrst so darauf mir zu unterstellen, dass ich auf eine massentaugliche Lösung aus wäre? Es wäre ja schön, wenn das ginge, aber das geht nun mal nicht. Zumal nicht, wenn der User nicht qualifizieren kann, was der da tut. Deswegen hör jetzt bitte damit auf mir etwas zu unterstellen!!!

Die Frage ist nun, wie lässt sich ein Filter erstellen, der sich auch universell verweden lässt, so dass auch der vermeintliche "Dummy ihn anwenden kann?

Oder wie sollte man das verstehen?

Siehst Du das Fragezeichen? Also ich sehe eines!

Insbesondere was "Deine" Postivliste anbetrifft.

Deine Aussage lässt mich vermuten, dass es hier immer noch ein Missverständnis gibt ... Also jetzt mal Klartext (Code)! Ich schlage etwas wie Folgendes vor:

Code: Alles auswählen

if (isset($_SERVER["HTTP_USER_AGENT"]) &&
    !isset($_SERVER["HTTP_SEC_FETCH_DEST"]) &&
    !isset($_SERVER["HTTP_SEC_FETCH_MODE"]) &&
    !isset($_SERVER["HTTP_SEC_FETCH_SITE"]) &&
    !isset($_SERVER["HTTP_SEC_FETCH_USER"]) &&
    preg_match('@^Mozilla/5\.0 \([^);]+(; [^);]+)*\) AppleWebKit/\d+(\.\d+)* \(KHTML, like Gecko\) Chrome/(7[6-9]|[8-9]\d|\d{3,})(\.\d+)* Safari/\d+(\.\d+)*$@', $_SERVER["HTTP_USER_AGENT"]))
{
    // Angeblich ist es Chrome Version >= 76, aber es wurden keine Sec-Fetch-Header gesendet.
    // Ein echter Chrome in dieser Version würde Sec-Fetch-Header senden, also ist es ein Fake-Browser!
    // Tu hier, was immer du willst: loggen, blockieren, bannen, Malware ausliefern, DDoS-Angriff starten, ...
}

Das nutze ich aktuell für mein Experiment. Bis jetzt wird hier nur ein Fake-Chrome erkannt, aber das kann ganz leicht erweitert werden auf Fake-Firefox, Fake-Opera etc. - dazu muss man nur den einen regulären Ausdruck anpassen. Mein Code prüft bis jetzt nur, ob Sec-Fetch-Header gesendet wurden, aber nicht, ob diese auch gültige Werte aufweisen. Das ließe sich natürlich auch noch leicht ändern.

Das Ganze lässt sich auch als Regel in der .htaccess umsetzen, da nur reguläre Ausdrücke benötigt werden.

Beachte folgenden Teil des regulären Ausdrucks:

Code: Alles auswählen

Chrome/(7[6-9]|[89]\d|\d{3,})(\.\d+)*

Damit wird getestet, ob die erste Zahl der Versionsnummer größer oder gleich 76 ist. Denn erst ab Version 76 sendet Chrome die Sec-Fetch-Header. Einen Chrome älter als Version 76, der keine Sec-Fetch-Header sendet, blockieren wir damit also nicht.

Für mich der falche Ansatz. Die Browser Version eines einzelnen, wenngleich verbreiteten Browser, vorrangig zu prüfen, ist wenig sinnvoll. Es macht für alles weitere mehr Sinn zunächst das Spreu vom Weizen zu trennen. Weizen ist der reale User, der Sec-Fetch-* Header sendet und das sind alle Browser bis auf den Safari Browser auf dem Mac. Den Safari Browser wollen wir aber auch als Weizen definieren, hat jedoch den Haken, dass der Applebot diesen auch verwendet, dieser allerdings keine Cookies akzeptiert. Dazu später mehr. Alles, was nun keine Sec-Fetch-* Header sendet und der Safari Browser ist (exklusive Applebot), ist das Weizen. Alles was dieser Definition nicht entspricht, ist das Streu. Vom Verhältnis her geschätzt >95:5 zu Gunsten des Weizen.

Wir prüfen deswegen zunächst die Existenz der Sec-Fetch-* Header und verpassen dem Weizen einen Cookie, müssen dem nicht Applebot Safari aber auch einen verpassen, was aber vergleichsweise einfach ist, weil der UA des Applebot den Namen "Applebot" im UA trägt. Dieser Cookie wird für alles weitere dann als Konstante definiert, was die Überprüfung nicht nur vereinfacht, sondern auch schneller macht als ständig die Existenz der Sec-Fetch-* Header zu prüfen.

Wir müssen uns deswegen nur mehr noch um den deutlich kleineren Spreu Anteil kümmern und das ist für mich die Negativliste. Allerdings, und jetzt kommst Du mit Deiner Positivliste ins Spiel, müssen wir aus dem Spreu diejenigen rausfiltern, die wir als Gut und somit als Weizen bezeichnen wollen, damit diese nicht geblockt werden. Also vom bitte gewünschten Bot bis sonstiges variables Zeugs. Meine Vorgehensweise geht vom Großen hin zum Kleinen, wobei sich das Große vergleichsweise einfach und auch sicher definieren lässt.

Die Logik würde zwar abverlangen auch die Browser Versionen zu prüfen, aber mal ehrlich, wer den Chrome Browser in der Version 76 verwendet, der verwendet auch Windows 95. Ich überlasse es aber dem Einzelnen das für sich zu qualifizieren.