Mein Self Formmailer, brauchbar oder Gemeingefährlich?

[Malcolm Beck´s]

hi,

hab mich heute Nacht endlich mal aufgerafft und mir ein Formmailer gebastelt, es gibt ja genug fertige Scripte aber alles irgendwie so ne sache für sich.
Naja, jetzt hab ich einen eigenen, nur kann ich nicht beurteilen, ob das ding sicher ist, könnte mal jemand drüber schauen ob es sicherheitslücken gibt?
Alles funktioniert, vorschau, absenden, Pflichtfelder, Affenformular.
Habs mal hochgeladen, http://start-navi.de/beispiele/form1.php

Und das Script sieht wie folgt aus, bissel viel, hoffe trotzdem das jemand mal drüberschaut.

<?php  
  
error_reporting(E_ALL);  
  
$strEmpfaenger = '***@***.de';  
$strFrom       = '"Formmailer" <***@***.de>';  
$strSubject    = 'Feedback';  
$strDelimiter  = ":\t";  
$strReturnhtml = 'http://start-navi.de/beispiele/form1.php?mail=ok';  
  
### Ende Konfiguration ###  
  
if(isset($_GET['abschicken']))  
{  
 $strMailtext = "";  
  
 while(list($strName,$value) = each($_GET))  
 {  
  if(is_array($value))  
  {  
   foreach($value as $value_array)  
   {  
    $strMailtext .= $strName.$strDelimiter.$value_array."\n";  
   }  
  }  
  else  
  {  
   $strMailtext .= $strName.$strDelimiter.$value."\n";  
  }  
 }  
  
 if(get_magic_quotes_gpc())  
 {  
  $strMailtext = stripslashes($strMailtext);  
 }  
  
 mail($strEmpfaenger, $strSubject, $strMailtext, "From: ".$strFrom)  
  or die("Die Mail konnte nicht versendet werden.");  
 header("Location: $strReturnhtml");  
 exit;  
}  
  
### Name #########  
 if ((isset($_GET['Name'])) AND (empty($_GET['Name']))) {  
  $err_Name = '<p style="color: #F00">Das Feld Name darf nicht Leer sein</p>';  
 }  
  else { $err_Name = ''; }  
  
 if (isset($_GET['Name'])) {  
  $name_value = htmlspecialchars($Name);  
 }  
  else { $name_value = ''; }  
#########################  
  
##### Nachname ###########  
 if (isset($_GET['Nachname'])) {  
  $nach_name_value = htmlspecialchars($Nachname);  
 }  
  else { $nach_name_value = ''; }  
#########################  
  
#### Textfeld #############  
 if ((isset($_GET['Nachricht'])) AND (empty($_GET['Nachricht']))) {  
  $err_Nachricht = '<p style="color: #F00">Das Feld Nachricht darf nicht Leer sein</p>';  
 }  
  else { $err_Nachricht = ''; }  
  
 if (isset($_GET['Nachricht'])) {  
  $text_value = htmlspecialchars($Nachricht);  
 }  
  else { $text_value = ''; }  
########################  
  
#### Select ##  
    if (isset($_GET['Browser'])) {  
 $array = array($_GET['Browser']);  
  
  foreach ($array as $wert) {  
   $mein_string = $wert;  
  }  
} else { $mein_string = ''; }  
#######################  
 echo '<p>** ist Pflichtfeld</p>';  
 echo $err_Name;  
 echo $err_Nachricht;  
 ?>

 <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="GET">  
  
Ihr Name: **  
<input type="text" name="Name" value="<?php echo $name_value; ?>" /> <br>  
  
Ihr Nachname:  
<input type="text" name="Nachname" value="<?php echo $nach_name_value; ?>" /> <br>  
  
  
Sie m&ouml;gen:  
<select name="Browser">  
<option value="Opera" <?php  
  
 if ($mein_string == 'Opera') {  
  echo 'selected';  
 } else { echo ''; }  
  
?>>Opera</option>  
<option value="Mozilla" <?php  
  
 if ($mein_string == 'Mozilla') {  
  echo 'selected';  
 } else { echo ''; }  
  
?>>Mozilla</option>  
</select>  
 <br>  
  
Nachricht: **  
<textarea name="Nachricht" rows="3" cols="20"><?php echo $text_value; ?></textarea>  
  
  <p><input type="submit" value="Vorschau" />  
<?php  
 if ((isset($_GET['Name'])) AND (!empty($_GET['Name'])) AND (isset($_GET['Nachricht'])) AND (!empty($_GET['Nachricht']))) {  
  echo '<input type="submit" name="abschicken" value="abschicken" /></p>';  
 } else { }  
?>  
        </form>

Es geht mir vor allem um Sicherheit, das das Script besser sein kann ist mir klar, besser kann ich´s leider nicht.

grüße

[gooxsy]

Hi Malcolm,

die Vorschau funktioniert nicht bei mir. Wenn ich das Formular vollständig ausfülle und auf VORSCHAU klicke, dann erscheint einfach nur der ABSENDE-Button, aber keine Vorschau. (Oder ist das gewollt???)

mfG

gooxsy

[Malcolm Beck´s]

hi,

die Vorschau funktioniert nicht bei mir. Wenn ich das Formular vollständig ausfülle und auf VORSCHAU klicke, dann erscheint einfach nur der ABSENDE-Button, aber keine Vorschau. (Oder ist das gewollt???)

Sorry, wollte das für das Forum hier nur aufs nötigste kürzen, hab ich jetzt korrigiert.

grüße

[gooxsy]

Hi Malcolm,

also um den PHP-Code zu beurteilen, fehlt mir noch die Kompetenz, aber mir ist aufgefallen, daß Du zur Formularverarbeitung GET angibst.

Abgesehen davon, daß GET sowieso Standard wäre und nicht extra angegeben werden müßte, solltest Du hier POST verwenden.

Siehe die entsprechende SELFHTML-Seite über die Formulardefinition:

Das W3-Konsortium empfiehlt, die Methode get dann zu wählen, wenn das auswertende Programm die Daten nur zur Ablaufsteuerung benötigt (z.B. für eine Suche oder zum Weiterblättern), während die Methode post für Fälle empfohlen wird, in denen die Daten über das auswertende Programm hinaus weiterverarbeitet werden (z.B. Speicherung in einer Datenbank oder Auslösung einer Bestellung).

mfG

gooxsy

[Malcolm Beck´s]

hi gooxsy,

also um den PHP-Code zu beurteilen, fehlt mir noch die Kompetenz, aber mir ist aufgefallen, daß Du zur Formularverarbeitung GET angibst.
Abgesehen davon, daß GET sowieso Standard wäre und nicht extra angegeben werden müßte, solltest Du hier POST verwenden.

Das hatte ich auch vor gehabt, da fehlt mir aber noch die kompetenz. :)
Das Script soll erstmal seinen Dienst tun, kommt Zeit, kommt POST.

grüße

[gooxsy]

Hi Malcolm,

Das hatte ich auch vor gehabt, da fehlt mir aber noch die kompetenz. :)
Das Script soll erstmal seinen Dienst tun, kommt Zeit, kommt POST.

ach, dazu brauchst Du gar keine große Kompetenz. Du änderst einfach das <form action="/beispiele/form1.php" method="GET"> in <form action="/beispiele/form1.php" method="POST"> um.

Und wenn es um die Auswertung geht, nimmst Du zB. statt echo"<p>Der eingegebene Name war: ".$_GET['name']."</p>\n"; einfach echo"<p>Der eingegebene Name war: ".$_POST['name']."</p>\n";.

mfG

gooxsy

[Malcolm Beck´s]

hi gooxsy,

ach, dazu brauchst Du gar keine große Kompetenz. Du änderst einfach das <form action="/beispiele/form1.php" method="GET"> in <form action="/beispiele/form1.php" method="POST"> um.
Und wenn es um die Auswertung geht, nimmst Du zB. statt echo"<p>Der eingegebene Name war: ".$_GET['name']."</p>\n"; einfach echo"<p>Der eingegebene Name war: ".$_POST['name']."</p>\n";.

Ich hätte schwören können das das nicht geht. :)
Ich hab bei meinen Tests heute Nacht wohl irgendwo was falsch gemacht, mit POST geht es auch, und sieht besser aus.

Danke für den hinweis.

So sieht es aus, einfach alles, was _GET und GET hiess auf _POST bzw. POST ändern.

grüße

[Stonie]

Hallöle!

Zum Thema Sicherheit kann ich leider nicht viel sagen; aber ich hab's auch mal ausprobiert (Mozilla Firefox 2.0.0.14). Funktioniert alles, soweit ich das übersehen kann. Ich find's ein bisschen irritierend, dass nach dem Absenden einfach das Formular nochmal kommt (naja, ok, könnt' sein, dass man noch eine zweite Nachricht versenden möchte - möchte ich aber eher selten). Bescheid! :o)

File Griese,

Stonie

[Malcolm Beck´s]

hi,

Zum Thema Sicherheit kann ich leider nicht viel sagen; aber ich hab's auch mal ausprobiert (Mozilla Firefox 2.0.0.14). Funktioniert alles, soweit ich das übersehen kann. Ich find's ein bisschen irritierend, dass nach dem Absenden einfach das Formular nochmal kommt (naja, ok, könnt' sein, dass man noch eine zweite Nachricht versenden möchte - möchte ich aber eher selten). Bescheid! :o)

Danke fürs nachsehen und bescheid. :)

Ich bin noch in der Entwicklungsphase, bevor ich da jetzt zuviel Zeit investiere wollte ich auf nummer sicher gehen, die Abschickbestätigung ist schon vorbereitet, nach dem abschicken steht in der URL ?mail=ok, das muss nur noch ins HTML. :)

Gerade Prasseln die ersten Mails ein. :-)

grüße

[Stonie]

Hallöle!

Gerade Prasseln die ersten Mails ein. :-)

*hihi* Ja, mit sowas muss man hier rechnen. Erzähl dann mal heute abend oder so, wieviele es dann waren. Es interessiert mich einfach.

File Griese,

Stonie

[gooxsy]

Hi Stonie,

*hihi* Ja, mit sowas muss man hier rechnen. Erzähl dann mal heute abend oder so, wieviele es dann waren. Es interessiert mich einfach.

Viel interessanter wäre ja noch, _was_ da so geschrieben wird. Vielen ist sicher nicht klar, daß sie da gerade dabei sind, eine Mail zu versenden und deshalb vielleicht aufregendere Dinge als "Das ist ein Test" schreiben. ;-)

mfG

gooxsy

[Malcolm Beck´s]

hi,

*hihi* Ja, mit sowas muss man hier rechnen. Erzähl dann mal heute abend oder so, wieviele es dann waren. Es interessiert mich einfach.

Ein nicht unbekanntes Mitglied des Mod Team versuchte gerade folgendes:

/%22%3E%3Cscript%3Ealert('XSS')%3C/script%3E%3Cform=%22

Das Script scheint gut zu sein. Heute abend kommt ein ausführlicher Bericht. :)

grüße

[Ingo Turski]

Hi,

Ein nicht unbekanntes Mitglied des Mod Team versuchte gerade folgendes:

/%22%3E%3Cscript%3Ealert('XSS')%3C/script%3E%3Cform=%22

Das Script scheint gut zu sein.

nö, wie Du in meiner letzten Nachicht siehst... Ich hatte zunächst nur die magic_quotes nicht berücksichtigt.

freundliche Grüße
Ingo

[Malcolm Beck´s]

hi,

Gerade Prasseln die ersten Mails ein. :-)
*hihi* Ja, mit sowas muss man hier rechnen. Erzähl dann mal heute abend oder so, wieviele es dann waren. Es interessiert mich einfach.

So, Auswertung ist beendet.
Es waren nur 9 Mails aber laut Logs bedeutend mehr testende im Spiel. :)
Inhaltlich war keiner der mails wirklich überzeugend, nur Hansis Mail war noch Akzeptabel, Grüsse an "Hallo Welt!" Hansi. :)

grüße

[Volker Nebelung]

Aloha 'oe,

hab mich heute Nacht endlich mal aufgerafft und mir ein Formmailer gebastelt, es gibt ja genug fertige Scripte aber alles irgendwie so ne sache für sich.

Wenn ich probeweise in ein Feld "<style="color: red;"> eingebe, kommt "<style="color: red">" als Vorschau dabei heraus. Wozu die Backslashes? Ein htmlspecialchars sollte an dieser Stelle ausreichen.

Gruß, Volker

[Malcolm Beck´s]

hi,

Wenn ich probeweise in ein Feld "<style="color: red;"> eingebe, kommt "<style="color: red">" als Vorschau dabei heraus. Wozu die Backslashes? Ein htmlspecialchars sollte an dieser Stelle ausreichen.

Wie meinst du das? htmlspecialchars erzeugen diese Backslashes.

grüße

[gooxsy]

Hi Malcolm,

Wie meinst du das? htmlspecialchars erzeugen diese Backslashes.

Nein, schau Dir an, was htmlspecialchars macht.

Und verwende die Funktion _nur_ für die Vorschau und später dann für die Ausgabe. Gewöhne Dir aber an, die Daten _genau so_ zu speichern, wie sie der user eingibt. Natürlich mußt Du Dich auch gegen SQL-Injections absichern.

Deshalb ist , wie hier im Forum schon des öfteren besprochen, folgendes Procedere der Standard: (Kurzversion)

* Userdaten übernehmen
* Schutz gegen SQL Injections mit der Funktion mysql_real_escape_string in Form von Beispiel 3 (Optimale Vorgehensweise zur Querybehandlung)
* Speichern der Daten
* Abruf der Daten
* _Jetzt_ htmlspecialchars verwenden und dann
* Daten ausgeben

mfG

gooxsy

grüße

[Malcolm Beck´s]

hi gooxsy,

Nein, schau Dir an, was htmlspecialchars macht.

Und verwende die Funktion _nur_ für die Vorschau und später dann für die Ausgabe. Gewöhne Dir aber an, die Daten _genau so_ zu speichern, wie sie der user eingibt. Natürlich mußt Du Dich auch gegen SQL-Injections absichern.

Ja, an diesen Diskussionen war ich auch des öfteren vertreten, mein Formmailer soll aber nur ein Formmailer sein, das heisst die eingaben sollen mir nur als Mail zukommen, wie ich Daten in eine DB kriege weiss ich, ich weiss nur nicht worauf ich bei Mails achten muss.
Für mich ist nur wichtig das mir der Formmailer keine kopfschmerzen macht, HTML darf von mir aus bis zur unkenntlichkeit maskiert werden, will ich ja eh nicht haben.

Danke trotzdem für den Hinweis, die DB erweiterung fü dieses Script folgt bestimmt demnächst, dann komm ich drauf zurück. :)

grüße

[Volker Nebelung]

Aloha 'oe,

Für mich ist nur wichtig das mir der Formmailer keine kopfschmerzen macht, HTML darf von mir aus bis zur unkenntlichkeit maskiert werden, will ich ja eh nicht haben.

Bei dir mag das auch kein Problem darstellen, die Frage ist, ob man dem Benutzer als Vorschau etwas präsentieren sollte, dass er so nicht eingegeben hat. Evtl. verwirren die Backslashes manche ... Zugegeben etwas spitzfindig, aber schließlich sagte schon mein alter Saufkumpan Sir Frederick Henry Royce:
"Kleinigkeiten sind es, die Perfektion ausmachen, aber Perfektion ist alles andere als eine Kleinigkeit."

Gruß, Volker

[Malcolm Beck´s]

hi,

Bei dir mag das auch kein Problem darstellen, die Frage ist, ob man dem Benutzer als Vorschau etwas präsentieren sollte, dass er so nicht eingegeben hat. Evtl. verwirren die Backslashes manche ... Zugegeben etwas spitzfindig, aber schließlich sagte schon mein alter Saufkumpan Sir Frederick Henry Royce:
"Kleinigkeiten sind es, die Perfektion ausmachen, aber Perfektion ist alles andere als eine Kleinigkeit."

Danke für den hinweis.

Da hat dein alter Saufkumpan Sir Frederick Henry Royce Recht. :)
Diese Maskierung kommt von den Magicquotes, habe es jetzt mittels strreplace einfach angepasst, jetzt bin ich mir aber wieder wegen der Sicherheit unsicher.

http://start-navi.de/beispiele/form3.php - so sieht es aus

grüße

[Volker Nebelung]

Aloha 'oe,

Diese Maskierung kommt von den Magicquotes, habe es jetzt mittels strreplace einfach angepasst, jetzt bin ich mir aber wieder wegen der Sicherheit unsicher.

Zumindest das "Sie mögen"-Feld wird nicht genügend überprüft. Übermittelt man probeweise
<script type=text/javascript>alert(true);</script>
(ohne Anführungszeichen, denn die werden wieder maskiert) als Inhalt des Feldes, wird der Code ohne Murren ausgeführt.

Gruß, Volker

[Malcolm Beck´s]

hi,

Zumindest das "Sie mögen"-Feld wird nicht genügend überprüft. Übermittelt man probeweise
<script type=text/javascript>alert(true);</script>
(ohne Anführungszeichen, denn die werden wieder maskiert) als Inhalt des Feldes, wird der Code ohne Murren ausgeführt.

Hehe, wie hast du denn da dieses stück Code reingekriegt?

Alles andere ist aber soweit in Ordnung oder? Ich hab das noch erweitert für zukünftige Aufgaben, könntest du das auch mal angreifen?
http://kultdose.de/ideal-data/kontakt.php

grüße und Danke

[Volker Nebelung]

Aloha 'oe,

zur Überschrift: Hacker sind hier dem Wortsinn nach genug im Forum unterwegs, und da gibt es Leute, die viel mehr draufhaben als ich.

Hehe, wie hast du denn da dieses stück Code reingekriegt?

Selbst Laien können POST-Daten manipulieren.
Simple (wenn auch umständliche) Möglichkeit: Ein Formular auf eigenem Webspace basteln, welches auf dein Skript zeigt und die Eingabefelder als type="text" deklariert.

Alles andere ist aber soweit in Ordnung oder? Ich hab das noch erweitert für zukünftige Aufgaben, könntest du das auch mal angreifen?
http://kultdose.de/ideal-data/kontakt.php

Zumindest Javascript lässt sich dort nicht ausführen.

Gruß, Volker

[Malcolm Beck´s]

hi,

zur Überschrift: Hacker sind hier dem Wortsinn nach genug im Forum unterwegs, und da gibt es Leute, die viel mehr draufhaben als ich.

Ja, den Thread hatte ich gesehen, Wahnsinn.

Simple (wenn auch umständliche) Möglichkeit: Ein Formular auf eigenem Webspace basteln, welches auf dein Skript zeigt und die Eingabefelder als type="text" deklariert.

Das muss ich mal testen, da könnte man doch ganze Eingabefelder nach lust  und Laune ändern, wie kann das sein?
Ich hab deine Domain in meinen Logs gesehen, kam aber leider nicht drauf. :)

http://kultdose.de/ideal-data/kontakt.php
Zumindest Javascript lässt sich dort nicht ausführen.

Wie kann man denn seine Seiten Umfangreich testen? Kennst du da eine möglichkeit?

grüße und Danke

[Volker Nebelung]

Aloha 'oe,

Wie kann man denn seine Seiten Umfangreich testen? Kennst du da eine möglichkeit?

Also im Studium habe ich gelernt, dass zu jeder Eingabemaske ein Prüfprotokoll zu entwerfen ist, mit dem man nach einem vorgegebenen Ablauf alle möglichen (oder zumindest als schwierig zu verarbeiten angesehene) Eingaben testen kann.
Aber dass das in der Regel nicht allzu umfrangreich geschieht, sieht man am Erfolg von Fuzzing-Attacken.
Vielleicht hilft dir das Stichwort, entsprechende Tools zu finden.

Gruß, Volker

[Malcolm Beck´s]

hi,

Also im Studium habe ich gelernt, dass zu jeder Eingabemaske ein Prüfprotokoll zu entwerfen ist, mit dem man nach einem vorgegebenen Ablauf alle möglichen (oder zumindest als schwierig zu verarbeiten angesehene) Eingaben testen kann.

Das klingt Logisch, im Grunde würden da ja ein Paar Javascripte zum testen reichen.

Aber dass das in der Regel nicht allzu umfrangreich geschieht, sieht man am Erfolg von Fuzzing-Attacken.
Vielleicht hilft dir das Stichwort, entsprechende Tools zu finden.

Für Internetseiten direkt scheint es da nicht all zuviel zu geben, ich werde mal gucken ob ich ein Paar Scripte finde, mit denen man selbst testen kann.
Zur Not belege ich einen Hacker Kurs. :)

Danke jedenfalls für die hilfe.

Und, du weißt nicht zufällig wie eine Datei namens .htPOSTdata.txt in mein Webverzeichnis kam?
Ich kann es mir jedenfalls nicht erklären. Das war plötzlich da.

grüße

[dedlfix]

echo $begrüßung;

Deshalb ist , wie hier im Forum schon des öfteren besprochen, folgendes Procedere der Standard: (Kurzversion)

* Userdaten übernehmen

Im Allgemeinen stehen sie schon in $_GET/$_POST/usw. bereit. Sie müssen nicht mehr übernommen werden. Sie müssen aber gegebenenfalls von den Magic Quotes befreit werden.

* Schutz gegen SQL Injections mit der Funktion mysql_real_escape_string in Form von Beispiel 3 (Optimale Vorgehensweise zur Querybehandlung)
* Speichern der Daten

Das sollte man nicht in zwei Schritte aufteilen. Es empfiehlt sich, die notwendige kontextgerechte Behandlung von Daten genau dann vorzunehmen, wenn die Daten in den Kontext eingefügt werden. Das sollte integraler Bestandteil jeder Datenübergabe sein, und nicht ein Extra-Schritt, den man zusätzlich beachten muss, wenn man mal später was ergänzt.

* _Jetzt_ htmlspecialchars verwenden und dann
* Daten ausgeben

Selbe Problematik wie oben.

echo htmlspecialchars($x);

statt

$x = htmlspecialchars($x);
  echo $x;

echo "$verabschiedung $name";

[gooxsy]

Hi dedlfix,

Im Allgemeinen stehen sie schon in $_GET/$_POST/usw. bereit.

Anders hab ich das auch nie gesehen.

Sie müssen nicht mehr übernommen werden.

Damit meinte ich einfach die Verwendung von $_GET bzw. $_POST.

* Schutz gegen SQL Injections mit der Funktion mysql_real_escape_string in Form von Beispiel 3 (Optimale Vorgehensweise zur Querybehandlung)
* Speichern der Daten

Das sollte man nicht in zwei Schritte aufteilen. Es empfiehlt sich, die notwendige kontextgerechte Behandlung von Daten genau dann vorzunehmen, wenn die Daten in den Kontext eingefügt werden. Das sollte integraler Bestandteil jeder Datenübergabe sein, und nicht ein Extra-Schritt, den man zusätzlich beachten muss, wenn man mal später was ergänzt.

Auch das hab ich nie anders gesehen. Aber wenn Du so einen Programmcode schreibst, in der beide Dinge passieren, dann kommt die Behandlung _vor_ der Speicherung, deshalb so hintereinander von mir aufgelistet.

* _Jetzt_ htmlspecialchars verwenden und dann
* Daten ausgeben

Selbe Problematik wie oben.

Meine selbe Antwort wie oben.

echo htmlspecialchars($x);

statt

$x = htmlspecialchars($x);
  echo $x;

Wie kommst Du eigentlich darauf, daß ich für diesen unnötigen Zwischenschritt bin? Wie Du bei einer einer Antworten an Malcolm siehst, verarbeite ich auch das _Get bzw. _POST _direkt_.

mfG

gooxsy

[dedlfix]

echo $begrüßung;

Im Allgemeinen stehen sie schon in $_GET/$_POST/usw. bereit.
Anders hab ich das auch nie gesehen.
Sie müssen nicht mehr übernommen werden.
Damit meinte ich einfach die Verwendung von $_GET bzw. $_POST.

Leider trifft man diese Formulierung vom Übernehmen ziemlich häufig. Und die meisten verbinden damit das unnötige Umkopieren in andere Variablen. Deswegen beanstandete ich zumindest deine Formulierung.

echo htmlspecialchars($x);
statt
  $x = htmlspecialchars($x);
  echo $x;
Wie kommst Du eigentlich darauf, daß ich für diesen unnötigen Zwischenschritt bin?

Weil du diese Handlung in zwei Schritte aufgeteilt beschrieben hast. Liegt es da nicht nahe, das als in zwei Schritten zu implementieren zu deuten?

Wie Du bei einer einer Antworten an Malcolm siehst, verarbeite ich auch das _Get bzw. _POST _direkt_.

Und genau da fehlt das htmlspecialchars().

echo "$verabschiedung $name";

[Malcolm Beck´s]

hi,

Leider trifft man diese Formulierung vom Übernehmen ziemlich häufig. Und die meisten verbinden damit das unnötige Umkopieren in andere Variablen. Deswegen beanstandete ich zumindest deine Formulierung.

Durch das umkopieren erspare ich mir viel geschreibe an anderen stellen.

Beispielsweise,

  
 if (isset($_POST['Name'])) {  
  $name_value = htmlspecialchars($Name);  
 }  
  else { $name_value = 'was auch immer'; }

Jetzt kann ich mit den Variablen Flexibel arbeiten, was spricht dagegen?
Mit Flexibel meine ich z.b. eine Vorschau, Affenformular, fehlermeldungen ggbf. an 2 stellen.
Wenn ich jedes mal direkt mit $_GET oder $_POST arbeiten würde müsste ich jedesmal die abfrage machen, ob der Wert überhaupt vorhanden ist.

Das jetzt laut meiner Logik, die eigentlich meistens falsch ist.

grüße

[dedlfix]

echo $begrüßung;

Leider trifft man diese Formulierung vom Übernehmen ziemlich häufig. Und die meisten verbinden damit das unnötige Umkopieren in andere Variablen. Deswegen beanstandete ich zumindest deine Formulierung.

Durch das umkopieren erspare ich mir viel geschreibe an anderen stellen.
Beispielsweise,
if (isset($_POST['Name'])) {
  $name_value = htmlspecialchars($Name);
}
  else { $name_value = 'was auch immer'; }[/code]

Damit hast du nun deinen Variableninhalt bereits für eine bestimmte Ausgabe vorbereitet. Wenn die Daten nun auch noch in eine Datenbank geschrieben werden sollen, was machst du dann? Dann hast du unbrauchbare HTML-Kodierungen drin.

Es spricht nichts dagegen, wenn du die Eingabedaten prüfst und eventuell einen Defaultwert für nicht oder fehlerhaft eingegebene Werte verwendest. Dieses geprüfte Ergebnis kann man in einer eigenen Variable anlegen. Es ist dann auch nicht mehr unbedingt das mit einem $_POST-Wert im Hinterkopf verbundene "Achtung! Ungeprüfte Benutzereingabe!" notwendig. Prüfen bedeutet aber nicht, Werte für eine bestimmte Ausgabe vorzubereiten. Das ist am besten dort aufgehoben, wo diese Ausgabe erzeugt wird. So sieht man an Ort und Stelle dass die Behandlung für den Ausgabekontext erfolgte, und muss nicht erst den gesamten vorherigen Quelltext durchsuchen, ob denn die Werte bereits berücksichtigt worden sind.

Es spricht etwas dagegen, wenn man einfach nur stur $x = $_POST['x']; für alle Eingabewerte verwendet. Dabei geht einfach nur der optische Hinweis auf die Benutzereingabe verloren, ohne dass man etwas wesentliches dazugewinnt.

Jetzt kann ich mit den Variablen Flexibel arbeiten, was spricht dagegen?
Mit Flexibel meine ich z.b. eine Vorschau, Affenformular, fehlermeldungen ggbf. an 2 stellen.

Das ist nicht mehr flexibel sondern festgelegt auf ein Ausgabemedium. Flexibel wären Rohdaten, die für beliebige Anwendungsfälle verwendet werden können.

Zum Beispiel ein Datum. Der Anwender soll, wie in Deutschland üblich, das Datum in der Form tt.mm.jjjj eingeben. Er gibt 31.2.2008 ein. So kann man es aber nicht prüfen, geschweige denn für ein Datumsfeld einer Datenbank verwenden, das die Schreibweise yyyy-mm-dd verlangt. Falsch ist er auch noch, März hätte der Anwender eigentlich eingeben wollen. In $_POST['datum'] steht die Benutzereingabe. Dieser Eingabewert soll aber auch nicht verloren gehen, denn im Fehlerfall soll dem Anwender genau diese falsche Eingabe zur Korrektur vorgelegt werden. Ein leeres Eingabefeld (nebst Fehlermeldung) vorzulegen ist unfein, muss er doch wegen des einen kleinen Tippfehlers alles nochmal eingeben. Rohdaten, um daraus ein Datum formatieren zu können, stehen wegen des fehlerhaften Wertes nicht zur Verfügung. Als Lösung kann man $_POST['datum'] für das Affenformular so lassen wie es ist. Der kontrollierte und in einen Unix-Timestamp umgewandelte Wert kann und muss in einer anderen Variable zu liegen kommen. Wenn alles richtig war kann dieser Roh-Wert nun bei der Ausgabe an diverse Ausgabemedien mit den üblichen Funktionen formatiert werden.

Wenn ich jedes mal direkt mit $_GET oder $_POST arbeiten würde müsste ich jedesmal die abfrage machen, ob der Wert überhaupt vorhanden ist.

Die Antwort lautet EVA-Prinzip. Erst die Eingabedaten behandeln und prüfen. Dann die Verarbeitung mit ihnen vornehmen. Da sie ja bereits geprüft und vorhanden sind, muss man sich während der Verarbeitung und der Ausgabe auch nicht ständig erneut prüfen.

echo "$verabschiedung $name";

[Malcolm Beck´s]

hi,

Damit hast du nun deinen Variableninhalt bereits für eine bestimmte Ausgabe vorbereitet. Wenn die Daten nun auch noch in eine Datenbank geschrieben werden sollen, was machst du dann? Dann hast du unbrauchbare HTML-Kodierungen drin.

Das ist mir klar, hier geht es ja Primär um einen Formmailer, das Script soll mir einfach nur zuverlässig die Usereingaben an mein Mail Konto senden.

Prüfen bedeutet aber nicht, Werte für eine bestimmte Ausgabe vorzubereiten. Das ist am besten dort aufgehoben, wo diese Ausgabe erzeugt wird. So sieht man an Ort und Stelle dass die Behandlung für den Ausgabekontext erfolgte, und muss nicht erst den gesamten vorherigen Quelltext durchsuchen, ob denn die Werte bereits berücksichtigt worden sind.

Das werde ich mir nochmal anschauen, in diesem beispiel weiss ich ja ganz genau was ich brauch und was ich damit anstellen will.

http://kultdose.de/ideal-data/kontakt.php - das fertige Produkt, macht genau das, was ich benötige.
Was noch fehlt ist eine E-Mail validierung, da muss ich noch schauen.

Das ist nicht mehr flexibel sondern festgelegt auf ein Ausgabemedium. Flexibel wären Rohdaten, die für beliebige Anwendungsfälle verwendet werden können.

Stimmt, Flexibel aus "meiner" Sicht, ich weiss ja in dem Fall was mit den Eingaben passiert, das das Script nicht Super ist ist mir klar, aber eine gute Grundlage darauf aufzubauen um es besser zu verstehen.

Die Antwort lautet EVA-Prinzip. Erst die Eingabedaten behandeln und prüfen. Dann die Verarbeitung mit ihnen vornehmen. Da sie ja bereits geprüft und vorhanden sind, muss man sich während der Verarbeitung und der Ausgabe auch nicht ständig erneut prüfen.

Und irgendwann werde ich auch das verstehen. :)

grüße

[at]

Hallo.

Was noch fehlt ist eine E-Mail validierung, da muss ich noch schauen.

Vergiss das. Du kannst mit Mühe und Not heute gültige Adressen erkennen, vielleicht noch welche, die in Zukunft möglich sein werden, aber du wirst nie die Existenz einer Adresse sicher feststellen können. Und warum dann noch auf ein @ prüfen?
MfG, at

[Ingo Turski]

Hi,

nur kann ich nicht beurteilen, ob das ding sicher ist, könnte mal jemand drüber schauen ob es sicherheitslücken gibt?

Da Du alle Userdaten in den mail-body packst, ist die Sicherheit zunächst mal gewährt, d.h. es können keine mail-header manupuliert werden. Allerdings lassen sich Links (bzw. im Falle von POST ein vorgefertigtes Formular) auf die Seite setzen, die Deine Ausgaben manipulieren können.

Und das Script sieht wie folgt aus, bissel viel

in der Tat - Du könntest viele redundante Codes in Funktionen auslagern.

if(get_magic_quotes_gpc())

die sind leider auf Deinem Webspace on - würde ich ändern.

header("Location: $strReturnhtml");

ich persönlich mag solche Weiterleitungen nicht und steuere lieber *alles* in derselben Seite.

<form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="GET">

wunderbar für XSS, z.B. so ;-) - Deine magic_quotes verhindern zwar schlimmeres, aber trotzdem...

freundliche Grüße
Ingo

[Malcolm Beck´s]

hi,

Da Du alle Userdaten in den mail-body packst, ist die Sicherheit zunächst mal gewährt, d.h. es können keine mail-header manupuliert werden. Allerdings lassen sich Links (bzw. im Falle von POST ein vorgefertigtes Formular) auf die Seite setzen, die Deine Ausgaben manipulieren können.

Hätte das auswirkungen auf meinen Server oder wäre ich leicht "hackbar"?

in der Tat - Du könntest viele redundante Codes in Funktionen auslagern.

Ist in Übung. :)

die sind leider auf Deinem Webspace on - würde ich ändern.

Da müsste ich an die php.ini, da trau ich mich nicht ran, da müsste ich eine Menge anpassen.

ich persönlich mag solche Weiterleitungen nicht und steuere lieber *alles* in derselben Seite.

Meine derzeit einzig realisierbare reloadsperre, ich scripte noch nicht so lang.

<form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="GET">
wunderbar für XSS, z.B. so ;-) - Deine magic_quotes verhindern zwar schlimmeres, aber trotzdem...

Hehe, ich sag doch, ihr vom MOD Team seid Gemein Gefährlich. :)
Danke für den hinweis, hab ich entfernt, geht das was du da gemacht hast noch oder hast du mehr auf Lager?  :)

grüße

[Ingo Turski]

Hi,

Allerdings lassen sich Links (bzw. im Falle von POST ein vorgefertigtes Formular) auf die Seite setzen, die Deine Ausgaben manipulieren können.

Hätte das auswirkungen auf meinen Server oder wäre ich leicht "hackbar"?

Nein, das hat keine Auswirkungen und leicht "hackbar" ist nur die GET-Methode.

Da müsste ich an die php.ini, da trau ich mich nicht ran, da müsste ich eine Menge anpassen.

nein, Du kannst das meist auch über die .htaccess steuern. Bei mir steht z.B. u.a. drin:

php_flag register_globals off  
php_flag short_open_tag off  
php_flag magic_quotes_gpc Off  
php_flag session.use_trans_sid 0  
Options -Indexes

ich persönlich mag solche Weiterleitungen nicht und steuere lieber *alles* in derselben Seite.

Meine derzeit einzig realisierbare reloadsperre, ich scripte noch nicht so lang.

es gibt da viele andere Möglichkeiten. Ein ganz simple, wenn auch nicht 100%ige, ist diese:

function tsNewPost($text,$log='.htPOSTdata.txt') {  
  if(file_exists($log) && is_readable($log) && file_get_contents($log) == $text)  
    return false;  
  if($handle=@fopen($log, 'w')) {  
    fwrite($handle, $text); fclose($handle);  
  }  
  return true;  
}  
# ...  
if(tsNewPost($tsForm['Text']))  
# ... mail(...) ...  
else tsAddError('Diese Nachricht war bereits verschickt worden !');

Hehe, ich sag doch, ihr vom MOD Team seid Gemein Gefährlich. :)
Danke für den hinweis, hab ich entfernt, geht das was du da gemacht hast noch oder hast du mehr auf Lager?  :)

Du solltest $_SERVER['PHP_SELF'] nicht entfernen, sondern durch $_SERVER['SCRIPT_NAME'] ersetzen. So oder so geht das dann nicht mehr, aber man kann natürlich noch Links (oder vorgefertigte Formulare) wie diesen setzen; ist aber nicht weiter tragisch.
Allerdings kann man auch die Vorschau umgehen... oder gleich eine Mail abschicken lassen durch anhängen von "&abschicken=" - den Link will ich Dir jetzt aber ersparen. ;-)

Bei der GET-Methode könnte letzteres sogar schaden, indem eine solche URL z.B. auf einer hochfrequentierten Seite als img-source eingebunden wird. Mein kleines Testscript oben könnte sowas allerdings nebenbei auch verhindern.

freundliche Grüße
Ingo

[Malcolm Beck´s]

hi,

Nein, das hat keine Auswirkungen und leicht "hackbar" ist nur die GET-Methode.

Das ist gut zu wissen, ich hab mittlerweile die GET methode rausgenommen, dann passt das ja ganz.

nein, Du kannst das meist auch über die .htaccess steuern. Bei mir steht z.B. u.a. drin:

php_flag register_globals off

php_flag short_open_tag off
php_flag magic_quotes_gpc Off
php_flag session.use_trans_sid 0
Options -Indexes

  
Eben nicht, das ist ne Geschichte die ich schon vor nem halben Jahr probiert hab, alle Zeilen bis auf `Options -Indexes`{:.language-apache} produzieren bei mir einen 500 Serverfehler, ich bin bei 1und1.  
  

> es gibt da viele andere Möglichkeiten. Ein ganz simple, wenn auch nicht 100%ige, ist diese:  
> ~~~php

function tsNewPost($text,$log='.htPOSTdata.txt') {  

>   if(file_exists($log) && is_readable($log) && file_get_contents($log) == $text)  
>     return false;  
>   if($handle=@fopen($log, 'w')) {  
>     fwrite($handle, $text); fclose($handle);  
>   }  
>   return true;  
> }  
> # ...  
> if(tsNewPost($tsForm['Text']))  
> # ... mail(...) ...  
> else tsAddError('Diese Nachricht war bereits verschickt worden !');

Das muss ich heute Nacht mal probieren, wobei eine frage hätte ich, welche variablen sind hier für mich wichtig? Klassen dieser art habe ich schon dutzende probiert aber es scheitert immer an den Variablen, wo ich nicht weiss, welche ich anpasen muss.

aber man kann natürlich noch Links (oder vorgefertigte Formulare) wie diesen setzen; ist aber nicht weiter tragisch.

Das wurde auch eingedämmt. :)

Allerdings kann man auch die Vorschau umgehen... oder gleich eine Mail abschicken lassen durch anhängen von "&abschicken=" - den Link will ich Dir jetzt aber ersparen. ;-)

Danke! Wobei, _jetzt_ ist´s auch egal. :)

grüße

[Ingo Turski]

Hi,

Eben nicht, das ist ne Geschichte die ich schon vor nem halben Jahr probiert hab, alle Zeilen bis auf Options -Indexes produzieren bei mir einen 500 Serverfehler, ich bin bei 1und1.

vielleicht kann Dir Patrick Andrieu dazu einen Tipp geben - wenn ich mich recht erinnere, ist er auch 1und1-geplagt. Oder bemühe die Forensuche mal mit Angabe seines Namens und 1und1.

es gibt da viele andere Möglichkeiten. Ein ganz simple, wenn auch nicht 100%ige, ist diese:

function tsNewPost($text,$log='.htPOSTdata.txt') {

if(file_exists($log) && is_readable($log) && file_get_contents($log) == $text)
    return false;
  if($handle=@fopen($log, 'w')) {
    fwrite($handle, $text); fclose($handle);
  }
  return true;
}

...

if(tsNewPost($tsForm['Text']))

... mail(...) ...

else tsAddError('Diese Nachricht war bereits verschickt worden !');

>   
> Das muss ich heute Nacht mal probieren, wobei eine frage hätte ich, welche variablen sind hier für mich wichtig? Klassen dieser art habe ich schon dutzende probiert aber es scheitert immer an den Variablen, wo ich nicht weiss, welche ich anpasen muss.  

Das hier ist keine Klasse, sondern eine einfache Funktion. Sie erwartet als 1.Parameter den Mailtext, so wie er auch an Dich geschickt werden soll. Bei mir steht er im Array $tsForm.  
Als optionalen 2.Parameter kann das Logfile angegeben werden.  
Die zweite Funktion dient nur der Vermeidung von Redundanz und sieht so aus:  
~~~php
function tsAddError($err) {  
  global $tsForm;  
  if($tsForm['Fehler']) $tsForm['Fehler'] .= '<br />';  
  $tsForm['Fehler'] .= $err;  
}

Vor dem Aufruf der ersten Funktion und dem Versenden steht demensprechend noch:
if(!$tsForm['Fehler']) {
und im HTML schließlich:
<?php if($tsForm['Fehler']) echo '<p id="Fehler">',$tsForm['Fehler'],'</p>'; ?>
Zugegeben hätte ich auch eine Liste wählen können, aber diese nur bei Fehlerausgabe erscheinende zu formatieren hatte ich keine Lust. ;-)
Der PHP-Code für eine Liste wäre aber simpel:

function tsAddError($err) {  
  global $tsForm;  
  $tsForm['Fehler'] .= '<li>.$err.</li>;  
}  
# ...  
<?php if($tsForm['Fehler']) echo '<ul id="Fehler">',$tsForm['Fehler'],'</ul>'; ?>

wobei eine Liste mit nur einem Listenpunkt auch wieder Murks wäre... auch ein Grund für p.

freundliche Grüße
Ingo

[Malcolm Beck´s]

hi,

vielleicht kann Dir Patrick Andrieu dazu einen Tipp geben - wenn ich mich recht erinnere, ist er auch 1und1-geplagt. Oder bemühe die Forensuche mal mit Angabe seines Namens und 1und1.

Patrick Perlt. :) Soweit ich weiss hat der mit der .htaccess auch nur fehlerseiten definiert, vielleicht liest er ja mit und Postet mal was. :)

Das hier ist keine Klasse, sondern eine einfache Funktion. Sie erwartet als 1.Parameter den Mailtext, so wie er auch an Dich geschickt werden soll. Bei mir steht er im Array $tsForm.

Danke für die hilfe aber ich bleib wohl erstmal bei dem was ich hab, deine Funktion krieg ich nicht integriert, wobei meine lösung ja auch in Ordnung ist, das POST Cache wird geleert und eine Bestätigung kann ich auch ausgeben.
Ich bau das Formular jetzt erstmal zu ende.

Danke an alle beteiligten.

grüße

[Patrick Andrieu]

Hallo Ingo und Malcolm!

vielleicht kann Dir Patrick Andrieu dazu einen Tipp geben - wenn ich mich recht erinnere, ist er auch 1und1-geplagt.

Ja, aber da

Patrick perlt.

betrifft es nur ein seltsames Verhalten mit Perls Tainted Mode (http://forum.de.selfhtml.org/archiv/2007/7/t156581/#m1018956 und http://forum.de.selfhtml.org/archiv/2008/1/t165630/#m1079858) und die Tatsache, dass keine error.log zur Verfügung steht.

Sonst hält sich das »Geplagtsein« in Grenzen, ich bin eigentlich relativ zufrieden.

Soweit ich weiss hat der mit der .htaccess auch nur fehlerseiten definiert, vielleicht liest er ja mit und Postet mal was. :)

Ja, er liest mit - wenn auch wenig die letzten Tagen. Mit .htaccess habe ich nicht nur Fehlerseiten umgeleitet, sondern Gone-Seiten angegeben, Ressourcen redirected, urls rewrited und .goek als Dateiendung für den Perlinterpreter auf goek.atomic-eggs.com angegeben. .htaccess ist also ein Buch mit jetzt weniger als sieben Siegel für mich ;)

PHP ist mir dagegen noch total fremd, außer »Hallo Welt«-Geschichten habe ich da nichts probiert, und habe keine Lust dazu, solange ich Perl nicht aus dem ff kenne.

Daher: Was bewirken die Anweisungen, und (Frage an Malcolm bevor ich es ausprobieren soll), kommt dann generell ein 500er Fehler, also beim Aufruf irgendeiner beliebigen Seite/Ressource, wie manchmal bei fehlerhaften Rewrite- oder Redirect-Regeln, oder nur bei Aufruf von .php-Seiten?

Viele Grüße aus Frankfurt/Main,
Patrick

[Malcolm Beck´s]

hi PAF,

Sonst hält sich das »Geplagtsein« in Grenzen, ich bin eigentlich relativ zufrieden.

Ich auch, im grossen und ganzen alles zufriedenstellend.

Fehlerseiten umgeleitet, sondern Gone-Seiten angegeben, Ressourcen redirected, urls rewrited und .goek als Dateiendung für den Perlinterpreter auf goek.atomic-eggs.com angegeben. .htaccess ist also ein Buch mit jetzt weniger als sieben Siegel für mich ;)

Jau, ganz vergessen. :) Meine .htaccess werden auch mit jeder neuen Domain immer spektakulärer, wenn ich die 100 Domain Grenze überschritten hab passiert ein Wunder[1]. :)

PHP ist mir dagegen noch total fremd, außer »Hallo Welt«-Geschichten habe ich da nichts probiert, und habe keine Lust dazu, solange ich Perl nicht aus dem ff kenne.

Hä? Whas is denn ff?

Daher: Was bewirken die Anweisungen, und (Frage an Malcolm bevor ich es ausprobieren soll), kommt dann generell ein 500er Fehler, also beim Aufruf irgendeiner beliebigen Seite/Ressource, wie manchmal bei fehlerhaften Rewrite- oder Redirect-Regeln, oder nur bei Aufruf von .php-Seiten?

Ich hab mal die .htaccess hochgeladen und die index ist jetzt eine stinknormale html Datei,

Vorneweg, alle erzeugen einen 500er!

http://start-navi.de/

http://start-navi.de/beispiele/ - hier liegt auch ne index.html, aber kein .htaccess

http://start-navi.de/beispiele/form1.php - damit wurde heute und Gestern noch gespielt

Das Gesamte Verzeichnis dieser Domain ist unbrauchbar, im Root liegen noch 4 andere Domains[keine Subdomains], die funzen[TM] alle aber noch.

grüße
[1] Noch ca. 90, dann hab ich sie. :)

[Patrick Andrieu]

Hallo Malcolm!

solange ich Perl nicht aus dem ff kenne.
Hä? Whas is denn ff?

EffEff

Vorneweg, alle erzeugen einen 500er!

Habe ich mittlerweile auch ausprobiert, Ergebnis: Sobald »php_flag somewhat« in der .htaccess steht, ist der Server nimmer froh.

Vielleicht hilft ein »AllowOverride all«, aber das probiere ich nicht aus:
http://www.howtoforge.com/forums/showthread.php?t=3011 (2 ersten Beiträge).

[1] Noch ca. 90, dann hab ich sie. :)

Schaffst Du in 2 Monaten ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Malcolm Beck´s]

hi PAF,

solange ich Perl nicht aus dem ff kenne.
Hä? Whas is denn ff?
EffEff

Ah, wieder was gelernt.

Habe ich mittlerweile auch ausprobiert, Ergebnis: Sobald »php_flag somewhat« in der .htaccess steht, ist der Server nimmer froh.
Vielleicht hilft ein »AllowOverride all«, aber das probiere ich nicht aus:
http://www.howtoforge.com/forums/showthread.php?t=3011 (2 ersten Beiträge).

Nein, das hilft auch nicht.

AllowOverride All  
php_flag register_globals off  
php_flag magic_quotes_gpc Off

Auch das in dem thread weiter unten aufgeführte mit admin funzt[TM] nicht.

AllowOverride All  
php_admin_flag register_globals off  
php_admin_flag magic_quotes_gpc Off

Du kannst dich aber wenn du möchtest an dem Verzeichnis "start-navi" im Root vergehen. :) Derzeit zum killen freigegeben. :)

[1] Noch ca. 90, dann hab ich sie. :)
Schaffst Du in 2 Monaten ;)

Ich bleib am Ball. :)

grüße

[Patrick Andrieu]

Hallo Malcolm!

Du kannst dich aber wenn du möchtest an dem Verzeichnis "start-navi" im Root vergehen. :) Derzeit zum killen freigegeben. :)

Danke, aber ich habe selbst einen VHost zum austoben. Bevor ich bei Dir alles kaputt mache, mache ich es eben nicht bei mir ;)

Ich bleib am Ball. :)

EM der Domainbelegung?

Viele Grüße aus Frankfurt/Main,
Patrick

[Malcolm Beck´s]

hi,

Danke, aber ich habe selbst einen VHost zum austoben. Bevor ich bei Dir alles kaputt mache, mache ich es eben nicht bei mir ;)

Kaputtmachen macht Spass.

Ich bleib am Ball. :)
EM der Domainbelegung?

Noch EM, bald gehe ich auf .com TLD los, dann wird es zur WM. :)

grüße

[Cybaer]

Hi,

if(get_magic_quotes_gpc())
die sind leider auf Deinem Webspace on - würde ich ändern.

Warum? Ich finde das ist schon sinnvoll - alleine für unbedachte PHP-Coder gegen XSS.

Und stören tut's auch nicht (jedenfalls nicht mich).

Gruß, Cybaer

[Ingo Turski]

Hi,

if(get_magic_quotes_gpc())
die sind leider auf Deinem Webspace on - würde ich ändern.

Warum? Ich finde das ist schon sinnvoll - alleine für unbedachte PHP-Coder gegen XSS.

hauptsächlich aus zwei Gründen:
1. weil diese Funktion deprecated ist und künftig entfernt wird und auch bei einem Providerwechsel evtl. deaktiviert sein kann. Sich darauf zu verlassen, ist blauäugig und hilft gerade Anfängern in keiner Weise dabei, sichere Scripts zu erstellen, sondern veranlasst sie eher, sich über Sicherheitsaspekte erst gar keine Gedanken zu machen.
2. weil ich es unsinnig finde, Userdaten erst zu maskieren und dies dann wieder rückgängig zu machen.

Und stören tut's auch nicht (jedenfalls nicht mich).

noch nicht... siehe auch http://en.wikipedia.org/wiki/Magic_quotes

freundliche Grüße
Ingo

[Cybaer]

Hi,

1. weil diese Funktion deprecated ist und künftig entfernt wird und auch bei einem Providerwechsel evtl. deaktiviert sein kann. Sich darauf zu verlassen, ist blauäugig

Sicher. Deswegen verläßt "man" sich ja auch nicht drauf, sondern fragt das vorher ab. Wie immer (jedenfalls sollte es immer so sein - wenn nicht, ist das IMHO ein grundlegender Wissensmangel und keiner, der nur magic_quotes betrifft!).

Die Funktion, mit der ich meine Parameterdaten hole, macht das z.B. en passant mit.

und hilft gerade Anfängern in keiner Weise dabei, sichere Scripts zu erstellen,

Durch das Quoten von Anführungszeichen strandet per se schon so manche XSS-Attacke.

sondern veranlasst sie eher, sich über Sicherheitsaspekte erst gar keine Gedanken zu machen.

Na ja. Ich sehe das nicht als sicherheitsrelevante Funktionalität an. Wer sich um Sicherheit Gedanken macht, wir auch zu XSS kommen. Wer das nicht tut (und das ist nunmal leider weit verbreitet), ist damit "im Schlaf" wenigstens zu ein bißchen mehr Sicherheit gekommen.

2. weil ich es unsinnig finde, Userdaten erst zu maskieren und dies dann wieder rückgängig zu machen.

Wer's nicht mag (mir ist es aus genannten Gründen ohenhin egal), der schaltet's halt ab.

Und stören tut's auch nicht (jedenfalls nicht mich).
noch nicht... siehe auch http://en.wikipedia.org/wiki/Magic_quotes

Danke, ich weiß. Es wird mich auch in Zukunft nicht stören (s.o.). =:-)

Gruß, Cybaer

[Malcolm Beck´s]

hi,

hab das Script endlich soweit fertig, hat sicherlich noch hier und da ein Paar Macken aber das passt schon.
Für interessenten, http://start-navi.de/beispiele/kontakt.php, und der Grauenhafte Sourcecode, vorher aber anschnallen!
http://start-navi.de/beispiele/kontakt.txt

Vielleicht hat ja jemand lust und schaut sich das ding mal an und kann mir berichten wo es bedenken geben könnte.

Werde natürlich von Zeit zu Zeit versuchen das Script zu optimieren, aber vorerst reicht mir das für meine belange.

Danke jedenfalls an alle beteiligten!

grüße

[Tom]

Hello,

Für interessenten, http://start-navi.de/beispiele/kontakt.php, und der Grauenhafte Sourcecode, vorher aber anschnallen!
http://start-navi.de/beispiele/kontakt.txt

Vielleicht hat ja jemand lust und schaut sich das ding mal an und kann mir berichten wo es bedenken geben könnte.

Sieht aus, wie eine abendfüllende Beschäftigung.
Das wäre doch was, wenn ich ab 16.06. in Dortmund gastieren würde *gg*

Ein harzliches Glückauf

Tom vom Berg

[Malcolm Beck´s]

hi,

Sieht aus, wie eine abendfüllende Beschäftigung.
Das wäre doch was, wenn ich ab 16.06. in Dortmund gastieren würde *gg*

Hast du denn schon was gefunden?

Meine Türen stehen jedenfalls weit offen für dich. :)

grüße

[Tom]

Hello,

Hast du denn schon was gefunden?

Meine Türen stehen jedenfalls weit offen für dich. :)

Ja, gefunden habe ich was. Entscheidungstermin ist morgen.
Schaun wir mal, ob es klappt.

Ein harzliches Glückauf

Tom vom Berg

[Malcolm Beck´s]

hi,

Ja, gefunden habe ich was. Entscheidungstermin ist morgen.
Schaun wir mal, ob es klappt.

Dann drück ich dir mal die Daumen.
Was für ein Lehrgang willst du besuchen?

grüße

[Ingo Turski]

Hi,

Vielleicht hat ja jemand lust und schaut sich das ding mal an und kann mir berichten wo es bedenken geben könnte.

ich sehe da noch viel Redundantes, das über eine Funktion vereinfacht werden könnte, z.B. die Prüfungen auf leere Pflichtfelder und das Umkopieren der POST-Eingaben.

Die Email-Validierung ist Murks - altertümlich und lässt gültige Adressen nicht durch.
Ich habe hierzu nur eine Minimalprüfung:

function tsCheckEmail($adr) {  
  $regEx = '^([^\s@,:"<>]+)@([^\s@,:"<>]+\.[^\s@,:"<>.\d]{2,}|(\d{1,3}\.){3}\d{1,3})$';  
  return (preg_match("/$regEx/",$adr,$part)) ? $part : false;  
}  
# if($tsPart=tsCheckEmail($tsAdr)) { $tsMail=$tsPart[1]; $tsDomain=$tsPart[2]; }

Die Telefon- Telefax- und Mobilprüfungen sind ebenfalls Murks (und redundant). Ich habe hierfür erst kürzlich folgendes programmiert (sollte die gültigen bzw. normierten Angaben eigentlich alle berücksichtigen:

function tsCheckPhone($tel) {  
  $regEx = '^((\+[0-9]{2,4}( [0-9]+? | ?\([0-9]+?\) ?))|(\(0[0-9 ]+?\) ?)|(0[0-9]+?( |-|\/)))[0-9]+?[0-9 \-\/]*$';  
  return preg_match("/$regEx/",$tel);  
}

Anmerkung: der Kunde wollte dann auch noch reine Ziffernfolgen akzeptiert haben, so dass meine Abfrage dann letztlich so aussah:

  if(in_array($key, $tsForm['Telefon']) && $val!=='' && !tsCheckPhone($val) && !preg_match("/^0[0-9]{7,21}$/",$val)) tsAddError('Unerwartetes Nummernformat im Feld "'.$key.'"');  

also der letzte preg_match auf 0 mit 7-21 folgenden Ziffern hinzugekommen ist.

Der PHP-Code in den HTML-Ausgaben sowie das HTML selbst ist unsauber - Du solltest Dich besonders an das EVA-Prinzip halten. Vergleiche Deinen Code:

if ((isset($_POST['Email'])) AND (empty($_POST['Email']))) {  
}  
 elseif ($email_check == "false") {  
 echo '<li><em class="required">Email</em>:<span class="required"> '.(str_replace( "\\", "", htmlspecialchars($email_value))).'</span></li>'."\n";  
}  
 else {  
echo '<li><em>Email</em>: '.(str_replace( "\\", "", htmlspecialchars($email_value))).'</li>'."\n";  
}

mit diesem:

<p><label for="E-Mail">E-Mail Adresse:</label>  
  <input id="E-Mail" <?php tsInput("E-Mail"); ?> />  
</p>

Die dazugehörige Funktion ist eine universelle:

function tsInput($field,$def='') {  
  echo 'name="',$field,'" value="';  
  if(isset($_POST[$field]) && $_POST[$field]!=='') echo str_replace('"','"',htmlspecialchars($_POST[$field]));  
  elseif($def) echo str_replace('"','"',htmlspecialchars($def));  
  echo '"';  
}

Interessant finde ich:
<p style="display: none;"><label>Homepage</label><input type="text" name="Homepage" value="" /></p>.
Abgesehen davon, dass "Homepage" meiner Erfahrung nach am ehesten von Spam-Bots links liegen gelassen wird, würde ich als Bot bei "display: none;" und plötzlich semantisch korrekter Nutzung von <label> vielleicht doch misstrauisch...

freundliche Grüße
Ingo

[Malcolm Beck´s]

hi,

ich sehe da noch viel Redundantes, das über eine Funktion vereinfacht werden könnte, z.B. die Prüfungen auf leere Pflichtfelder und das Umkopieren der POST-Eingaben.

Ich weiss nicht wie ich anders die Vorschau bauen kann. Ich brauch die POST Daten ja mehrfach, der einfachste Weg ist für mich die in einer Variablen zu haben.

Die Email-Validierung ist Murks - altertümlich und lässt gültige Adressen nicht durch.
Ich habe hierzu nur eine Minimalprüfung:

function tsCheckEmail($adr) {

$regEx = '^([^\s@,:"<>]+)@([^\s@,:"<>]+.[^\s@,:"<>.\d]{2,}|(\d{1,3}.){3}\d{1,3})$';
  return (preg_match("/$regEx/",$adr,$part)) ? $part : false;
}

if($tsPart=tsCheckEmail($tsAdr)) { $tsMail=$tsPart[1]; $tsDomain=$tsPart[2]; }

  
Kannst du mir bitte DAU sicher verraten, wie man das in eine abfrage packt.  
Am besten in Kombination mit tsInput, das mit tsInput habe ich verstanden.  
  

> Anmerkung: der Kunde wollte dann auch noch reine Ziffernfolgen akzeptiert haben, so dass meine Abfrage dann letztlich so aussah:  
> ~~~php

  if(in_array($key, $tsForm['Telefon']) && $val!=='' && !tsCheckPhone($val) && !preg_match("/^0[0-9]{7,21}$/",$val)) tsAddError('Unerwartetes Nummernformat im Feld "'.$key.'"');  

> 

also der letzte preg_match auf 0 mit 7-21 folgenden Ziffern hinzugekommen ist.

Auch hier versteh ich nicht wie man das integrieren kann.

mit diesem:

<p><label for="E-Mail">E-Mail Adresse:</label>

<input id="E-Mail" <?php tsInput("E-Mail"); ?> />
</p>

> Die dazugehörige Funktion ist eine universelle:  
> ~~~php

function tsInput($field,$def='') {  

>   echo 'name="',$field,'" value="';  
>   if(isset($_POST[$field]) && $_POST[$field]!=='') echo str_replace('"','"',htmlspecialchars($_POST[$field]));  
>   elseif($def) echo str_replace('"','"',htmlspecialchars($def));  
>   echo '"';  
> }

Eins weiss ich jetzt, ich werde mich jetzt erstmal auf ein Tutorial stürzen und lernen, wie man Funktionen baut. :)
Was ich hier aber nicht versteh, warum ersetzt du " mit &quot;?

str_replace('"','&quot;',htmlspecialchars($_POST[$field]));

Das macht doch htmlspecialchars.

Abgesehen davon, dass "Homepage" meiner Erfahrung nach am ehesten von Spam-Bots links liegen gelassen wird, würde ich als Bot bei "display: none;" und plötzlich semantisch korrekter Nutzung von <label> vielleicht doch misstrauisch...

Ja, das ist mir auch später durch den Kopf gegenagen, das muss ich noch überarbeiten.

Danke für die Mühen.

grüße

[Ingo Turski]

Hi,

if($tsPart=tsCheckEmail($tsAdr)) { $tsMail=$tsPart[1]; $tsDomain=$tsPart[2]; }[/code]

Kannst du mir bitte DAU sicher verraten, wie man das in eine abfrage packt.

eine Beispielabfrage ist doch hier. bzw. if(!$tsPart=tsCheckEmail($tsAdr)) Fehler();

Was ich hier aber nicht versteh, warum ersetzt du " mit &quot;?

str_replace('"','&quot;',htmlspecialchars($_POST[$field]));

Das macht doch htmlspecialchars.

stimmt, gut erkannt. Das ist ein überflüssiges Überbleibsel.

freundliche Grüße
Ingo

[Malcolm Beck´s]

hi,

eine Beispielabfrage ist doch hier. bzw. if(!$tsPart=tsCheckEmail($tsAdr)) Fehler();

Das krieg ich nicht hin, dafür habe ich aber meine erste Funktion gebaut. :)
Ich hab mich erstmal um ein Pflichtfeld gekümmert, werde das ganze gleich  mal ausbauen.

<?php  
  
function tspflichtInput($pflicht_feld,$input_alert='style="border-color: #F00;"') {  
 echo "<label for=\"$pflicht_feld\">$pflicht_feld</label>  
<input type=\"text\" name=\"$pflicht_feld\" id=\"$pflicht_feld\" class=\"input_text_klasse\" ";  
  
  if(isset($_POST[$pflicht_feld]) && $_POST[$pflicht_feld]!=='')  
 echo 'value="'.str_replace('\\','',htmlspecialchars($_POST[$pflicht_feld])).'"';  
  
  elseif(isset($_POST[$pflicht_feld]) && $_POST[$pflicht_feld]=='')  
 echo  'value="'.str_replace('\\','',htmlspecialchars($_POST[$pflicht_feld])).'" '.$input_alert;  
  
 echo ' />';  
}  
  
 tspflichtInput("Name");  
 tspflichtInput("Email");  
?>

Ich weiß, ich vermische Code mit HTML aber das reicht mir erstmal so als Grundlage.

Wie ist denn der Ansatz, wie würdet ihr es machen?

Und die Email validieren Geschichte, da werde ich wohl at sein Einwand berücksichtigen und einfach lassen.

grüße

[Malcolm Beck´s]

hi,

warum bin ich erst so spät auf Funktionen gekommen? Die sind ja voll Fett!
Ich hab sogar die <select> in eine Funktion verpackt bekommen.
Da dürften Radio und Checkboxen ja kein Problem sein.

http://start-navi.de/beispiele/kontakt-funktion.php
http://start-navi.de/beispiele/kontakt-funktion.txt

könntest du bitte nochmal so ne Attacke auf den Server starten?

grüße

[Tom]

Hello,

function tspflichtInput($pflicht_feld, $input_alert='style="border-color: #F00;"')
{
   echo "<label for="$pflicht_feld">$pflicht_feld</label>".
        "    <input type="text" name="$pflicht_feld" id="$pflicht_feld" class="input_text_klasse" ";

if(isset($_POST[$pflicht_feld]) && $_POST[$pflicht_feld]!=='')
echo 'value="'.str_replace('\','',htmlspecialchars($_POST[$pflicht_feld])).'"';

Du bringst da "Schutzfunktionen" (mygic_quotes), Datenübernahme und Datenvorbereitung für einen bestimmten Ausgabekontext und den Style für Ausgabe in einer Funktion unter. Das ist nicht sehr prakrisch.

Außerdem, was machst Du, wenn die Funktion mal auf einem Server laufen soll, der keine magic_quotes mehr benutzt?

Trenne die Datenhaltung im Script von den Metadaten (wie soll angezeigt werden, sind die daten valide) und der Ausgabeformatierung.

Am Anfang eines Scriptes könnte zum Beispiel die Hilfsfunktion

#--------------------------------------------------------------------

Rekursive Entfernung der Maskierungs-Backslashes aus Arrays

function strip($data)
{
    if (!get_magic_quotes_gpc())
    {
        return $data;
    }

if (is_array($data))
    {
        foreach($data as $key => $val)
        {
            $data[$key] = strip($val);
        }
    }
    else
    {
        $data = stripslashes($data);
    }

return $data;
}
#-------------------------------------------------------------------------

Ein harzliches Glückauf

Tom vom Berg

[Malcolm Beck´s]

hi,

Du bringst da "Schutzfunktionen" (mygic_quotes), Datenübernahme und Datenvorbereitung für einen bestimmten Ausgabekontext und den Style für Ausgabe in einer Funktion unter. Das ist nicht sehr prakrisch.

Ja, ich weiss, ich hab erst grade gelernt, wie man Funktionen baut, gib mir 1-2 Tage. :)

Außerdem, was machst Du, wenn die Funktion mal auf einem Server laufen soll, der keine magic_quotes mehr benutzt?

Mein Code ändern, noch ist der Ja übersichtlich.

Am Anfang eines Scriptes könnte zum Beispiel die Hilfsfunktion

#--------------------------------------------------------------------

Rekursive Entfernung der Maskierungs-Backslashes aus Arrays

function strip($data)
{
    if (!get_magic_quotes_gpc())
    {
        return $data;
    }

if (is_array($data))
    {
        foreach($data as $key => $val)
        {
            $data[$key] = strip($val);
        }
    }
    else
    {
        $data = stripslashes($data);
    }

return $data;
}
#-------------------------------------------------------------------------

Muss ich hierbei irgendwas beachten, bei mir funktioniert das nicht.
Das erste Eingabefeld, Unternehmen

Funktionsaufruf

function tsInput($feld) {  
 echo "<label for=\"$feld\">$feld</label><input type=\"text\" name=\"$feld\" id=\"$feld\" class=\"input_text_klasse\" ";  
  if(isset($_POST[$feld]) && $_POST[$feld]!=='')  
 echo 'value="'.htmlspecialchars($_POST[$feld]).'"';  
  elseif(isset($_POST[$feld]) && $_POST[$feld]=='')  
 echo  'value="'.htmlspecialchars($_POST[$feld]).'" ';  
 echo ' />';  
}

grüße

[Malcolm Beck´s]

hi,

nach mehr stündigem basteln Qualmt mir der Kopf, ich hab 4 Funktionen, aus einer Funktion möchte ich die $_POST Variable auf true/false, je nach Ergebnis setzen, ich steig da aber nicht durch, wie kann ich da vorgehen? Den &$Operator hab ich schon gefunden aber ich kapier das nicht, was muss ich hier machen?

function tsPflichtInput($pflicht_feld,$input_alert='style="border-color: #F00;"') {  
 echo "  
<label for=\"$pflicht_feld\">$pflicht_feld  <span class=\"required\">*</span></label>  
<input type=\"text\" name=\"$pflicht_feld\" id=\"$pflicht_feld\" class=\"input_text_klasse\" ";  
  
  if(isset($_POST[$pflicht_feld]) && $_POST[$pflicht_feld]!=='')  
 echo '  
value="'.str_replace('\\','',htmlspecialchars($_POST[$pflicht_feld])).'"';  
  
  elseif(isset($_POST[$pflicht_feld]) && $_POST[$pflicht_feld]=='')  
 echo  '  
value="'.str_replace('\\','',htmlspecialchars($_POST[$pflicht_feld])).'" '." $input_alert";  
  
 echo ' />';  
}

Derzeitiger Stand:
http://start-navi.de/beispiele/kontakt-3.php
http://start-navi.de/beispiele/kontakt-c.txt

Ziel ist, das bei korrekten Eingaben in die Textfelder der Absende Button angezeigt wird.

grüße