krjdev: Wichtiger Hinweis im Umgang mit PHP

1 49

Wichtiger Hinweis im Umgang mit PHP

krjdev
  • http-status
  • php
  1. 0
    Matthias Scharwies
    1. 1
      krjdev
      1. 0
        Matthias Scharwies
        1. 0
          krjdev
          1. 0
            Raketenverschlimmbesserer
  2. 0

    Hat vorliegend mit PHP nichts zu tun, „ist Grundrauschen“

    Raketenflugkontrolle
    • http-status
    • php
    • sicherheit
    1. 0

      Nachtrag

      Raketenflugkontrolle
      1. 0
        Matthias Scharwies
        1. 0
          krjdev
          1. 0
            Raketenflugkontrolle
            1. 0
              krjdev
            2. 0
              krjdev
              1. 0
                Raketenflugkontrolle
                1. 0
                  krjdev
            3. 0
              Rolf B
        2. 0
          Raketenflugkontrolle
    2. 0

      Bevor gefragt wird ... mod_rewrite bekommt die Anfrage auch nicht / Keine Panik!

      Raketenflugkontrolle
      1. 0
        krjdev
        1. 0
          Raketenflugkontrolle
          1. 0
            krjdev
          2. 0
            krjdev
            1. 0
              Raketenflugkontrolle
              1. 0
                Rolf B
                1. 0
                  Raketenflugkontrolle
                  1. 0
                    Raketenflugkontrolle
              2. 0
                krjdev
                1. 0
                  Rolf B
                  1. 0
                    Felix Riesterer
    3. 0
      krjdev
      1. 0

        Ultimatives „Nein“.

        Raketenflugkontrolle
        1. 0
          krjdev
          1. 0
            Raketenflugkontrolle
            1. 0
              Der Martin
              1. 0
                Raktenflugkontrolle
                1. 0
                  Rolf B
                  1. 0
                    Raketenflugkontrolle
                    1. 0
                      Rolf B
                    2. 0

                      Habs gefunden ...

                      Raketenflugkontrolle
                      1. 0
                        krjdev
                        1. 0
                          Rolf B
                          1. 0
                            krjdev
                        2. 0
                          Raketenflugkontrolle
  3. 0
    Rolf B
  4. 0
    klawischnigg
    1. 0
      Rolf B
      1. 0
        klawischnigg
        1. 0
          Rolf B
  5. 0
    Raktenflugkontrolle

Hallo liebe SelfHTML Freunde!

Da ich die Wikiartikel gerne als Hilfestellung hier genutzt habe und auch die erste Anlaufstelle bezüglich PHP war, möchte ich gerne hier im Umgang mit PHP auf was wichtiges hinweisen. Ich habe einen Artikel geschrieben, der jetzt nicht mehr Online ist, bis sich die Sache mit meinem ISP geklärt hat. Hab die Server vom Netz nehmen müssen aufgrund eines Fehler im PHP Code. Vorweg es war keine Sicherheitslücke im Code

Zugegeben ist ein etwas langer Text, soll aber veranschaulichen auf was man unbedingt achten sollte, wenn man PHP verwendet. Vielleicht erwähnt Ihr das ja einmal in der Wiki, damit andere nicht den selben Fehler machen. Richtet sich an Quereinsteiger.

Suchmaschinen und Robots: Wenn eine Maschine nur den Fehlercode abfragt.

Oder:

Google bitte verliere dein Gedächtnis: Suchmaschinen und was man nicht falsch machen sollte wenn man eine Webseite betreibt.

Ein Artikel von [ENTFERNT] "krjdev" [ENTFERNT]

Letzte Aktualisierung am 23. Oktober 2021

Vorwort

Dieser Artikel richtet sich hauptsächlich an Webseitenentwickler wie mich, die aus Lernzwecken fast alles bei einer Webseite selber machen wollen und keine Baukastensysteme wie WordPress und Konsorten verwenden wollen. Der folgende Text entspricht nach einer wahren Begebenheit, die mir mit dieser Webseite widerfahren ist. Der Artikel ist möglicherweise deswegen nicht neutral formuliert, da ich voreingenommen durch diesen von mir peinlichen Fehler bin. Auch wenn hier über diesen Fehler Einige schmunzeln werden, ist es aber leider für mich derzeit nicht zum Lachen zumute, bis Google, Microsoft Bing und andere Suchmaschinen das Problem lösen, oder sich das Problem im Laufe der Zeit von selber löst. Der Artikel beinhaltet technische Begriffe im Bereich der Webentwicklung und ist in erster Linie an Menschen gerichtet die schon zu mindestens ein Grundwissen über die Funktionsweise des Internets haben. Sollten Ihnen aber trotzdem ein paar Begriffe nicht bekannt sein, dann finden Sie im letzten Abschnitt dieses Artikels Links zu Wikipedia Artikeln.

Die Geschichte

Ich betreibe diese Webseite seit Anfang 2018, angefangen mit reinen statischen HTML Seiten. Diese habe ich dann im Jahr 2020 auf pseudo-dynamische Seitengenerierung mittels PHP umgestellt. Mit pseudo-dynamisch meine ich damit, dass der ganze HTML Code bzw. Inhalt im PHP Skript vorhanden war. Wurde nicht über eine Datenbank bezogen, so wie das jetzt auf dieser neuen Seite der Fall ist. Natürlich war es durch diesen Designfehler meinerseits sehr umständlich neue Inhalte bereit zu stellen. Deswegen habe auch seit der Umstellung keine neue Inhalte hinzugefügt. Der Zweite aber schwerwiegende Fehler war, – der Grund warum ich diesen Artikel zur Schadensbegrenzung hier veröffentliche – dass ich im HTTP Header keinen richtigen Statuscode gesetzt habe, wenn zum Beispiel eine Seite nicht verfügbar ist oder die URL Parameter ungültig sind. Für normale Benutzer die diese Seite über einen Browser ansehen, ist bei falschen Angaben immer auf meine Startseite verwiesen worden, was ich damals nicht als schwerwiegend angesehen habe. Ich habe aber damals Eines Aufgrund meines fehlenden Wissensstandes in diesem Bereich nicht bedacht: Und zwar das Verhalten der Robots der Suchmaschinenbetreiber und Skripte die meine Seite analysieren. Diese kontrollieren derzeit nämlich vorrangig den Statuscode einer Seite und überprüfen so ob eine Seite oder Parameter gültig ist. Im korrekten Fall hätte ich müssen einen 4xx Statuscode für diese Robots und Skripte ausliefern sollen wenn eine Anfrage nicht gültig ist. Habe ich aber damals nicht, und das hat sich sehr negativ auf den Suchmaschinen und externen Seiten ausgewirkt.

Im Detail

Wenn ein Robot oder Skript eine Anfrage an den Webserver sendet, dann parst das Programm vorrangig zuerst im HTTP Header den Statuscode. Ein möglicher Header kann so bei einer HTTP GET Anfrage aussehen (hier mit dem Programm telnet illustriert):

[Hier war ein Link auf ein Screenshot mit einer manuellen Anfrage mit telnet, auf meiner Homepage.]

Wie Sie sehen steht in der ersten Zeile die Protokollversion (HTTP/1.1) und die Zahl 200, die bedeutet dass die Anfrage erfolgreich war. Nachfolgend sehen Sie andere Header Parameter gefolgt vom eigentlichen Inhalt der jeweiligen Seite. Manche Robots und Skripte überprüfen hier nur den Statuscode 200 vom Header. Wenn diese Zahl abweicht, dann wird der restliche Inhalt nicht mehr analysiert bzw. verworfen. Zugeben ich würde es vermutlich, wenn ich so einen Robot schreibe, auch nicht anders machen.

Das Problem

Das Problem dabei ist wenn Robots und Skripte nicht den eigentlichen Inhalt lesen, dass wie bei meiner Seite passiert ist, es zu schwerwiegenden Seiteneffekten führt, wenn diese nicht existenten URL’s auf einer Webseite in eine Datenbank oder auf externen Webseiten gespeichert werden. Hier bringe ich den SEO Begriff Backlinks in Spiel. Das sind Verweise auf externen Seiten auf die eigene Webseite verweisen. Robots und Skipte reagieren auf diese Links wenn Sie diese auf einer externen Seite erscheinen, da für Robots und Skripte alles anscheinend verlinkt bzw. vernetzt sein muss. Es wäre aus meiner Sicht kein Problem dabei, wenn diese Robots auch den Link folgen würden und auch den Inhalt verifizieren. Was nicht immer bei den Suchmaschinenbetreiber geschieht. Sollte sich schon wer mal bei der Google Search Konsole angemeldet haben, wird vermutlich den Begriff Duplikat kennen. Hier wurde der Inhalt bei einer URL tatsächlich zu einen gewissen Grad überprüft und als gleich befunden. Das machen aber leider nicht alle Suchmaschinenbetreiber.

Die Folgen

In technischer Hinsicht besteht darin kein Problem, wenn in Suchmaschinen und externen Seite falsche Verweise stehen. Aber es kann den Ruf einer Webseite massiv beschädigen, anhand meines Beispieles: Meine Webseite war als eine Art Bewerbungsseite gedacht. Wo ich technische Artikel und Projekte im Bereich Elektronik und Programmierung vorstelle. Was ich noch, trotz diesem peinlichen Fehler auch noch mache. Was ich jetzt nachfolgend beschreibe ist kein technisches Problem sondern ein gesellschaftliches Problem in unseren Breitengraden. Für Maschinen ist eine (ungültige) URL nur eine Zeichenkette ohne Bedeutung, sofern keine KI verwendet wird. Für Menschen kann dies allerdings unterschiedliche Reaktionen auslösen, wenn sie diese Zeichenkette auf einer Suchmaschine oder auf fremden Seiten sehen. Leider neigen manche Menschen dazu, wenn Sie so eine Zeichenkette sehen, nicht die Quelle überprüfen. Das heißt, sie folgen nicht den Link auf die betroffene Webseite. So entsteht aber ein falsches Vorurteil über eine Webseite. Sofern Sie mich noch folgen können, Betreff meiner Webseite denken möglicherweise jetzt manche Menschen, dass ich eine schmuddelige Seite betreibe, was diese nachfolgenden Serverlogs von Suchmaschinenanfragen (hier der Bing) beweisen:

www.[ENTFERNT].com 40.77.167.17 - - [22/Oct/2021:16:08:00 +0200] "GET /search/pXrnX+casero?top HTTP/1.1" 400 0 "" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" - -

[Ich habe die Anfrage im Serverlog entschärft, war nicht jugendfrei.)

Natürlich war auf meiner Seite nicht ein solcher Inhalt vorhanden und diese Menschen hätten das auch erkannt, wenn sie den Link aufgerufen hätten anstatt das restliche Internet zu vertrauen.

Nachtrag

Ich werde diesen Artikel nach Möglichkeit noch weiter ergänzen. Hoffe aber, dass der Ruf dieser Webseite mit dem Lauf der Zeit sich wieder ändert und bestimmte Links wieder von den Suchmaschinen und externen Seiten gelöscht werden. Ich habe jedenfalls aus meinen peinlichen Fehler gelernt.

  1. Herzlich willkommen bei SELFHTML!

    Danke für Deinen Artikel!

    An welchen Stellen im SELF-Wiki im Bereich PHP/Tutorials und HTTP/Einsteiger-Tutorial müsste Deiner Meinung nach etwas verbessert, bzw von wo darauf verlinkt werden?

    Herzliche Grüße

    Matthias Scharwies

    --
    Einfach mal was von der ToDo-Liste auf die Was-Solls-Liste setzen.“
    1. Hi Matthias!

      Vielen lieben Dank für das Feeback.

      Gute Frage.

      Ich finde der Artikel zur 404-Fehlerseite sollte ergänzt werden mit dem Hinweis einer "möglichen" Lösung wenn der eingesetzte HTTP Server keine .htaccess Datei unterstützt (wie zum Beispiel beim OpenBSD's httpd in meinem Fall).

      Hier habe ich es so gelöst, das ich den HTTP Statuscode manuell mit der folgenden PHP Funktion setze

      http_response_code(404);

      Quelle: PHP Manual (http_reponse_code)

      Und es sollte auf möglichen Folgen eventuell darauf hingewiesen werden, was passieren kann wenn man das nicht macht. Also was ich meinen Artikel geschildert habe.

      Das sollte meiner Meinung nach auch im Einstiegstutorial nicht fehlen.

      EDIT

      Das ist besonders wichtig wenn man wie ich alle gültigen URL's der Seite in einer Datenbank hinterlegt hat und den Server so eingestellt hat das alle Anfragen auf ein PHP Skript umgeleitet werden.

      Kann das gerne noch erläutern.

      1. Servus!

        Hi Matthias!

        Vielen lieben Dank für das Feeback.

        Gute Frage.

        Ich finde der Artikel zur 404-Fehlerseite sollte ergänzt werden:

        Hab' ich mal gemacht - liest wer drüber?

        Das sollte meiner Meinung nach auch im Einstiegstutorial nicht fehlen.

        Da geht's ja eher nur um die Sprachstrukturen. Ich wüsste nicht, wo man da was hinzufügen sollte.

        Ich hatte an PHP/Tutorials/Templates gedacht.

        Das soll einerseits kein 27-teiliges Werk zum Schreiben eines CMS werden, wird andererseits

        1. immer wieder gefragt
        2. und ist eben doch noch nicht fertig:

        In PHP/Tutorials/Templates/Datenausgabe ist ein ToDo, wo's wsl. reingehört.

        Herzliche Grüße

        Matthias Scharwies

        --
        Einfach mal was von der ToDo-Liste auf die Was-Solls-Liste setzen.“
        1. Ich finde der Artikel zur 404-Fehlerseite sollte ergänzt werden:

          Hab' ich mal gemacht - liest wer drüber?

          Ich weiß nicht was andere dazu sagen, aber für mich ist es jedenfalls in Ordnung. 😀

          Man könnte eventuell noch bei der Funktion erwähnen (steht zwar eh bei den Kommentaren im Manual), dass das vor der Ausgabe des eigentlichen Inhaltes geschehen müsste.

          Auch bei anderen Manipulationen vom HTTP Header. Wenn der Server es "chunked" schickt.

          Das sollte meiner Meinung nach auch im Einstiegstutorial nicht fehlen.

          Da geht's ja eher nur um die Sprachstrukturen. Ich wüsste nicht, wo man da was hinzufügen sollte.

          Ja, stimmt. Wie ich halt im Artikel im Vorwort geschrieben habe bin ich voreingenommen. Hat für mich derzeit allerhöchste Priorität.

          Ich hatte an PHP/Tutorials/Templates gedacht.

          Das soll einerseits kein 27-teiliges Werk zum Schreiben eines CMS werden, wird andererseits

          1. immer wieder gefragt
          2. und ist eben doch noch nicht fertig:

          In PHP/Tutorials/Templates/Datenausgabe ist ein ToDo, wo's wsl. reingehört.

          Herzliche Grüße

          Matthias Scharwies

          1. Ich finde der Artikel zur 404-Fehlerseite sollte ergänzt werden:

            Hab' ich mal gemacht - liest wer drüber?

            Ich weiß nicht was andere dazu sagen, aber für mich ist es jedenfalls in Ordnung. 😀

            Das brauchte etwas „Tuning“. Ich hab das mal eigenmächtig gemacht. Hoffe es ist jetzt O.K.

  2. www.[ENTFERNT].com 40.77.167.17 - - [22/Oct/2021:16:08:00 +0200] "GET /search/pXrnX+casero?top HTTP/1.1" 400 0 "" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" - -

    Hm. Schauen wir da mal hin:

    Der HTTP-Statuscode 400 Bad Request gibt an, dass der Server die Anfrage nicht verarbeiten kann, weil anscheinend ein clientseitiger Fehler geschehen ist (z.B. eine syntaktisch falsche Anfrage).

    Es wurden also 0 Bytes geliefert.

    IP?

    s.a. https://www.fastix.org/netztools/index.php?addr=40.77.167.17&action=whois

    Also unabhängig davon, dass die IP zu Microsoft gehört: Ich glaube nicht, dass Bing eine syntaktisch falsche Anfrage sendet.

    Was ist das also?

    Offenbar ein Netzwerkscan, dumper Angiffsversuch oder dergleichen. Bing verwendet IP-Bereiche, die auch sonst immer mal auffällig sind. Da man bei Microsoft auch virtuelle Maschinen, reine Anwendungen oder dergleichen hosten kann würde ich vielmehr vermuten, dass da jemand - vorsätzlich oder nicht - Mist baut, den schon der Server zurückweist.

    Wenn man das absichtlich machen würde würde man es sicher für eine gute Idee halten, als "Bing" aufzuteten - und eine IP von M$ vorzuweisen. Für mich läuft das unter „Grundrauschen“, sowas hat man täglich in den Logs.

    Nochmal zum Statuscode 400 und 0 Bytes Payload:

    PHP wird damit also gar nicht befasst. Und damit, Deine Seiten vom Netz zu nehmen, hast Du wohl heftig überreagiert.

    1. Ich würde sogar behaupten, dass es eine Webseite mit dem beschriebenen Link nicht gibt. Die URL wurde höchstwahrscheinlich „synthetisiert“, mithin „erfunden“.

      1. Servus!

        Ich würde sogar behaupten, dass es eine Webseite mit dem beschriebenen Link nicht gibt. Die URL wurde höchstwahrscheinlich „synthetisiert“, mithin „erfunden“.

        Ja, das hat @krjdev ja so beschrieben:

        www.[ENTFERNT].com 40.77.167.17 - - [22/Oct/2021:16:08:00 +0200] "GET /search/pXrnX+casero?top HTTP/1.1" 400 0 "" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" - -

        [Ich habe die Anfrage im Serverlog entschärft, war nicht jugendfrei.)

        Fiktive Seiten wurden aufgrund des falschen StatusCodes ungeprüft in Suchmaschinen übernommen, die Suchergebnisse suggerieren eine Porno-Seite - Interessierte nehmen Abstand vom Besuch der vorhandenen, anständigen Hauptseite.

        Deshalb der Appell von krjdev, doch sein CMS/ Webauftritt so zu programmieren, dass immer der richtige statusCode ausgeliefert wird.

        Herzliche Grüße

        Matthias Scharwies

        --
        Einfach mal was von der ToDo-Liste auf die Was-Solls-Liste setzen.“
        1. Das Problem ist für mich ja nicht das Suchmaschinen, dass als Pornoseite darstellen.

          Da ich die Serverlogs nicht immer kontrolliert habe und nur gelegentlich überflogen habe, könnte es durchaus sein, dass auch illegale Anfragen hier eingetragen wurden.

          Weil wir gerade bei Pornos sind: Stichwort Kinderpornographie.

          Deswegen ist das für mich dramatisch.

          1. Deswegen ist das für mich dramatisch.

            Nochmal: Das sind synthetisierte Abfragen von irgendwelchen Typen, die irgendwas versuchen und sich - das ist recht geschickt - hinter einer IP von Microsoft und der Angabe von Bing als UserAgent verstecken.

            Das beschriebene Problem ist eine „Fata Morgana“. Es scheint so, ist aber anders.

            1. Das Problem ist definitv keine Fata Morgana.

              Wenn die IP-Adresse von irgendwelchen Helden gekapert wurde, dann hat MS ein Sicherheitsproblem. Außerdem kann man in der Bing Serach Konsole die IP Adressen auf gültige Bots überprüfen. Beweise?

              $ whois 40.77.167.17
              
              #
              # ARIN WHOIS data and services are subject to the Terms of Use
              # available at: https://www.arin.net/resources/registry/whois/tou/
              #
              # If you see inaccuracies in the results, please report at
              # https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
              #
              # Copyright 1997-2021, American Registry for Internet Numbers, Ltd.
              #
              
              
              NetRange:       40.74.0.0 - 40.125.127.255
              CIDR:           40.96.0.0/12, 40.125.0.0/17, 40.124.0.0/16, 40.76.0.0/14, 40.74.0.0/15, 40.80.0.0/12, 40.112.0.0/13, 40.120.0.0/14
              NetName:        MSFT
              NetHandle:      NET-40-74-0-0-1
              Parent:         NET40 (NET-40-0-0-0-0)
              NetType:        Direct Assignment
              OriginAS:       
              Organization:   Microsoft Corporation (MSFT)
              RegDate:        2015-02-23
              Updated:        2015-05-27
              Ref:            https://rdap.arin.net/registry/ip/40.74.0.0
              
              
              
              OrgName:        Microsoft Corporation
              OrgId:          MSFT
              Address:        One Microsoft Way
              City:           Redmond
              StateProv:      WA
              PostalCode:     98052
              Country:        US
              RegDate:        1998-07-10
              Updated:        2021-10-13
              Comment:        To report suspected security issues specific to traffic emanating from Microsoft online services, including the distribution of malicious content or other illicit or illegal material through a Microsoft online service, please submit reports to:
              Comment:        * https://cert.microsoft.com.  
              Comment:        
              Comment:        For SPAM and other abuse issues, such as Microsoft Accounts, please contact:
              Comment:        * abuse@microsoft.com.  
              Comment:        
              Comment:        To report security vulnerabilities in Microsoft products and services, please contact:
              Comment:        * secure@microsoft.com.  
              Comment:        
              Comment:        For legal and law enforcement-related requests, please contact:
              Comment:        * msndcc@microsoft.com
              Comment:        
              Comment:        For routing, peering or DNS issues, please 
              Comment:        contact:
              Comment:        * IOC@microsoft.com
              Ref:            https://rdap.arin.net/registry/entity/MSFT
              
              
              OrgTechHandle: IPHOS5-ARIN
              OrgTechName:   IPHostmaster, IPHostmaster 
              OrgTechPhone:  +1-425-538-6637 
              OrgTechEmail:  iphostmaster@microsoft.com
              OrgTechRef:    https://rdap.arin.net/registry/entity/IPHOS5-ARIN
              
              OrgAbuseHandle: MAC74-ARIN
              OrgAbuseName:   Microsoft Abuse Contact
              OrgAbusePhone:  +1-425-882-8080 
              OrgAbuseEmail:  abuse@microsoft.com
              OrgAbuseRef:    https://rdap.arin.net/registry/entity/MAC74-ARIN
              
              OrgTechHandle: MRPD-ARIN
              OrgTechName:   Microsoft Routing, Peering, and DNS
              OrgTechPhone:  +1-425-882-8080 
              OrgTechEmail:  IOC@microsoft.com
              OrgTechRef:    https://rdap.arin.net/registry/entity/MRPD-ARIN
              
              OrgDNSHandle: YSRH-ARIN
              OrgDNSName:   Yalamati, Sree Raghu Harsha 
              OrgDNSPhone:  +917702220771 
              OrgDNSEmail:  v-raghuy@microsoft.com
              OrgDNSRef:    https://rdap.arin.net/registry/entity/YSRH-ARIN
              
              
              #
              # ARIN WHOIS data and services are subject to the Terms of Use
              # available at: https://www.arin.net/resources/registry/whois/tou/
              #
              # If you see inaccuracies in the results, please report at
              # https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
              #
              # Copyright 1997-2021, American Registry for Internet Numbers, Ltd.
              
            2. Hier der Beweis...

              Der Beweis

              1. Also, die Whois-Daten habe ich schon gezeigt.

                Ich habe dort durchaus auch gesehen, dass „17.167.77.40.in-addr.arpa“ zu „msnbot-40-77-167-17.search.msn.com“ aufgelöst wird.

                Das kann eine veraltete Information sein (z.B. kann die Datenbank fehlerhaft sein, und die von Dir gezeigte Verifizierungsseite benutzt ebenfalls das DNS… und Reverse-Lookup-Datenbanken werden oft schlecht gepflegt (soweit das nicht ein DHCP-Server macht - aber selbst dann)

                Soweit es nicht an dem ist, solltest Du bei Bing mal nachfragen, wieso die eigentlich Abfragen starten, die zu einem 400er „Bad Request“ führen. Das kann, wie schon geschrieben, als Ursache haben, dass unzulässige Daten übertragen werden. Das wider kann alles mögliche sein, wie z.B. ein riesiges Cookie. Nur bekommt man das wiederum der Definition gemäß eben nicht nicht in einer URL unter. Das müsste man aber, wenn der Request von (angeblich!) Bing darauf beruht, dass irgendjemand irgendwo eine Webseite mit einem solchen böswilligen Link hingesetzt hat.

                Möglicherweise suchen die ja gehackte Webserver um dann den Request via Browser zu unterbinden. In dem Fall ist durch den 400er klar, dass Dein Server nicht gehackt oder „böse“ ist.

                Wenn Du aber schon mal die Webmastertools von Bing benutzt: Warum suchst Du nicht mal, ob Bing den angeblichen Link und also die Seite, auf der der stehen soll, kennt?

                Das müsste ja an dem sein.

                1. Ich habe mit dem Support schon Mailverkehr.

                  Leider habe ich noch keine Erklärung erhalten.

                  Der Supportmitarbeiter muss noch auf die Antwort von den Zuständigen warten.

            3. Hallo Raketenflugkontrolle,

              sich - das ist recht geschickt - hinter einer IP von Microsoft und der Angabe von Bing als UserAgent verstecken.

              Ich habe keinen Überblick über die IPs von Microsoft, aber das könnte ein Teil der Azure-Farm sein und die Bing-Bots könnten darauf laufen.

              Demnach würde jeder Azure-Kunde mit den gleichen IPs vorbeikommen.

              Rolf

              --
              sumpsi - posui - obstruxi
        2. Fiktive Seiten wurden aufgrund des falschen StatusCodes ungeprüft in Suchmaschinen übernommen…

          Nein! Gerade nicht. Der Grund für den 400er liegt außerhalb der URL, also kann den eine Suchmaschine gar nicht haben....

    2. Ich kann Dir auch versichern, dass nicht mal das Modul rewrite des Apache mit der Anfrage belästigt wird: Ich habe nämlich schon versucht, solche Requests an ein PHP-Skript zu übergeben und wollte nicht nur die IP für ein Stündchen sperren, sondern mir solche fehlerhaften Requests auch mal wegloggen und ansehen.

      Da wurde aber nichts draus.

      Der Apache sendet den 400er header (stets ohne Payload), schreibt den Protest ins error.log. Mehr macht er offensichtlich nicht. Sogar Versuche, ihn mit einer Fehlerseite - aber für den Error 400 - zu überzeugen, hat nichts gebracht.

      Dann sollte man auch feststellen, dass 400er Fehler auch bei scheinbar gültigen URLs auftreten:

      X - - [24/Oct/2021:05:29:53 +0000] "GET / HTTP/1.1" 400 0 "-" "-"
      X - - [24/Oct/2021:08:52:55 +0000] "GET / HTTP/1.1" 400 0 "-" "-"
      X - - [23/Oct/2021:02:47:31 +0000] "GET / HTTP/1.1" 400 0 "-" "-"
      X - - [23/Oct/2021:08:16:16 +0000] "GET / HTTP/1.1" 400 0 "-" "-"
      

      Das ist die Beute der letzten 24 Stunden. Das zeigt aber, dass der Fehler des Requests nicht in der URL ist, sondern vermutlich ein anderer, unsauberer Request-Header Und was steht in einem Link? Richtig: Nur die URL.

      Kein Grund zu irgendwelcher Panik.

      Wie schon geschrieben, dass eine Webseite mit einem derartigem Link gibt, halte ich für „ausgemacht unwahrscheinlich, eigentlich unmöglich“.

      1. Dann sollte man auch feststellen, dass 400er Fehler auch bei scheinbar gültigen URLs auftreten:

        Scheinbar.

        Was du da an den Logs gezeigt hast, sind zum Beispiel Anfragen OHNE die Angabe des Hosts im Header.

        Das MUSS beim HTTP/1.1 vorhanden sein. Alle anderen Parameter wie User-Agent sind nicht notwendig. Kannst du gerne mit telnet oder openmSSL (via HTTPS) überprüfen.

        Soll ich mal auf die betreffende RFC verlinken?

        1. Was du da an den Logs gezeigt hast, sind zum Beispiel Anfragen OHNE die Angabe des Hosts im Header.

          Äh. Nein. Ich benutze virtuelle Hosts, die jeweils eigene Logfiles haben.

          CustomLog /var/log/apache2/code.fastix.org_access.log combined env=!dontlog
          

          im Custom-Log wird (gemäß der Voreinstellung) der Hostname nicht ins Log übernommen, weil der Host ja anderweitig fest steht.

          Das MUSS beim HTTP/1.1 vorhanden sein.

          Im Request: „ja“. Im Log: „nein“.

          1. Was du da an den Logs gezeigt hast, sind zum Beispiel Anfragen OHNE die Angabe des Hosts im Header.

            Äh. Nein. Ich benutze virtuelle Hosts, die jeweils eigene Logfiles haben.

            CustomLog /var/log/apache2/code.fastix.org_access.log combined env=!dontlog
            

            im Custom-Log wird (gemäß der Voreinstellung) der Hostname nicht ins Log übernommen, weil der Host ja anderweitig fest steht.

            Das MUSS beim HTTP/1.1 vorhanden sein.

            Im Request: „ja“. Im Log: „nein“.

            Das stimmt. Im Log steht das auch bei OpenBSD's httpd nicht. Also der Host steht nicht im Log. Allerdings ist die Angabe vom Host immer der Server selber an dem die Anfrage gestartet wird.

            Was ich damit meine, mache Angaben vom HTTP/1.1 Header werden nicht in das Logfile geschrieben. Bei OpenBSD je nach Einstellung nur der User-Agent und Refferer.

          2. Die Log was du da gezeigt hast "könnten" manuelle Anfragen mittels telnet oder openSSL sein von Leuten die wissen wollen was für einen Server du betreibst. Welche Versionsnummer und so weiter. Also ob sie im schlimmsten Fall einen Exploit verwenden können. Ich erläutere das Thema nicht mehr weiter worauf ich hinaus will. Aber ich glaube du wirst es sicherlich vermuten.

            1. Die Log was du da gezeigt hast "könnten" manuelle Anfragen mittels telnet oder openSSL sein von Leuten die wissen wollen was für einen Server du betreibst.

              Natürlich ist das „Stochern im Nebel“. Aber manuell? Telnet? Pures openSSL? Eher nicht. Es gibt genug „Hacking-Tools“, die Wunder versprechen.

              Und es gibt wohl auch genug IoT-Dinger mit seltsamen Webservern (nicht vergessen: Wordpress-(und andere) Installationen ohne Updates) - die man mit sowas hacken kann.

              Wenn ich Dich inzwischen richtig verstanden habe sendest Du selbst mit PHP einen 400er. Das solltest Du NICHT tun, überlass den 400er dem Apache exclusiv, damit Du Hänsel und Gretel unterscheiden kannst.

              1. Hallo Raketenflugkontrolle,

                überlass den 400er dem Apache exclusiv, damit Du Hänsel und Gretel unterscheiden kannst.

                Diese Idee mag ich nicht unterstützen. HTTP Codes haben eine bestimmte Bedeutung, und wenn ein erwarteter Parameter nicht da ist, ist Bad Request genau die richtige Antwort.

                Was soll er denn sonst schicken? 5xx? 402? 418? 301 nach google.de?

                Ich weiß nicht, wieviel Content der Apache bei einem 400er schickt. Das müsste man sich anschauen und aus dem PHP eine Antwort zur 400 schicken, deren Länge sich deutlich unterscheidet. Dann wäre das im Log ein Unterscheidungsmerkmal.

                Für Netzwerk-Traces reicht ja auch der X-Powered-by Header, den PHP schickt, sofern man das nicht verhindert.

                Rolf

                --
                sumpsi - posui - obstruxi
                1. Ich weiß nicht, wieviel Content der Apache bei einem 400er schickt.

                  Keinen.

                  Das müsste man sich anschauen und aus dem PHP eine Antwort zur 400 schicken, deren Länge sich deutlich unterscheidet.

                  Das teste ich gleich mal...

                  1. <?php
                    http_response_code(400);
                    header("Content-Type: text/plain; charset=UTF-8");
                    
                    echo "0123456789";
                    

                    gefällt mir nicht, geht aber.

                    Im Log:

                    X - - [24/Oct/2021:13:21:20 +0000] "GET /Tests/400-test.php HTTP/1.1" 400 803 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0"
                    

                    Ich würde einen 403er schicken, wenn mir jemand mit krummen Zeug kommt. Ist es Zeug, das z.B. mit Nessus getestet wird, dann kümmert sich der Honeypot darum und blockt die IP 60 Minuten.

                    Das hat meine Logfiles sehr verkürzt.

              2. Ich verwende aber nicht Apache!

                Schön, wenn es der Apache kann. Aber dann müsste ich den Apache über die Portssammlung kompilieren.

                Ich verwende auf die Server OpenBSD. Nicht Linux. Nicht falsch verstehen, ich mag Linux. Ist aber meine Entscheidung das mit OpenBSD.

                1. Hallo krjdev,

                  es ist doch wurscht, ob Du Apache, NGinx, den httpd von OpenBSD oder einen C64-Emulator mit Contiki verwendest. Die Konzepte sind die gleichen.

                  Rolf

                  --
                  sumpsi - posui - obstruxi
                  1. Lieber Rolf,

                    C64-Emulator mit Contiki

                    ah, der gute alte Brotkasten. Damals hatten wir an der Schule Steckmodule mit EPROMs gelötet. 512K! Ich konnte ein Spiel darauf speichern, welches beim Laden mehrere Diskettenseiten benötigte, nun aber mit einem Tastaturkommando in den Speicher geladen werden konnte! Good times, good times.

                    Liebe Grüße

                    Felix Riesterer

    3. Es steht deswegen 400 im Serverlog, weil ich den Code vor ungefähr einer Woche ausgebessert habe.

      Jetzt werden eh alle ungültigen Anfragen richtig behandelt.

      Das Problem bestand bei mir aber seit 2020 bis vor kurzem.

      Ich habe die Server jetzt aber ausgeschaltet.

      Ich weiß, der Artikel ist allgemein gehalten. Nicht nur auf PHP bezogen. Kann eventuell auch mit ASP passierenn

      1. Es steht deswegen 400 im Serverlog, weil ich den Code vor ungefähr einer Woche ausgebessert habe.

        Ultimatives „Nein“. Das mag Deine Erinnerung sein, es ist aber falsch.

        Vergiss nicht, dass Du das nur in den Logfiles findest, wenn das auch versucht wird… Ein Eindruck kann also trügen.

        Wie ich gezeigt habe, gibt es 400er auch beim Abruf der Index-Seite (GET /). Also ist nicht die URL ungültig sondern es werden weitere Header gesendet, die aus Sicht des Webservers ungültig sind.

        Ich gehe davon aus, dass da pauschal versucht wird, Daten auf den Webserver zu übertragen, die Du nicht siehst – also z.B. (ZUM BEISPIEL) DAV-Daten mit der unzutreffenden Methode GET…

        1. Ich bezweifle, dass du den jetzigen PHP code von meinem Server kennst.

          Weil: Es mag eventuell nicht RFC konform sein. Aber ich behandle im PHP code Fehler so:

          Alle PHP Anfragen die einen ungültigen Parameter haben. Alles alles was derzeit nicht lang ist, behandle ich mit 400.

          Alle URL's OHNE Parameter mit 404.

          1. Ich bezweifle, dass du den jetzigen PHP code von meinem Server kennst.

            Das muss ich nicht! Der Statuscode 400 zeigt, dass PHP für die Abfrage gar nicht erst belastigt wird. Ebensowenig mod_rewrite.

            Das hab ich auch schon geschrieben.

            1. Hi,

              Ich bezweifle, dass du den jetzigen PHP code von meinem Server kennst.

              Das muss ich nicht! Der Statuscode 400 zeigt, dass PHP für die Abfrage gar nicht erst belastigt wird. Ebensowenig mod_rewrite.

              es sei denn, der Request geht bis zum PHP-Interpreter durch, und das Script sendet selbst den Status 400 als Antwort.

              Das hab ich auch schon geschrieben.

              Ja, und es stimmt unter der Annahme, dass der Request wirklich fehlerhaftes HTTP ist.
              Aber nur dann.

              Live long and pros healthy,
               Martin

              --
              Bei Erwärmung steigt das Thermometer, bei Erkältung singt es.
              1. Das muss ich nicht! Der Statuscode 400 zeigt, dass PHP für die Abfrage gar nicht erst belastigt wird. Ebensowenig mod_rewrite.

                es sei denn, der Request geht bis zum PHP-Interpreter durch, und das Script sendet selbst den Status 400 als Antwort.

                Also aus dem Sinnzusammenhang heraus sollte der TO doch wissen, was seine SELBST geschriebenen Skripte so treiben - oder?

                1. Hallo Raktenflugkontrolle,

                  weiß er. Schrub er doch. Er schickt 400 bei falschem Query Parameter.

                  Rolf

                  --
                  sumpsi - posui - obstruxi
                  1. weiß er. Schrub er doch. Er schickt 400 bei falschem Query Parameter.

                    Du meinst bestimmt das hier:

                    Es steht deswegen 400 im Serverlog, weil ich den Code vor ungefähr einer Woche ausgebessert habe.

                    Naja. Wenn dass die „Ausbesserung“ sein sollte dann hätte er sein Zeug selbst mächtig gewaltig verschlimmert. Ich hab das auch nicht so interpretiert, weil er ja sonst von 404er schreibt…

                    Und bekanntlich gilt:

                    ( 400 != 404 ) === TRUE 
                    

                    Ich bin davon ausgegangen, dass er dem zufällig entstandenem Eindruck aufgesessen ist, dass nach seinen Änderungen keine 400er mehr auftraten.

                    1. Hallo Raketenflugkontrolle,

                      konkret meine ich das hier:

                      Alles alles was derzeit nicht lang ist, behandle ich mit 400.

                      Ich deute das so, dass "lang" ein Parametername ist. Fehlt der, gibt's den 400 auf die naseweisen Fingerchen.

                      Rolf

                      --
                      sumpsi - posui - obstruxi
                    2. jetzt hab ich es gesehen.

                      Alle PHP Anfragen die einen ungültigen Parameter haben. Alles alles was derzeit nicht lang ist, behandle ich mit 400.

                      Was bedeutet denn „Alles alles was derzeit nicht lang ist“???

                      Und warum (zum Teufel!) einen 400er? Es gibt so viele schöne dreistellige Zahlen, die 4 beginnen!

                      Und wenn man nicht ausgerechnet die 400 hernimmt, dann kann man am Log auch sehen, was passiert ist.

                      1. Es mag sicherlich noch immer Bad-Design sein, aber ich musste das auf die schnelle machen.

                        Zum Beispiel kommen "gelegentlich" Anfrage mit Parametern in die PHP Code eingeschleust werden kann.

                        Kann da auch, müsste ich im Log nachschauen, was zeigen.

                        1. Hallo krjdev,

                          Zum Beispiel kommen "gelegentlich" Anfrage mit Parametern in die PHP Code eingeschleust werden kann.

                          Bei einer korrekten Programmierung des Kontextwechsels im PHP und einer gründlichen Überprüfung des übergebenen Wertes können Dir die vollkommen schnuppe sein.

                          Wenn Du natürlich ohne vorhergehende Validierung sowas wie

                          include "components/" . $_GET['lang'] . ".php";
                          

                          in deinem Code hättest (oder eine Variante mit readfile), fliegst Du mit Schwung und dreifachem Salto auf die Nase.

                          Rolf

                          --
                          sumpsi - posui - obstruxi
                          1. Hallo krjdev,

                            Zum Beispiel kommen "gelegentlich" Anfrage mit Parametern in die PHP Code eingeschleust werden kann.

                            Bei einer korrekten Programmierung des Kontextwechsels im PHP und einer gründlichen Überprüfung des übergebenen Wertes können Dir die vollkommen schnuppe sein.

                            Gebe ich dir natürlich recht. Aber ich lebe aufgrund diesen Fehlers jetzt bei dieser Sache nach dem Motto: Vorsicht ist die Mutter der Porzellankiste.

                            Auch im PHP Interpreter werden manchmal Sicherheitslücken gefunden. Und deswegen versuche ich, wenn möglich alle Angriffe abzuwehren.

                            Zugegeben, meine Kenntnisse in PHP sind noch nicht so groß. Bin eigentlich ein low-level Programmierer. C und Assembler ist mein Ding.

                        2. Zum Beispiel kommen "gelegentlich" Anfrage mit Parametern in die PHP Code eingeschleust werden kann.

                          Aua! Wenn ich mir nicht absolut sicher wäre, dass niemand derlei in mein Zeug per Request einschleusen kann, dann würde ich meine Seite auch vom Netz nehmen.

  3. Hallo krjdev,

    vielleicht bin ich ja einfach zu blöd. Aber dein Artikel ist dermaßen weichgespült, dass ich nicht kapiere, wie sich das Problem überhaupt äußert. Ich versuche darum mal wiederzugeben, wie ich das verstanden habe.

    Angenommen, deine Seite wäre www.example.org gewesen. Da gibts - hypothetisch - index.php, auf dem HTML-Output dieser Seite wird ./img/logo.svg angezeigt und index.php hat einen Query-Parameter, z.B. index.php?content=myprojects, der den gewünschten Inhalt auswählt. Dieser Inhalt bringt vielleicht auch noch eigene Links mit, die z.B. auf index.php?content=selfhtml oder sowas verweisen. Im Detail mag es bei Dir anders implementiert gewesen sein, ist auch egal, es geht um's Prinzip.

    Nun kommt Carl Crawlme vorbei, weil Du die index.php bei der Suchmaschine deines geringsten Misstrauens angemeldet hast. Er ruft also index.php ab (die ohne Parameter die Seite für content=startpage liefert), guckt in die robots.txt und folgt - sofern nicht per robots.txt missbilligt, den diversen Links. Diese verweisen hoffentlich alle auf valide Artikel deiner Seite. Einige mögen tot sein, kann ja mal vorkommen, aber keiner davon würde - beispielsweise - mit dem Linktext "All Your XXX Dreams" auf ?content=xxx_dreams verweisen. Und wenn doch - nun ja, dann wärest Du selbst schuld und würdest hier keine Warnungen verkünden, gelle?

    Bis hierher sehe ich keine Chance für ein Problem, denn Carl Crawlme käme von sich aus nicht auf die Idee, bei Dir eine unverlinkte Unterseite abzurufen. Eine Suchmaschine käme von sich aus auch nicht auf die Idee, bei der Suche nach XXX Dreams deine Seite einzubeziehen.

    Oder doch? Keine Ahnung - manche Webseiten scheinen es zu schaffen, auf jede Google-Suche eine Antwort zu liefern und wollen mir - fast egal, wonach ich suche - die besten Angebote zu diesem Thema machen. Gibt's da bei Google einen Hook, mit dem man sich in jegliche Suche einklinken kann? Oder haben die einfach nur so viele Adwords gekauft? ABER: Das wäre eine Aktivität von Dir. Google oder Bing machen das nicht von sich aus.

    Wenn statt Carl Crawlme nun Kitty Scriptkid vorbeikommt und mal blindlings ein paar URLs auf deiner Seite durchprobiert, z.B. ./hot-dreams.html oder ./xxx/index.html, dann machst dein PHP Fehler auch kein Problem, denn an der Stelle schlägt der Indianerhäuptling zu und schickt von sich aus einen 404. Kritisch wird es, wenn Kitty Scriptkit irgendwie drauf kommt, dass deine Links alle index.php?content=... heißen und DA was durchprobiert. Aber das wäre dann hochspezialisiert und an der Grenze der Vorstellbarkeit.

    Anders wird es, wenn - sagenwirmal - von irgendeinem Bösewicht auf top-links.example.kp ein vorsätzlich falscher Link dieser Art

    <a href="https://www.example.org/index.php?content=hot_dreams">
      All Your Hot Dreams
    </a>
    

    gesetzt würde. Carl Crawlme würde den sehen, ihm folgen und von Dir - wenn das dein Fehler war - einen HTTP 200 mit dem Text "Der Inhalt hot_dreams ist nicht vorhanden" bekommen. Aber - in dem Moment merkt sich die Suchmaschine, dass es von top-links.example.kp eine korrekte Verlinkung nach www.example.org gibt.

    So habe ich die von Dir - sehr schwurbelig - beschriebenen Hintergründe aufgefasst.

    Und was passiert nun damit?

    Irgendwer sucht nach krjdev und bekommt außer deiner Titelseite auch noch All Your Hot Dreams angeboten? Weil's die gleiche Domain ist?

    Oder sucht nach Hot Dreams und bekommt deine Seite als Treffer? Weil's im Linktext stand UND die beiden Worte auch noch auf dem Antworttext standen?

    Rolf

    --
    sumpsi - posui - obstruxi
  4. Hi there,

    und was hat das alles mit PHP zu tun?

    1. Hallo klawischnigg,

      weniger mit PHP als generell mit programmatisch generierten Webseiten.

      Nämlich nicht stumpf die 200-Response zu schicken, wenn die Query Parameter nicht passen.

      Rolf

      --
      sumpsi - posui - obstruxi
      1. Hi there,

        weniger mit PHP als generell mit programmatisch generierten Webseiten.

        Nämlich nicht stumpf die 200-Response zu schicken, wenn die Query Parameter nicht passen.

        Na schon, aber ich hab nach der Überschrift gedacht, ich finde hier einen "wichtigen" Hinweis im Umgang mit PHP😉. Stattdessen hat offenbar irgendjemand, der eine "nicht jungendfreie" Seite betreibt, Probleme mit irgendwelchen Suchmaschinen...

        1. Hallo klawischnigg,

          nee, betreibt er eben nicht. Sagt er zumindest. Aber er meint, in einen solchen Ruch gekommen zu sein.

          Ich mag jetzt aber auch nicht den Thread-Titel renamen.

          Rolf

          --
          sumpsi - posui - obstruxi
  5. Ich habe das übrigens mal als Anlass genommen, bei meiner Suche-Seite (die auch für die 404er zuständig ist)

    a) mit PHP

    <?php
    header( 'X-Robots-Tag: noindex');
    

    zu senden und b) im HTML

    <meta name="robots" content="noindex">
    

    zu notieren.

    Nicht, dass mir da jemand mit böswilligen Links was in die Suchergebnisse schmuggelt

    Das wäre auch geeignet, um Deinem Problem vorzubeugen.