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";