nicht angemeldet
Formulardaten per E-Mail senden
Hallo,ich habe folgendes Formular in meine Seite eingebunden:
<form action="????" method="post">
<div><input class="input_txt2" value="Name" name="Name2" type="text" /></div><div style="height:5px"></div>
<div><input class="input_txt2" value="E-mail" name="Name" type="text" /></div><div style="height:5px"></div>
<div><input class="input_txt2" value="Subject" name="Name" type="text" /></div><div style="height:5px"></div>
<div><textarea class="text_area2" cols="32" rows="3" name="Message">Nachricht</textarea></div><div style="height:4px"></div>
<div><input class="submit2" name="Submit2" type="submit" value="Submit" />
<input class="submit2" name="Submit2" type="submit" value="Reset" />
</div>
</form>
Bei form action habe ich jetzt noch Fragezeichen. Ich möchte das die eingegebenen Daten der Besucher über ein Php-Script verarbeitet und an meine E-Mail Adresse geschickt werden.Kann mir da einer Tipps geben? Meine Versuche liefen darauf hin,dass sich nach dem Klick auf Submit das PHP Scribt in einem neuen Fenster geöffnet hat und man den Quellcode sehen konnte.
MfG
-
Hallo Schimalostra,
ist schon etwas länger her, dass ich mich mit PHP beschäftigt habe, aber ich versuche dir trotzdem schonmal zu helfen, bevor sich die Experten zu Wort melden:
1. Sende die Formulareingaben an eine PHP, wo du sie prüfst (zu lang, fehlende Infos, zu kurz, unerwünschte Zeichen, böse Wörter oder ähnliches) und dann
2. Entweder eine Fehlermeldung ausgibst oder die Formulardaten mit mail()* weiterleitest.FG
Zwerg Alex* hier auch noch eine - wie ich finde - schöne Erklärung dazu
-
Hallo Schimalostra,
ist schon etwas länger her, dass ich mich mit PHP beschäftigt habe, aber ich versuche dir trotzdem schonmal zu helfen, bevor sich die Experten zu Wort melden:
- Sende die Formulareingaben an eine PHP, wo du sie prüfst (zu lang, fehlende Infos, zu kurz, unerwünschte Zeichen, böse Wörter oder ähnliches) und dann
Grundsaetzlich muss JEDE Usewreingabe ueberprueft werden. Aber nicht unbedingt auf Laenge oder boese Woerter, sondern auf Sicherheitsluecken! Schnell hat man sich einen Spambot gebaut.
--
Vergesst Chuck Norris.
Sponge Bob kann unter Wasser grillen!-
Hi!
Grundsaetzlich muss JEDE Usewreingabe ueberprueft werden. Aber nicht unbedingt auf Laenge oder boese Woerter, sondern auf Sicherheitsluecken!
Nö. Worauf willst du sie denn prüfen? Welche Dinge sind denn bei der Eingabe beachtenswert - abgesehen von Transportverpackungen? Wenn man etwas grundsätzlich machen will, dann sollte man _alle_ Daten, nicht nur die unmittelbaren Benutzereingaben, bei der Ausgabe dem Ausgabemedium (inklusive Speichermedien) gerecht behandeln. Bei der Eingabe steht nicht in jedem Fall bereits fest, welches Ausgabemedium die Daten nehmen werden. Es ist nicht sinnvoll, bei der Eingabeverarbeitung bereits an das Ausgabemedium zu denken, denn die dafür eingefügten Maskierzeichen haben nur das Potential einen beim fachlichen Verarbeiten zu behindern. Einen Nutzen entfalten sie zu dem Zeitpunkt nicht.
Wenn du dir einen Haushaltsgegenstand zulegst, wirst du ihn üblicherweise, zu Hause angekommen, aus der Verpackung nehmen. Du wirst ihn sicher auf Funktionalität prüfen. Nutzen wirst du ihn in meist seiner "Rohform". Erst wenn du Bedarf hast, ihn irgendwohin mitzunehmen, wirst du dir Gedanken über eine angemessene Verpackung machen. Bei der Wahl der Transportverpackung wirst du nicht unterscheiden, ob ein Ding kürzlich erworben, ob es vom Speicher geholt oder ob es selbst hergestellt wurde. Ausschlaggebend ist allein, dass der Gegenstand in seiner Verpackung bestmöglich zur Transportform passt. Und auf diese Weise sollten auch Daten behandelt werden.
Lo!
-
Moin!
Grad seh ich nicht, wo der essentielle Unterschied von: "Jede Usereinagbe sollte geprueft werden" zu "pruefe Daten, wenn Du was damit machst" ist. Dass man Daten mit denen nicht passiert auch nicht pruefen braucht duerfte klar sein? Reden wir aneinander vorbei? Ich sage, du sollst pruefen. Du, wann und wie. Widerspricht sich doch nicht.
--
Vergesst Chuck Norris.
Sponge Bob kann unter Wasser grillen!-
Hi!
Grad seh ich nicht, wo der essentielle Unterschied von: "Jede Usereinagbe sollte geprueft werden" zu "pruefe Daten, wenn Du was damit machst" ist. Dass man Daten mit denen nicht passiert auch nicht pruefen braucht duerfte klar sein? Reden wir aneinander vorbei? Ich sage, du sollst pruefen. Du, wann und wie. Widerspricht sich doch nicht.
Der allgemeine Tenor lautet - und so auch deine Aussage - "prüfe alle Eingabedaten, das ist wichtig für die Sicherheit". Stellt sich die Frage: worauf prüfen und welche Sicherheit? Bei der Eingabe steht doch noch gar nicht fest, welches Ausgabemedium angesprochen wird. Also was soll man denn da prüfen - außer auf fachlichen Inhalt? Aus Sicherheitssicht ist Prüfen auch gar nicht notwendig. Stattdessen muss beim Ausgeben eine Behandlung gemäß Kontext stattfinden. Und das nicht nur für die Eingabedaten.
"Der allgemeine Tenor" lässt sich nur bei ganz einfachen Abläufen berücksichtigen, wenn die Daten geradeaus durchlaufen. Ansonsten fordert er etwas, das im Prinzip nicht zu realisieren ist, und lässt wichtige Sicherheitsaspekte weg.
Deswegen ist meine Aussage, dass man Eingabedaten nur aus fachlicher Sicht prüfen muss, wenn das notwendig ist. Die Sicherheit muss bei der Ausgabe beachtet werden.
(Diese Aussage gilt für Systeme, die sich nicht mit Puffergrößen rumschlagen müssen (z.B. PHP). Für Systeme, die ihre Puffer selbst verwalten (z.B. C), muss zumindest die Größe der Eingabedaten berücksichtigt werden, damit es keinen Pufferüberlauf gibt.)
Lo!
-
Hi!
Der allgemeine Tenor lautet - und so auch deine Aussage - "prüfe alle Eingabedaten, das ist wichtig für die Sicherheit". Stellt sich die Frage: worauf prüfen und welche Sicherheit? Bei der Eingabe steht doch noch gar nicht fest, welches Ausgabemedium angesprochen wird. Also was soll man denn da prüfen - außer auf fachlichen Inhalt? Aus Sicherheitssicht ist Prüfen auch gar nicht notwendig. Stattdessen muss beim Ausgeben eine Behandlung gemäß Kontext stattfinden. Und das nicht nur für die Eingabedaten.
Mal ein konkretes Beispiel: In ein Eingabefeld darf der Anwender einen beliebigen Text eingeben. Dafür wüsste ich grad keine sinnvolle Eingabedatenprüfung aus Sicherheitssicht. Bestimmte Zeichen zu entfernen ist nicht notwendig. Die Ausgabebehandlung kümmert sich um deren Entschärfung - und das ist in dem Sinne keine Prüfung.
Lo!
-
Moin!
Stellen wir uns folgendes Szenario vor:
User gibt seinen Namen ein: "Robert'); DROP TABLE Students;"
Ich hab also nur nen String. Ich kann den auf dem Monitor ausgeben, in eine Datenbank schreiben oder mailen...
Ungeprüft ist der erstmal nur kritisch in der zweiten Situation. Es ist aber völlig egal, was ich wann damit mache: Es bleibt eine Usereingabe. Wir behandeln mit diesem String also immer eine Usereingabe. Nehmen wir also den Fall, daß ich mit diesem Namen einen Datenbankquery erstelle: Wenn ich das Teil einfach so übernehme, habe ich ein Problem. Also muss ich das Teil entschärfen, wie Du es so schön nennst. Wie mache ich das? Ich prüfe es auf Gefahrenpotential und behandle den String.
Egal wie Du es nennst. Ich muss eine Usereingabe pruefen. Ich weiß nicht, ob Du hier nur extrem penibel bist und beim stumpfen escapen von z.B. allen ' keinerlei Pruefung siehst.
Ich komm immer noch nicht drauf, was Dein Problem ist.--
Vergesst Chuck Norris.
Sponge Bob kann unter Wasser grillen!-
Hi!
User gibt seinen Namen ein: "Robert'); DROP TABLE Students;"
Ich hab also nur nen String. Ich kann den auf dem Monitor ausgeben, in eine Datenbank schreiben oder mailen...
Ungeprüft ist der erstmal nur kritisch in der zweiten Situation. Es ist aber völlig egal, was ich wann damit mache: Es bleibt eine Usereingabe.Nö, bleibt es nicht, weil ich die Eingabe zusammen mit anderen Daten in eine Datei schreibe. Wenn ich die Datei lese, habe ich keine Usereingabe mehr, sondern Daten aus einer Datei. Die mixe ich munter und froh mit Daten aus anderen Quellen zusammen. Dass ein Teil, der nicht mal mehr zusammenhängen muss, mal eine Usereingabe war, kann man nun nicht mehr eindeutig sehen. Trotzdem können diese Daten Zeichene enthalten, die eine Sonderbedeutung in bestimmten Ausgabemedien haben. Und es sind sogar noch welche hinzugekommen, die nicht durch eine Eingabedatenprüfung (worauf auch immer) gegangen sind. Denn irgendwann nun - die Usereingabe ist mittlerweile völlig in Vergessenheit geraten - will ich eine Ausgabe vornehmen. Es interessiert nun nicht mehr, dass das eine Usereingabe war, sondern nur die aktuellen Zeichen in den Daten.
Wir behandeln mit diesem String also immer eine Usereingabe. Nehmen wir also den Fall, daß ich mit diesem Namen einen Datenbankquery erstelle: Wenn ich das Teil einfach so übernehme, habe ich ein Problem. Also muss ich das Teil entschärfen, wie Du es so schön nennst. Wie mache ich das? Ich prüfe es auf Gefahrenpotential und behandle den String.
Eine Methode ist, jedes einzelne Zeichen auf seine Sonderbedeutung zu prüfen und es gegebenenfalls zu maskieren. Doch das macht man nicht per Hand, dafür gibt es Funktionen. Die betrachte ich als Blackbox, und ob die was prüfen, etwas berechnen, eine Kodierung (z.B. Base64) oder eine Typumwandlung durchführen, ist mir egal. Sie geben einen kontextgerecht behandelten Wert zurück. Die Behandlung für das Ausgabemedium können also auch ganz andere Vorgänge als eine Prüfung sein.
Egal wie Du es nennst. Ich muss eine Usereingabe pruefen. Ich weiß nicht, ob Du hier nur extrem penibel bist und beim stumpfen escapen von z.B. allen ' keinerlei Pruefung siehst.
Ich komm immer noch nicht drauf, was Dein Problem ist.Du kommst nicht auf die sichere Seite, wenn du lediglich eine Eingabedatenprüfung vornimmst. Wichtig ist eine Ausgabedatenbehandlung, und die muss keine Prüfung sein. Deshalb möchte ich nicht mehr "prüfe unbedingt deine Eingabedaten" lesen, sondern "behandle unbedingt deine Ausgabedaten".
Lo!
-
-
-
-
-
-
-
Hi!
Hallo,ich habe folgendes Formular in meine Seite eingebunden:
Bei form action habe ich jetzt noch Fragezeichen. Ich möchte das die eingegebenen Daten der Besucher über ein Php-Script verarbeitet und an meine E-Mail Adresse geschickt werden.Das heißt also, dass du ein auswertendes Script haben musst. Weiterhin heißt das, dass es ausgeführt werden muss. Es muss, da wo das Script liegt (auf dem Server), etwas vorhanden und konfiguriert sein, dass dafür sorgt, dass dieses Script arbeiten kann.
Meine Versuche liefen darauf hin,dass sich nach dem Klick auf Submit das PHP Scribt in einem neuen Fenster geöffnet hat und man den Quellcode sehen konnte.
Und das sieht sehr danach aus, als ob PHP gar nicht zur Verfügung steht. Das solltest du zuerst einmal erkunden. Wenn es doch verfügbar ist, wäre die Frage, was noch getan werden muss, um PHP-Scripte ausführen zu können. Üblicherweise muss man nichts weiter machen, als den Dateinamen auf .php enden zu lassen. Aber dafür ist dein Hoster/Admin der beste Ansprechpartner.
Lo!