Include (php Seiten Inkludieren als zusätzliches script)

[Berlinn]

Hallo Forum,

habe eine frage zu Include von PHP.
Ich benutze ein Affenformular mit $_POST übergaben und möchte jetzt das Prüfungsscript ein wenig erweitern über eine zusätzliche inkludierte PHP Seite.

Beispiel formular.php:

<?php
if (count($_GET)>0)
  {
   echo ‘SPAM VERDACHT’;
    exit();
  }
?>
<?php
if (isset($_POST['absenden'])) {

include('formularscript.php');

etc……

Beispiel Inkludierte Seite formularscript.php:

<?php
if (count($_GET)>0)
  {
   echo ‘SPAM VERDACHT’;
    exit();
  }
?>
<?php
   if (isset($_POST['wasauchimmer'][1]))
     {
      $_POST['wasauchimmer'][1] = trim($_POST['wasauchimmer'][1]);
     }
     else
     {
      echo ‘SPAM VERDACHT’;
       exit();
     }
   if ($_POST['wasauchimmer'][1] !== "")
     {
      echo ‘SPAM VERDACHT’;
       exit();
     }

etc……

Da hier alles über POST übermittelt wird, stehen auch keine Informationen in der Browserleiste zu Verfügung! Auch das übermitteln evtl. Manipulationen über die Leiste wird unterbunden. Dennoch habe ich einen faden Beigeschmack der Sicherheit wegen und wollte euch fragen welche Möglichkeiten man noch hat die Inkludierung sicherer zu machen!

Danke für eure Antwort!

Mit freundlichen Grüßen,

Berlinn

[dedlfix]

echo $begrüßung;

Da hier alles über POST übermittelt wird, stehen auch keine Informationen in der Browserleiste zu Verfügung! Auch das übermitteln evtl. Manipulationen über die Leiste wird unterbunden. Dennoch habe ich einen faden Beigeschmack der Sicherheit wegen und wollte euch fragen welche Möglichkeiten man noch hat die Inkludierung sicherer zu machen!

Ich weiß nicht, an welcher Stelle du konkret welche Sicherheitsbedenken hast und was dir an einem include einer lokalen, genau benannten Datei unsicher vorkommt.

Ein include sorgt dafür, dass der inkludierte Code in den Kontext des include-Aufrufs geladen und eben dort ausgeführt wird. Bedenklich ist, wenn der Dateiname direkt aus einer Nutzereingabe gebildet wird oder eine externe Quelle inkludiert wird, die kompromittiert sein könnte.

echo "$verabschiedung $name";

[Berlinn]

Hallo dedlfix,

danke für die schnelle antwort!

Mit freundlichen Grüßen,

Berlinn

[grauerkoala]

Hallo dedlfix,

danke für die schnelle antwort!

Mit freundlichen Grüßen,

Berlinn

übrigens sind die daten nicht wirklich unsichtbar, sie erscheinen nur nicht in der adressleiste. für firefox gibt es eine ganze reihe an addons, mit denen man alle daten, die der browser an eine website übermittelt, also auch post- und get-daten, einsehen kann.

[Berlinn]

übrigens sind die daten nicht wirklich unsichtbar, sie erscheinen nur nicht in der adressleiste. für firefox gibt es eine ganze reihe an addons, mit denen man alle daten, die der browser an eine website übermittelt, also auch post- und get-daten, einsehen kann.

»»

Hallo grauerkoala,

auch an Dir ein danke für die antwort!

Mir ist klar das eingegebene Daten die per POST (z.B. Value) gesendet werden sichtbar sind! Hierfür braucht man keine speziellen Addons um diese zu sehen. Ein blick in den Quelltext reicht aus! Es ging mir in erster Linie nur darum Manipulationen am Include Script selbst zu Unterbinden. Mit GET könnte man fremde Scripte einschleusen wenn auf dem Server allow_url_fopen aktiviert ist! Dieses wird durch if (count($_GET)>0) unterbunden.

Auch kann man über die Eingabefelder die per POST gesendet werden scripte einschleusen wenn diese nicht auf bösen Code geprüft werden! Prüfungsmöglichkeiten hätte man ja genug wie z.B. strip_tags, nach Wörter wie <?php suchen etc. pp.!

Leider bin ich jetzt noch unsicherer geworden und ich bitte euch mein überarbeitetes script noch mal anzuschauen:

Beispiel formular.php:

<?php
if (count($_GET)>0)
  {
   echo ‘SPAM VERDACHT’;
    exit();
  }
?>
<?php
if (isset($_POST['absenden'])) {

$kontrolle = 'formularscript.php';

if (file_exists($kontrolle))
     {
      include('formularscript.php');
     }
     else
     {
      echo ’Durch einen unerwarteten Fehler kann das Formular nicht bearbeitet werden!<br><br>’;
      echo ’Bitte versuchen Sie es morgen erneut!’;
       exit();
     }

etc……

Beispiel Inkludierte Seite formularscript.php:

<?php
if (count($_GET)>0)
  {
   echo ‘SPAM VERDACHT’;
    exit();
  }
?>
<?php
   if (isset($_POST['wasauchimmer'][1]))
     {
      $_POST['wasauchimmer'][1] = trim(strip_tags($_POST['wasauchimmer'][1]));
     }
     else
     {
      echo ‘SPAM VERDACHT’;
       exit();
     }
   if ($_POST['wasauchimmer'][1] !== "")
     {
      echo ‘SPAM VERDACHT’;
       exit();
     }

etc……

Könnte man dieses so lassen oder ist das ein absolutes Sicherheitsrisiko?
Danke für eure Hinweise!!!

Mit freundlichen Grüßen,

Berlinn

[dedlfix]

echo $begrüßung;

Mir ist klar das eingegebene Daten die per POST (z.B. Value) gesendet werden sichtbar sind! Hierfür braucht man keine speziellen Addons um diese zu sehen. Ein blick in den Quelltext reicht aus!

Er meinte nicht das Sehen des HTML-Quelltextes sondern eher die Manipulierbarkeit vor dem Absenden. Nimm als Beispiel ein Hidden-Feld. Das kann man im Normalfall nicht manipulieren, aber mit entsprechenden Browser-Addons kann man dessen Wert vor dem Absenden relativ bequem ändern ohne dass man sich den Quelltext lokal kopieren und dort Änderungen vornehmen muss.

Es ging mir in erster Linie nur darum Manipulationen am Include Script selbst zu Unterbinden. Mit GET könnte man fremde Scripte einschleusen wenn auf dem Server allow_url_fopen aktiviert ist! Dieses wird durch if (count($_GET)>0) unterbunden.

Ein include hat mit GET- oder POST-Parametern nichts zu tun, wenn du nicht explizit diese Werte in den include-Aufruf bringst. Ein Prüfen auf GET/POST ist dahingehend nicht sinnvoll.

include $_GET['seite']; // Das wäre eine höchst gefährliche Angelegenheit.

include 'seite.php'; // Das hingegen ist harmlos.

Auch kann man über die Eingabefelder die per POST gesendet werden scripte einschleusen wenn diese nicht auf bösen Code geprüft werden! Prüfungsmöglichkeiten hätte man ja genug wie z.B. strip_tags, nach Wörter wie <?php suchen etc. pp.!

Wichtig ist im Prinzip nur, Werte für den jeweiligen Ausgabekontext aufzubereiten. PHP- oder HTML-Code ist völlig harmlos, wenn du ihn beim Ausgeben in einen HTML-Kontext HTML-gerecht aufbereitest, sprich: die <http://de.selfhtml.org/html/allgemein/zeichen.htm#html_eigene@title=HTML-eigenen Zeichen> maskiert. Dann wird der HTML-Code zwar angezeigt, aber nicht mehr ausgeführt. Wenn du ihn mit strip_tags() und Ähnlichem filterst hast du trotzdem die Notwendigkeit, unsinnige Einträge in Gästebüchern und dergleichen zu entfernen, denn sie stören ob mit oder ohne angezeigten Code. Du sparst dir durch strip_tags() und Co. nichts an Administrationsaufwand. Andererseits kannst du auch Kollateralschaden anrichten, wenn du Code, der wirklich angezeigt werden soll, oder Code-ähnliche Texte wegfilterst.

Leider bin ich jetzt noch unsicherer geworden und ich bitte euch mein überarbeitetes script noch mal anzuschauen:
if (count($_GET)>0)
  {
   echo ‘SPAM VERDACHT’;
    exit();
  }

Das kannst du machen, du kannst es aber auch weglassen. Wenn du keine GET-Parameter erwartest, lass einfach das $_GET-Array unbeachtet liegen. Prüfen und Abbrechen brngt dir k(aum)einen Vorteil.

if (isset($_POST['absenden'])) {

Wenn man ein Formular mit Enter absendet wird vom IE der Submitbutton als nicht aktiviert betrachtet und damit auch nicht abgesendet. Der FF hingegen simuliert fälschlicherweise (gemäß meiner Interpretation des Standards) eine Submit-Betätigung. Andere Browser verhalten sich vielleicht wieder anders.

Das Absenden eines Formulars würde ich nicht an einem Submitbutton kontrollieren. Solche würde ich nur dann auswerten, wenn eine explizite Aktion mit einem bestimmten Submitbutton ausgelöst werden soll.

$kontrolle = 'formularscript.php';
   if (file_exists($kontrolle))
     {
      include('formularscript.php');
     }

Wenn jemand in der Lage war, dir Dateien zu löschen, hast du ein viel gravierenderes Problem. Der Angreifer ist dann vermutlich nicht auf das Vorhandensein einer Inklude-Datei angewiesen. Lass die Prüfung weg. Wenn du einen Abbruch bei nicht vorhandener Inklude-Datei haben möchtest, nimm require.

echo ’Durch einen unerwarteten Fehler kann das Formular nicht bearbeitet werden!<br><br>’;
      echo ’Bitte versuchen Sie es morgen erneut!’;
       exit();

Aha, und wer würde im Falle eines Falles informiert, dass er bis morgen am Webauftritt etwas auszubessern hat?

echo ‘SPAM VERDACHT’;

Dass weder diese noch die eins weiter oben verwendeten Anführungszeichen die richtigen für Stringwerte sind, weißt du?

Könnte man dieses so lassen oder ist das ein absolutes Sicherheitsrisiko?

Wie gesagt, es steigert weder die Sicherheit noch verringert es sie. Du solltest dein Augenmerk viel mehr auf eine kontextgerechte Behandlung legen. Die Nichtbeachtung von kontextgerechter Behandlung ist eine der am häufigsten auftauchenden Sicherheitslücken.

echo "$verabschiedung $name";

[Berlinn]

Hallo Der Martin,
Hallo dedlfix,

an euch ein großes danke für die Informationen!
Wenn ich nicht mit den richtigen fachlichen Wörtern antworte bitte ich dieses zu entschuldigen. Ich bin noch im Lernprozess!

Von dedlfix: Er meinte nicht das Sehen des HTML-Quelltextes sondern eher die Manipulierbarkeit vor dem Absenden. Nimm als Beispiel ein Hidden-Feld. Das kann man im Normalfall nicht manipulieren, aber mit entsprechenden Browser-Addons kann man dessen Wert vor dem Absenden relativ bequem ändern ohne dass man sich den Quelltext lokal kopieren und dort Änderungen vornehmen muss.

Da es sich hier um ein Kontaktformular (Affenformular) handelt sind die vom User eingegebenen Daten ja nicht vorausschaubar. Demnach werden diese bevor sie in den Mailbody übertragen werden ja auch überprüft ob bestimmte Kriterien erfüllt werden bzw. böse eingaben gemacht wurden. Bei festen übertragenen Werten (Bsp. Hidden) sollte man auch Gegenprüfen ob die Werte wirklich vorhanden sind, sollte das nicht der fall sein heißt es für das Script abrechen.

Von dedlfix: Ein include hat mit GET- oder POST-Parametern nichts zu tun, wenn du nicht explizit diese Werte in den include-Aufruf bringst. Ein Prüfen auf GET/POST ist dahingehend nicht sinnvoll. include $_GET['seite']; // Das wäre eine höchst gefährliche Angelegenheit. include 'seite.php'; // Das hingegen ist harmlos.

Genau das wollte ich wissen! Danke!!!

Von dedlfix: Wenn man ein Formular mit Enter absendet wird vom IE der Submitbutton als nicht aktiviert betrachtet und damit auch nicht abgesendet. Der FF hingegen simuliert fälschlicherweise (gemäß meiner Interpretation des Standards) eine Submit-Betätigung. Andere Browser verhalten sich vielleicht wieder anders. Das Absenden eines Formulars würde ich nicht an einem Submitbutton kontrollieren. Solche würde ich nur dann auswerten, wenn eine explizite Aktion mit einem bestimmten Submitbutton ausgelöst werden soll.

Wenn ich im IE ein Formular mit Enter (Tastatur) bestätige wird das Formular ohne Probleme abgesendet. Beim FF, Netscape oder Opera ist das nur möglich wenn ich vorher in einem Einzeiligen Textfeld den Eingabecursor am blinken habe! Vielleicht verstehe ich hier etwas falsch, bitte nehme dazu kurz Stellung!

Die Aktion die durch das absenden ausgelöst werden soll ist natürlich als erstes die Prüfung der Benutzereingaben, erst wenn keine Fehlerausgabe mehr ausgegeben wird, werden die Benutzereingaben in den Mailbody übertragen und versendet.

Von dedlfix: Wenn jemand in der Lage war, dir Dateien zu löschen, hast du ein viel gravierenderes Problem. Der Angreifer ist dann vermutlich nicht auf das Vorhandensein einer Inklude-Datei angewiesen. Lass die Prüfung weg. Wenn du einen Abbruch bei nicht vorhandener Inklude-Datei haben möchtest, nimm require.

Da teilen sich die Meinungen, es könnte ja auch sein das man selbst vergessen hat die Datei Hochzuladen oder diese wurde nicht übertragen. Außerdem zeigt require eine schöne Warnung sowie einen Fatal Error mit Angabe der betroffenen Include Datei an. Mit dieser Meldung könnte der Interessent (kein Programmierer) der das Formular ausfüllt nichts mit anfangen. Bei file_exists und bei nicht Vorhandensein der Datei hätte man wenigsten die Möglichkeit dem User etwas mitzuteilen und abgebrochen wird das Script dann durch Exit.

Von dedlfix: Aha, und wer würde im Falle eines Falles informiert, dass er bis morgen am Webauftritt etwas auszubessern hat?

Von Der Martin: Und morgen klappt es dann besser? ;-)

:-) Das war nur ein Beispiel wie es aussehen könnte. Man kann ja dem User die Möglichkeit bieten auf einen Button zu drücken der dann eine Nachricht an mich weiterleitet das da etwas nicht stimmt! Automatisieren könnte man das bestimmt auch ohne dass der User irgendetwas drücken muss!

Von dedlfix: Dass weder diese noch die eins weiter oben verwendeten Anführungszeichen die richtigen für Stringwerte sind, weißt du?

Von Der Martin: Die Zierschnörkel anstatt der Anführungszeichen hat dedlfix ja schon kritisiert; mir sind sie auch schon in deinem ersten Posting aufgefallen.

Sorry, habe einen teil von dem script in Word und dann hier rein geworfen und da ist wohl was bei schief gelaufen: echo "So wäre es richtig!"; und das steht für eine vordefinierte Variable $hallo = 'Hallo, das ist ein Test!';

Von dedlfix: Wie gesagt, es steigert weder die Sicherheit noch verringert es sie. Du solltest dein Augenmerk viel mehr auf eine kontextgerechte Behandlung legen. Die Nichtbeachtung von kontextgerechter Behandlung ist eine der am häufigsten auftauchenden Sicherheitslücken.

Dann wäre hier das Zauberwort htmlspecialchars zuzüglich zur normalen Prüfung, hoffe dass ich es richtig verstanden habe!

Von Der Martin: nicht ganz; nach dem Blick in den Quelltext weiß man immer noch nicht, *welche* name-value-Paare tatsächlich gesendet werden (Stichwort: successful controls). Aber es gibt viele Möglichkeiten, die tatsächlich gesendeten und empfangenen Daten einzusehen. Die größte Keule wäre vermutlich Wireshark oder ein protokollierender Proxy, die einfachste Methode IMO die LiveHTTP-Extension für den Firefox.

Ich finde nur als Addon denn Live HTTP Headers unter FF und nehme an das Du das meinst. Gibt es den Möglichkeiten wie man es Unterbinden kann Sniffer Programme eine Einsicht in die Daten zu gewähren??? Oder anders, würde ein SSL die Sache Entschärfen???

Von Der Martin: Was veranlasst dich, den PHP-Block zu beenden und sofort wieder aufzumachen?

Das hätte ich noch geändert, ich bin halt noch am lernen und probieren und wollte einige Sachen erst einmal prüfen bevor das ganze Script eine Einheit bildet.

Ich bedanke mich bei euch das Ihr soviel Geduld und Zeit Opfert einem etwas beizubringen und verbleibe mit freundlichen Grüßen,

Berlinn

[dedlfix]

echo $begrüßung;

Da es sich hier um ein Kontaktformular (Affenformular) handelt sind die vom User eingegebenen Daten ja nicht vorausschaubar. Demnach werden diese bevor sie in den Mailbody übertragen werden ja auch überprüft ob bestimmte Kriterien erfüllt werden bzw. böse eingaben gemacht wurden.

Wenn du das für erforderlich hältst, kannst du die Eingabedaten prüfen. Das sollte vor allem eine fachliche Prüfung sein. Das Entfernen unerwünschter Werte sehe ich aber nur mehr oder weniger als zusätzliche Hilfe an, auf die man sich nicht verlassen darf. Denn man kann ja auch mal was übersehen und das darf auch keinen Schaden anrichten. Wichtiger als die Eingabedatenprüfung ist die Beachtung des Ausgabekontexts. Und das darf auch bei Eingabedatenprüfung auf keinen Fall unterlassen werden. Solange ein Wert im Ausgabekontext nicht fehlinterpretiert wird, ist er harmlos, egal wie unerwünscht er ist.

Du willst etwas in einen Mailbody einfügen. Wenn der Plaintext ist und auch als solcher ausgezeichnet ist (Content-Type: text/plain) dann ist da nichts weiter zu beachten, denn Plaintext wird nicht interpretiert. Soll eine HTML-Mail gesendet werden, ist das ein HTML-Kontext und mindestens die HTML-eigenen Zeichen zu maskieren. Dieses Prinzip bezieht sich auch auf mehrteilige Mails (zum Beispiel ein HTML- und ein Text-Teil).

Bei festen übertragenen Werten (Bsp. Hidden) sollte man auch Gegenprüfen ob die Werte wirklich vorhanden sind, sollte das nicht der fall sein heißt es für das Script abrechen.

Hidden-Werte sind nur scheinbar fest. Sie unterliegen wie alle Daten die vom Client gesendet werden, einer möglichen Manipulation. Wenn du zwischen zwei Aufrufen Daten festhalten willst, nimm eine Session. Bei der liegen die Daten vom Client nicht beeinflussbar auf dem Server.

Wenn ich im IE ein Formular mit Enter (Tastatur) bestätige wird das Formular ohne Probleme abgesendet. Beim FF, Netscape oder Opera ist das nur möglich wenn ich vorher in einem Einzeiligen Textfeld den Eingabecursor am blinken habe! Vielleicht verstehe ich hier etwas falsch, bitte nehme dazu kurz Stellung!

Ich hab das grad nochmal getestet. IE6 und FF2 verhalten sich im Prinzipg gleich, was die Bedienung angeht. Hinzu kommt beim IE6, dass er das erste Formular der Seite absendet, wenn kein Formularelement fokussiert ist und man Enter drückt. In dem Fall simuliert der IE sogar den Button-Klick und sendet das name-value-Pärchen des Submit-Buttons mit. Ist man direkt in einem Formularelement und entert, kommt das name-value-Pärchen des Submit-Buttons nicht mit.

Was ich mit dem Teil der Antowrt sagen wollte: Verlass dich nicht darauf, dass das name-value-Pärchen des Submit-Buttons in jedem Fall mitgesendet wird. Der Anwender könnte sich veralbert vorkommen, wenn er das Formular absendet und du so reagierst, als ob er das nicht gemacht hat. Was du immer kontrollieren kannst ist, ob das $_POST-Array nicht leer ist (!empty($_POST)) oder ob $_SERVER['REQUEST_METHOD'] auf POST steht. In beiden Fällen gab es eine POST-Request, mithin hat jemand ein Formular abgesendet. Ein weiterer Workaround wäre

<input type="hidden" name="submit" value="Absenden">
  <input type="submit" name="submit" value="Absenden">

Wenn kein Submit-Button gesendet wird hast du als Ersatz den Wert aus dem Hidden-Feld. Wird der Submit-Button mitgesendet, überschreibt der den Hidden-Wert im $_POST-Array. In beiden Fällen hast du nur einen Inhalt in $_POST['submit'].

Da teilen sich die Meinungen, es könnte ja auch sein das man selbst vergessen hat die Datei Hochzuladen oder diese wurde nicht übertragen.

Es liegt in deiner Verantwortung als Administrator des Webauftritts, dass du kontrollierst, dass alles noch wie gewünscht funktioniert, nachdem du eine Änderung vorgenommen hast. Das sind vermeidbare Fehler. Weniger Einfluss hast du, wenn das DBMS grad mal keine Lust hat. Diesen Fehler abzufangen, sehe ich als wichtiger an, als sich gegen eigenes (kontrollierbares) Fehlverhalten abzusichern.

Außerdem zeigt require eine schöne Warnung sowie einen Fatal Error mit Angabe der betroffenen Include Datei an. Mit dieser Meldung könnte der Interessent (kein Programmierer) der das Formular ausfüllt nichts mit anfangen. Bei file_exists und bei nicht Vorhandensein der Datei hätte man wenigsten die Möglichkeit dem User etwas mitzuteilen und abgebrochen wird das Script dann durch Exit.

Hauptsache ist, dass du ihm nicht indirekt die Schuld gibst, indem du ihn mit technischen Details zum Fehler behelligst. Als Alternative bietet sich an, einen benutzerdefinierten Errorhandler zu erstellen (siehe Error Handling and Logging). Der springt immer an, wenn ein Fehler auftritt (außer bei fatalen) und kann beispielsweise den Admin per Mail benachrichtigen und dem Anwender was erzählen.

Nachteilig bei jeder Art von Abbruch ist, dass dabei eventuell Seitenfragmente entstehen, was zumindest für den Benutzer unschön aussieht. Trennt man hingegen den Ablauf nach dem EVA-Prinzip, kann man, wenn ein Fehler im E- oder V-Teil auftritt, von der Fehlerabfangfunktion zumindest eine komplette Seite mit eingebetteter Meldung ausgeben lassen.

» Von dedlfix: Wie gesagt, es steigert weder die Sicherheit noch verringert es sie. Du solltest dein Augenmerk viel mehr auf eine kontextgerechte Behandlung legen. Die Nichtbeachtung von kontextgerechter Behandlung ist eine der am häufigsten auftauchenden Sicherheitslücken.

Dann wäre hier das Zauberwort htmlspecialchars zuzüglich zur normalen Prüfung, hoffe dass ich es richtig verstanden habe!

Ja, wobei ich die Prioritäten andersherum sehe: kontextgerechte Behandlung als Muss und Prüfungen als Zusatz.

Gibt es den Möglichkeiten wie man es Unterbinden kann Sniffer Programme eine Einsicht in die Daten zu gewähren??? Oder anders, würde ein SSL die Sache Entschärfen???

Wenn der Sniffer "unterwegs" mitliest, kann ihm das durch Verschlüsslung verhindert oder erschwert werden. Plugins im Browser können die Daten vor der Verschlüsslung sehen.
(P.S. Ein Fragezeichen pro Frage reicht auch.)

echo "$verabschiedung $name";

[Berlinn]

Hallo dedlfix,

vielen dank für deine ausführliche Stellungnahme!
Habe vieles noch nicht gewusst und jetzt dazugelernt.

Freundliche Grüße,

Berlinn

[Der Martin]

Hallo,

Mir ist klar das eingegebene Daten die per POST (z.B. Value) gesendet werden sichtbar sind! Hierfür braucht man keine speziellen Addons um diese zu sehen. Ein blick in den Quelltext reicht aus!

nicht ganz; nach dem Blick in den Quelltext weiß man immer noch nicht, *welche* name-value-Paare tatsächlich gesendet werden (Stichwort: successful controls). Aber es gibt viele Möglichkeiten, die tatsächlich gesendeten und empfangenen Daten einzusehen. Die größte Keule wäre vermutlich Wireshark oder ein protokollierender Proxy, die einfachste Methode IMO die LiveHTTP-Extension für den Firefox.

Es ging mir in erster Linie nur darum Manipulationen am Include Script selbst zu Unterbinden. Mit GET könnte man fremde Scripte einschleusen wenn auf dem Server allow_url_fopen aktiviert ist!

Nein. Versuche bitte *ganz genau* nachzuvollziehen, wie das deiner Meinung nach gehen sollte. Es geht nicht. Es geht nur dann, wenn du aus den GET-Parametern z.B. den Namen der include-Datei bildest. Das ginge aber dann mit POST ebensogut.

Auch kann man über die Eingabefelder die per POST gesendet werden scripte einschleusen wenn diese nicht auf bösen Code geprüft werden!

Auch hier: Nein. Es sei denn, du kommst auf die gefährliche Idee, Parameter mit eval() als Programmcode auszuführen. Nur die Tatsache, dass übergebene Parameter so aussehen wie PHP-Code, führt diesen Code noch lange nicht aus.

echo ‘SPAM VERDACHT’;

Die Zierschnörkel anstatt der Anführungszeichen hat dedlfix ja schon kritisiert; mir sind sie auch schon in deinem ersten Posting aufgefallen.
Auch über Sinn und Unsinn deiner weiteren Überprüfungen hat er schon einiges gesagt.

echo ’Durch einen unerwarteten Fehler kann das Formular nicht bearbeitet werden!<br><br>’;
      echo ’Bitte versuchen Sie es morgen erneut!’;

Und morgen klappt es dann besser? ;-)

?>
<?php

Was veranlasst dich, den PHP-Block zu beenden und sofort wieder aufzumachen?

Könnte man dieses so lassen oder ist das ein absolutes Sicherheitsrisiko?

Es ist vor allem viel Aufwand ohne irgendeinen Nutzen.

So long,
 Martin