[gelöst] Unbererechtiger Zugang zur Web-Site

[thoerb]

Für ein Szenario wie Deines hab ich damals™ gar nur Integers eines vorgegebenen Bereichs verwendet, und die Zuordnung im Script selbst gemacht, wobei alles verworfen wurde, für das es keine Zuordnung gab – gerade weil beliebige Eingaben halt problematisch sind.

So würde ich das wahrscheinlich auch machen.

Code: Alles auswählen

if ($url == "1"){

	$url = "Klapperkiste";
	
} elseif ($url == "2"){

	$url = "asdf";
	
} else {

	exit();
}

[TomL]

Den Vorschlag mit den Integers habe ich mir sofort als Beipackzettel zu meinem lokalen Script gesichert... und dem Vorschlag, das jetzt über mein Monitoring und den Log-Files sorgfältig zu beobachten, werde ich unbedingt folgen.

Soweit es das zweite Script angeht, war das eigentlich sehr ähnlich bzw. fast identisch, bezog sich aber auf downloadbare Dateien. Da hab ich aber jetzt konkrete zusätzliche Prüfungen eingebaut, also das der übergebene Parameter tatsächlich einer bereits vorhandenen Datei entspricht, die im korrekten Verzeichnis liegt und eine Größe >0 hat... bei jeglichem Prüfungs-Fehler wird sofort abgebrochen.

Ich werde das jetzt bis auf weiteres beobachten und beobachten lassen.

Danke an alle für die Unterstützung.

[inne]

In jedem PHP-Einsteigertutorial steht ziemlich am Anfang, dass man niemals Usereingaben ungefiltert und ungeprüft weiterverarbeitet

Mit dem von thoerb und einem Assert

[DeletedUserReAsG]

In jedem PHP-Einsteigertutorial steht ziemlich am Anfang, dass man niemals Usereingaben ungefiltert und ungeprüft weiterverarbeitet

Mit dem von thoerb und einem Assert

Auch in dem von thoerb verlinkten Tutorial steht’s, ja:

Think SECURITY when processing PHP forms!

This page does not contain any form validation, it just shows how you can send and retrieve form data.

However, the next pages will show how to process PHP forms with security in mind! Proper validation of form data is important to protect your form from hackers and spammers!

Bevor da Fragen kommen: GET benutzt man üblicherweise in Verbindung mit Formularen, deswegen steht’s da so, ist hier aber genauso anzuwenden.

[TomL]

Auch in dem von thoerb verlinkten Tutorial steht’s, ja:

Proper validation of form data is important to protect your form from hackers and spammers!

Da ist nichts, was ich sachlich nicht in vollem Umfang nachvollziehen kann, wenn dieser Textparameter bestimmten Anforderungen genügen muss oder eine Folgebearbeitung beinflusst... aber das liegt hierbei nicht an. Es bleibt also die Frage offen, nach welche Kriterien ich den übergebenen Text überhaupt validieren kann, wenn der einzige Anspruch ist, dass der String etwas ist, was sich aus beliebigen Zeichen zusammensetzt? Ob in der Text-Datei anschließend richtige und neben den richtigen auch falsche Zeilen-Daten drinstehen, macht weder für den Verwendungszweck noch für das Script einen Unterschied, weil das Script nicht wissen kann, ob ich als Betrachter den in die Datei eingetragenen Text als richtig oder irgendwas anderes beurteile.

Ich denke immer noch, die richtige Frage wäre, ob ein übergebener Inhalt als Anweisung ausgeführt werden kann.... das wäre nämlich echt dramatisch und ich würde das Script umgehend entfernen. Solange es sich bei dem Parameter jedoch nur um Buchstabensalat handelt, der als Buchstabensalat behandelt wird, ist das working as intended ... auch dann, wenn der Buchstabensalat den Text (i.ü.S.) "format c:" oder "rm -rf /*" beinhaltet.

[irgendwas]

Es bleibt also die Frage offen, nach welche Kriterien ich den übergebenen Text überhaupt validieren kann, wenn der einzige Anspruch ist, dass der String etwas ist, was sich aus beliebigen Zeichen zusammensetzt?

Da gibt es ganz bestimmt ein passendes Kriterium, oder sind auch Sonderzeichen notwendig? Filter einfach über einen regulären Ausdruck. Werden die Anforderungen nicht erfüllt -> Skript beenden.

[DeletedUserReAsG]

TomL, mein letzter Post war eigentlich die Antwort auf inne, in dessen Post ich die Frage interpretiert habe, ob die gequotete Aussage von mir auch in dem von thoerb verlinkten Tutorial vorhanden ist – deswegen habe ich es rausgesucht und gepostet.

Es bleibt also die Frage offen, nach welche Kriterien ich den übergebenen Text überhaupt validieren kann, wenn der einzige Anspruch ist, dass der String etwas ist, was sich aus beliebigen Zeichen zusammensetzt?

Ich denke nicht, dass es ein Szenario gibt, in dem wirklich beliebige Zeichen auf diesem Weg übergeben werden müssen. Und selbst, wenn man’s, warum auch immer, trotzdem macht, kann man die potentiell gefährlichen Zeichen entschärfen, bevor man die Variable auf irgendeine potentiell gefährliche Weise weiterverarbeitet (etwa in ’ne Datei oder gar in eine Datenbank schreibt¹).

Ich denke immer noch, die richtige Frage wäre, ob ein übergebener Inhalt als Anweisung ausgeführt werden kann. […] Solange es sich bei dem Parameter jedoch nur um Buchstabensalat handelt, der als Buchstabensalat behandelt wird, ist das working as intended ... auch dann, wenn der Buchstabensalat den Text (i.ü.S.) "format c:" oder "rm -rf /*" beinhaltet.

Und ich denke immer noch, dass genau das passiert ist. Es scheint zwar nicht mehr so einfach zu sein, wie ganz früher™, als Variablen durch ihren Inhalt ersetzt wurden, und das durch den Interpreter geschoben wurde – da hätte etwas in der Art › "; böserCode; ?> ‹ gereicht², aber ich denke weiterhin, dass das zum Angriff verwendete Script hier den Interpreter dazu gebracht hat, die Variable eben nicht nur als Zeichenkette zu handhaben, sondern Teile davon zu verarbeiten, oder in die Datei zu schreiben, und diese dann auszuführen. Möglicherweise hat die verwendete PHP-Version dabei mit einer bekannten Schwachstelle geholfen – deswegen fragte ich nach dieser Version, dann hätte man mal schauen können, ob da was bekannt ist. Vielleicht hat das zweite Script auch einen Punkt, den du übersehen hast. Auf jeden Fall aber ist in meinem mentalen Syntax-Highlighting die Variable $url, die ungeprüft aus GET übernommen, und ungefiltert in eine Datei geschrieben wird, fett grellrot markiert und mit vielen Ausrufezeichen versehen.

Leider ist meine PHP-Phase lange her, und es fehlt mir wirklich an Zeit und anderen Ressourcen, mich da wieder reinzufinden und die aktuellen Methoden zu recherchieren. Interessant zu wissen, was nun tatsächlich passiert ist, wär’s allemal – deswegen meine Anregung, das Ganze quasi als Honigtopf wieder draufzutun, und dann, nachdem dein Alarm für erstellte Dateien ausgelöst wurde, mal im Log zu schauen, was denn nun eigentlich passiert ist. Möglich ist allerdings auch, dass im März ein Bug in PHP genutzt wurde, der das Ausnutzen deines Handlings von nutzerübergebenen Daten erst ermöglicht hat, und dass dein Anbieter zwischenzeitlich ’n Update gefahren hat. In dem Fall würde da natürlich nichts weiter passieren – umschreiben würde ich das Script aber auf jeden Fall.

¹) tatsächlich dürfte so eine SQL-Injektion, bei der Zeichenfolgen übergeben werden, die zwar der PHP-Interpreter nicht ausführt, das DBMS dann allerdings schon, auch heute noch einer der häufigsten Angriffsvektoren sein

²) minimal umständlicher war’s schon noch – aber immer noch nix, was man nicht hätte scripten können

[TomL]

@niemand

Danke, das alles hat mir sehr dabei geholfen, das Problem etwas besser einzuordnen. Und mal am Rande bemerkt, das hat mir gestern den ganzen Tag über solche mentale Anspannung verschafft, durch Suchen im Web, Fragen finden, Antworten darauf suchen, Zusammenhänge begreifen, mit ständig hoher Konzentration und Motivation, dass ich heute Nacht echt scheisse geschlafen hab keine Ruhe gefunden. Boar, was man doch das "Stress aushalten" (selbst wenns 'nen Eigenbaustress ist) verlernt, wenn man einmal aus der Tretmühle raus ist.... ein Nachteil des Ehrgeizes zu verstehen, was man da überhaupt tut.

Wenn ich das alles richtig interpretiere, hat es also irgendwer irgendwie geschafft ca. im März diesen Jahres ein php-Script und eine Textdatei mit über 1600 Web-Sites auf meinen Speicher hochzuladen. Ich denke, diese Textdatei dient als Vorlage für die Seiten, die sich das Script mit einem Hackingversuch vornimmt. Das heißt im Klartext, eine Lücke auf meiner Web-Site hat letztlich dazu geführt, dass meine Kundenressourcen bei diesem Hoster für illegale Zwecke missbraucht wurden.

BTW, ich habe bisher allerdings vergessen, einen wichtigen Begleitumstand zu nennen... sorry... meine Seite ist ja nicht neu, die gibts seit 3 oder 4 Jahren ... dieser Vorfall war definitiv der erste und bisher einzige Vorfall.

Ich werds deshalb genau so tun, wie Du vorgeschlagen hast.... die Scripte mit einigen verbessernden Anpassungen erst mal wieder laufen lassen und ein zweifaches Monitoring installieren. Zweifach, um
- einerseits täglich auf fremde, neue Dateien zu prüfen
- andererseits das Log täglich für den Vortag zu prüfen, siehe Beispiel:

Code: Alles auswählen

$ zgrep POST access_jun.log.gz | awk -F ' ' '{if($4 ~ "29/Jun/2020") {print}}'
89.245.63.0 - - [29/Jun/2020:18:51:56 +0200] "POST /maindi.php HTTP/1.1" 404 196 "-" "curl/7.64.0"
89.245.63.0 - - [29/Jun/2020:18:53:17 +0200] "POST /maindi.php HTTP/1.1" 404 196 "-" "curl/7.64.0"
89.245.63.0 - - [29/Jun/2020:18:53:26 +0200] "POST / HTTP/1.1" 200 116337 "-" "curl/7.64.0"
89.245.63.0 - - [29/Jun/2020:18:55:45 +0200] "POST / HTTP/1.1" 200 116337 "-" "curl/7.64.0"
89.245.63.0 - - [29/Jun/2020:18:56:06 +0200] "POST /irc HTTP/1.1" 404 196 "-" "curl/7.64.0"

In dieser Form ist es dann ausreichend dynamisch:

Code: Alles auswählen

gestern=$(date --date="-1 day" "+%d/%b/%Y")
monat=$(date --date="-1 day" "+%b")
monat=${monat,,} 
zgrep POST access_$monat.log.gz | awk -F ' ' '{if($4 ~ "$gestern") {print}}'

Du hattest die Stichworte "POST" und "curl" erwähnt... ich glaube, genau darauf werde ich jetzt durch ein kleines Programm gezielt achten lassen. Via cron auf meinem heimischen Server gestartet, anmelden via SSH, alles prüfen und ggf. eine Benachrichtigung an mich senden.

[DeletedUserReAsG]

curl war allerdings auch nur ein Beispiel – einerseits lässt sich dort der User-Agent einfach anders angeben, so dass beispielsweise ’n legitimer Browserstring an dieser Stelle im Log erscheint, andererseits gibt es hunderte Möglichkeiten, das Gleiche zu erreichen. Auf das Greppen dieses Strings würde ich mich also nicht vollständig verlassen. Auch wird, wenn es denn über dein Script gelaufen ist, zunächst GET benutzt worden sein – das liest du ja schließlich im Script aus, POST würde also ins Leere gelaufen sein.

Mal ein zufälliger Versuch aus meinem Log, damit du ungefähr siehst, wie’s aussehen kann:

Code: Alles auswählen

192.241.xxx.xxx - - [04/Jul/2020:19:56:59 +0000] "GET /owa/auth/logon.aspx?url=https%3a%2f%2f1%2fecp%2f HTTP/1.1" 404 3963 "-" "Mozilla/5.0 zgrab/0.x"

Hätte dort das Script gelegen, hätte es die codierte Zeichenfolge https%3a%2f%2f1%2fecp%2f via GET bekommen, was bei dem konkreten Script (logon.aspx von irgend’ner Software) in irgendeiner Version vermutlich einen ausnutzbaren Fehler getriggert hätte. Die xxx in der IP hab ich da übrigens reingemalt, falls der Host sowas wie dein Webspace gewesen ist: irgendjemand hat’s aufgemacht und nutzt es, um weitere Kisten zum Aufmachen zu finden.

[eggy]

dieser Vorfall war definitiv der erste und bisher einzige Vorfall.

Würde ich nicht drauf wetten. Es war der erste Vorfall, der Dir aufgefallen ist.

was bei dem konkreten Script (logon.aspx von irgend’ner Software) in irgendeiner Version vermutlich einen ausnutzbaren Fehler getriggert hätte.

https://isc.sans.edu/forums/diary/Scann ... ECP/26132/

[TomL]

Würde ich nicht drauf wetten. Es war der erste Vorfall, der Dir aufgefallen ist.

Das stimmt natürlich. Aber ich begründe meine Annahme damit, dass der Web-Space, wenn er einmal kompromittiert ist, nicht direkt nach dem erfolgreich ausgeführten Fremd-Script mit illegalen Absichten sofort auch wieder ordentlich aufgeräumt verlassen wurde, wenn das Script fertig ist. Ich würde annehmen, ist es einmal geschafft so ein Script zu installieren, wird das auch solange genutzt, wie es nur irgendwie geht. Und ich glaube, dass mir das in solchem Fall wirklich schon früher mal aufgefallen wäre, wenn da solche fremden Dateien aufgetaucht wären... aber wirklich sicher sein kann man natürlich nie.

Na klar, hätten die 'ne Schwingtür verfügbar (z.B.durch Missbrauch eines legalen Zugangspassworts), und man verfährt damit nach der Devise rein-upload-job-del-raus, dann hätte ich das garantiert nicht bemerkt. Aber ich hoffe, dass das jetzt nicht mehr möglich ist, weil...

- Die theoretisch trotzdem vorhandene mögliche PWD-Lücke ist zu
- Script-Integrität ist verbessert
- Zugang nur noch via SSH
- Monitoring auf Content und Logfiles ist eingerichtet

Ich muss das jetzt einfach beobachten.... und ich gestehe... mangels kompletter Fehleinschätzung habe ich die Logs leider auch vernachlässigt. Über sowas wie das hier ...
41083
... bin ich erst jetzt zum ersten Mal gestolpert. Unglaublich..... und wenn ich das richtig interpretiere, muss ich mir immer an dem Punkt Gedanken machen, wenn hierbier '404' nicht die Antwort wäre.

[TRex]

Das ist aber normal - automatisierte Scans über bekannte Lücken. Lektion daraus ist: hab keine angreifbare Standardsoftware. Eigentlich ist damit wordpress und phpmyadmin bei den meisten "Admins" raus

[JTH]

Interessantes Thema. Mein Kontakt mit PHP ist auch schon ein paar Jahre und Versionen her.

Trotzdem als (wahrscheinlich) sehr naiver Gedanke, was bei deinem Skript im Ansatz händisch möglich wäre:
Du nimmst, wie mehrfach angemerkt, den Input ja bisher komplett ungefiltert (filter_input(), strip_tags()) entgegen. Damit könnte man dort z.B. auch PHP-Code einschleusen:

Code: Alles auswählen

curl 'http://example.org/k33.php?to=<?php echo "Evil script doing its thing ...\n"; $f=fopen("evil.php", "w"); fwrite($f, "..."); fclose($f); ?>%00'

Der steht jetzt in visitors/X-Y-ViewCounts.db, plus ältere gewollte Logeinträge – die stehen aber einer Ausführung als PHP-Skript nicht im Wege.
Lässt die Konfiguration womöglich PHP in .db-Dateien zu oder findet man einen Weg, das in eine Datei mit Endung .php umzuleiten (dein zweites Skript?), ist die Scheune offen.

[TomL]

Das ist mal wieder so ein Moment, wo sich der Wortlaut im Koppe breit macht "ich könnt kotzen" .... deshalb, weil ich gar nicht so schlecht denken kann, wie andere kriminelle Ideen entwickeln.

Das, was JTH gerade beschrieben hat, kann sich imho wirklich zu einer gefährlichen Variante auswachsen ... da wäre ich doch von alleine nie drauf gekommen... boar ... ich habe jetzt gerade mal probiert die Datei ViewCounts.db direkt auf der Web-Seite adressiert zu öffnen, ganz normal mit Browser, ohne Login... so ein Mist, das geht ja völlig problemlos und die wird als Text angezeigt. Wenn da jetzt wirklich Text als interpretierbarer Code hinterlegt und auf irgendeinem Wege ausgeführt werden könnte, wars das...

Meine erste Gegenmaßnahme war jetzt sofort: 'deny from all' in einer htaccess im entsprechenden Verzeichnis. Dieser Zugang ist jetzt verbaut.

@ JTH

[thoerb]

Meine erste Gegenmaßnahme war jetzt sofort: 'deny from all' in einer htaccess im entsprechenden Verzeichnis. Dieser Zugang ist jetzt verbaut.

Ich würde trotzdem mal prüfen, ob sich diese *.db Datei mit PHP-Code direkt auf dem Server ausführen lässt.

[TomL]

Ich würde trotzdem mal prüfen, ob sich diese *.db Datei mit PHP-Code direkt auf dem Server ausführen lässt.

Sorry... aber da reichen meine php-Kenntnisse nicht aus. Wie kann ich denn diese Datei versuchsweise an den PHP-Interpreter als (scheinbar) ausführbare Datei übergeben? Mit der Extension '.db' und ohne Shebang wird die doch von alleine gar nicht als php-Script erkannt.

[JTH]

Im Zweifelsfall einfach im Browser aufrufen, z.B.:

Code: Alles auswählen

http://example.org/visitors/2020-07-ViewCounts.db

Das hast du durchs Deny from all aber nun wohl unterbunden.

Noch als Ergänzung, basierend auf meiner auffrischenden Lektüre vorhin zu PHP: Null-Bytes in Dateipfaden scheinen auch nen beliebtes Loch zu sein. Wenn du in deinem zweiten Skript etwa aus dem vom Benutzer kommenden Dateipfad (du schriebst etwas von Downloads) – ungefiltert – einen neuen konstruierst, könnte man da anscheinend evtl. beliebige Dateien schreiben.

[thoerb]

Code: Alles auswählen

<?php echo "Test"; ?>

In der Datei einfügen sollte reichen. Dann kannst du die Datei mit php *.db aufrufen.

Eine Shebang wird eigentlich nicht benötigt? Aber selbst wenn, könnte die der Angreifer ja auch rein schreiben.

[TomL]

Im Zweifelsfall einfach im Browser aufrufen, z.B.:

Das habe ich natürlich getestet... und das funktioniert jetzt nicht mehr. Infolgedessen kann das

Code: Alles auswählen

<?php echo "Test"; ?>

In der Datei einfügen sollte reichen. Dann kannst du die Datei mit php *.db aufrufen.

jetzt also auch nicht mehr funktionieren.

Aber im Rückblick, nach 'ner langen Kaffeepause, komme ich nicht umhin festzustellen, dass man alleine und als Laie mit dem Wissen der Hacker hoffnungslos überfordert ist. Insofern bin ich -auch rückblickend- mit meiner Entscheidung zufrieden, alle Zugänge zu heimischen Web-GUI-Schnittstellen, Web-Server, den zwei Mailserver-Prozessen oder allgemein ins LAN ausschließlich und rigoros auf das LAN zu begrenzen.

Ich bin jetzt fast davon überzeugt, dass vermutlich die meisten Laien-Web-Server-Admins ("ich bin ganz neu bei Linux und finde das echt super und habe gestern meinen Raspi zum ersten mal gestartet, wo finde ich eigentlich die config von meinem Sioux-Webserver, damit ich von unterwegs darauf zugreifen kann") nicht mal mitkriegen, wenn ihr ganzes Netzwerk von irgendwem übernommen wird. Und gleichzeitig wird von Antiviren-Software gelabert, oder wie man alles Surfen aller Clients via VPN-Provider einrichtet, wo man die Logs für fail2ban findet und ca. 85 Postings benötigt, um dem NIC 'ne Static-IP zu verpassen. Für mich ist hier ein Punkt erreicht, wo mich die Realität des Bösen-aus-dem-Web echt frustriert.

[thoerb]

Im Zweifelsfall einfach im Browser aufrufen, z.B.:

Das habe ich natürlich getestet... und das funktioniert jetzt nicht mehr. Infolgedessen kann das

Code: Alles auswählen

<?php echo "Test"; ?>

In der Datei einfügen sollte reichen. Dann kannst du die Datei mit php *.db aufrufen.

jetzt also auch nicht mehr funktionieren.

Korrigiert mich bitte, wenn das falsch sein sollte, aber mit htaccess kontrollierst du doch meines Wissens nur den Zugriff über http. Lokal sollte das noch ausführbar sein, wenn die Dateirechte dafür gegeben sind.

[TomL]

Korrigiert mich bitte, wenn das falsch sein sollte, aber mit htaccess kontrollierst du doch meines Wissens nur den Zugriff über http. Lokal sollte das noch ausführbar sein, wenn die Dateirechte dafür gegeben sind.

Vielleicht habe ich das missverstanden.... lokal kann ich das nicht ausführen, weils bei mir keinen lokalen php-Interpreter gibt. Ich müsste das also schon remote auf dem Web-Space-System mit dessen PHP ausführen ... aber da weiß ich nicht, wie das anders als via http gehen soll... und http ist ja jetzt unterbunden.

Nachtrag:
Ich habe zum Testen eine der DB-Files nach vorne (www) kopiert und als erstes das php-Statement eingefügt.

• Mit der Extension '.db'' wird die erste Zeile (das statement) übersprungen und der restliche Inhalt als Text ausgegeben.
• Mit der Extension '.php'' wird das Statement ausgeführt und der restliche Inhalt wie zuvor als Text ausgegeben.

Soweit es also die Extension ".db" angeht, betrachte ich das als örtliches Verhalten dieses Web-Servers.... ob das allerdings generell so ist ...?... keine Ahnung... vielleicht führen andere Maschinen das trotzdem aus....

[JTH]

Ich bin jetzt fast davon überzeugt, dass vermutlich die meisten Laien-Web-Server-Admins ("ich bin ganz neu bei Linux und finde das echt super und habe gestern meinen Raspi zum ersten mal gestartet, wo finde ich eigentlich die config von meinem Sioux-Webserver, damit ich von unterwegs darauf zugreifen kann") nicht mal mitkriegen, wenn ihr ganzes Netzwerk von irgendwem übernommen wird.

Ja, da hast du sicherlich recht. Leute, die sich unerfahren ihren eigenen Root-Server o.ä. aufsetzen, bekommen ja hier im Forum und anderswo auch (nicht umsonst) regelmäßig kopfschüttelnde und kritische Reaktionen.

[TomL]

Moin

Mein Monitoring funktioniert anscheinend. Ich habe heute morgen meine erste Mail bekommen. Die erste Nachricht, dass der Inhalt geändert wurde, ist soweit in Ordnung... beim Vergleich von gestern und vorgestern fehlten 2 Dateien, die ich gestern manuell von Hand gelöscht habe.... also soweit ok. Das jetzt beide Prüfungen eine Meldung beinhalten, ist also nur ein zufälliges gemeinsames Ereignis. Aber ich kann die beiden Schreibzugriffe (Log-Auszug) nicht einordnen, ich sehe da gar keinen Inhalt, wie muss man das interpretieren?

Beim Vergleich mit älteren Meldungen mit Inhalt sehe ich immer die Server-Antwort 404, also abgewiesen. Aber bei diesen 2 Kandidaten antwortet der Server 200, also OK. Nummer 1 ist Versatel, Nummer 2 ist Microsoft... also nicht die typischen Hacker. Meine Web-Site hat mit beiden nix zu tun... was tun die da ...?...ich bin jetzt nicht beunruhigt, aber doch einigermaßen ratlos.

Code: Alles auswählen

11-07-2020-01:00 Caution! Web-Space-Content was changed
11-07-2020-01:00 Caution! Write-Access to Web-Space found

89.245.101.0 - - [10/Jul/2020:02:29:00 +0200] "POST / HTTP/1.1" 200 116337 "-" "curl/7.64.0"
51.140.251.0 - - [10/Jul/2020:08:53:15 +0200] "POST / HTTP/1.1" 200 14559 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36"

[DeletedUserReAsG]

Microsoft mag Bingbot sein – wobei der sich eigentlich im Useragent zu erkennen gibt. Vielleicht jemand, der deren Clouddienste nutzt ….

Ansonsten sehe ich da nun nix, was irgendwie Fragen aufwerfen sollte.

[eggy]

Aber ich kann die beiden Schreibzugriffe (Log-Auszug) nicht einordnen, ich sehe da gar keinen Inhalt, wie muss man das interpretieren?

Ich versteh den Satz so, dass Du glaubst, dass "POST" als Schreibzugriff zu verstehen ist?

Schau Dir nochmal die Literatur an.

GET: The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
POST: The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server.

"should", nicht "must"; "often" nicht "everytime". Und https://tools.ietf.org/html/rfc1945#section-8 sagt auch, nur der Server entscheidet, was passiert:
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.

Wenn man es genauer wissen will, HTTP ist in den entsprechenden RFCs beschrieben. Fang beim Lesen ruhig mit dem veralteten HTTP/1.0 an, RFC 1945. Das benutzt so heute zwar hoffentlich niemand mehr, aber darauf baut der ganze moderne Krempel auf. Beim Lesen aber nicht vergessen: HTTP ist später noch (mehrfach) erweitert/geändert worden. HTTP 1.1 in RFC 2616, welches dann in mehrere andere RFCs aufgetrennt bzw durch andere ersetzt wurde. Welche RFCs das sind, steht dann meist oben im RFC (updated by/obsoleted by) . Weitere relevante RFCs, falls Dich das Thema tiefer interessiert, einfach mal selber suchen.

Wenn Du mal selbst probieren willst, Telnet eignet sich super, um Einträge in den eigenen Logs zu provozieren:
Verbindung zum Server aufbauen und HTTP Kommandos absetzen.

Code: Alles auswählen

telnet example.com 80

Dann mit dem Server sprechen, dazu drei Zeilen Text absenden:

Code: Alles auswählen

GET / HTTP/1.1
HOST: example.com

Die zusätzliche Leerzeile ist wichtig, damit bekommt die Gegenseite mit, dass wir fertig gefragt haben.
Als Antwort gibts sowas wie: HTTP/1.1 200 OK und den Inhalt der Webseite.
Wenn Du jetzt statt GET einfach mal POST versuchst, gibts erstmal "HTTP/1.1 411 Length Required" zurück. Liegt daran, dass der Standard sagt, dass man bei dieser Methode die Länge der Daten mitliefern muss. Kein Problem, schicken wir die eben auch noch mit:

Code: Alles auswählen

POST / HTTP/1.1
HOST: example.com
Content-Length:0

Leerzeile nicht vergessen. Und schon gibt es das erwartete "HTTP/1.1 200 OK" sowie den Rest.