dedlfix: Include (php Seiten Inkludieren als zusätzliches script)

Beitrag lesen

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