Ingolf: Missbrauch von Formularen zum Spam-Versand

Hi,
hat jemand Erfahrung mit der 'Sichermachung von Formularen ?
Woran liegt es, dass diese immer wieder mißbraucht werden können oder anders gefragt: Worauf ist zu achten bei der Verwendung eines Formmailers (die ja zahlreich angeboten werden).
Was ich bisher werfahren konnte, ist dass Javascript-Prüfungen offenbar so durchlässig sind wie Schweizer Käse! Wenn man die Felder aber in dem gerufenen CGI (Perl-Script) prüft, kann da noch etwas passieren ?

PS: Ob der Beitrag hierher gehört, weiß ich leider nicht. Ich hätte ihn lieber unter einem Kapitel wie 'Internet-Sicherheit' untergebracht.

  1. Hi,

    die ersten Dinge die mir einfallen:

    1.) Der Empfänger muss fest sein. Am besten in einem Config-File oder im Script selber. Auf keinen fall darf er von der Nutzerseite übermittelt werden (zum Beispiel per "hidden"-field). Also alles was die Empfänger-Mailadresse im HTML Quelltext hat ist schonmal hoch gefährdet

    2.) Die Eingaben müssen anständig geprüft werden. Vor allem darf es nicht passieren, das ein Benutzer durch unerwartete Eingaben irgendwelche Informationen in die erweiterten Header schummeln kann. Klassischer Fall hier wäre zum Beispiel: Benutzer darf Absender angeben und kann mangels unzureichender Prüfung auch noch ein BCC: Feld unterbringen.

    Das sind die beiden Dinge, die mir einfallen.

    Grüße

    Marc

    1. Hi,

      die ersten Dinge die mir einfallen:
      Klassischer Fall hier wäre zum Beispiel: Benutzer darf Absender »» »» angeben und kann mangels unzureichender Prüfung auch noch ein BCC: »» Feld unterbringen.

      Oh, das klingt interessant. Wüde ich ein Formular einsetzen, wäre es sicherlich sinnvoll dem Sender die Möglichkeit zu geben, seine Adresse anzugeben. Wie sonst könnte ich antworten?
      Wie könnte dieser denn ein BCC Feld einschmuggeln?
      Wäre eine dem entgegenwirkende Maßnahme, wenn man z. B. in PHP eine Funktion wie diese auf die Eingaben anwendet:

        
      function kodiere_postdaten() {  
              foreach ($_POST as $key => $wert) {  
                  $_POST[$key] = (stripslashes(htmlentities($_POST[$key])));  
              }  
      }  
      
      ~~~ ?  
        
      Grüße  
      ^da Powl
      
      1. Hallo Powl.

        Wie könnte dieser denn ein BCC Feld einschmuggeln?

        Zum Beispiel indem er in ein kritisches Formularfeld die Zeichenkette „\r\nBCC: spam-me@example.org, etc“ einfügt. (\r\n ist der Terminator für Mailheader) Dass ein solches Formularfeld normalerweise einzeilig ist, ist hierbei kein Hindernis. Selbst per JS kann man ganz leicht in ein solches Formularfeld beliebig Zeilenumbrüche einfügen.

        Deswegen habe ich in den Formmailer meines Impressums auch eine Prüfung auf „\r\n“ und sicherheitshalber auch „\n“ bei allen Formularfeldern eingefügt, welche keine Textarea sind.

        Wäre eine dem entgegenwirkende Maßnahme, wenn man z. B. in PHP eine Funktion wie diese auf die Eingaben anwendet:
        […]

        Höchstens für die Anzeige der Mail.

        Einen schönen Samstag noch.

        Gruß, Ashura

        --
        sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
        „It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
        [HTML Design Constraints: Logical Markup]
        1. Hi,

          ich glaube ich verstehe etwas nicht. Wenn die Postdaten mittels stripslashes "bearbeitet" werden, wird dann aus \r\n nicht automatisch
          rn?
          Das wäre dann doch harmlos, oder?
          Wieso müßte man dann noch wie Du es machst alle einzeiligen input's auf \r\n prüfen?
          Könnte man nicht auch mittels preg- oder string replace "\r\nBCC" durch "" ersetzen und gut ist's?
          Außerdem, bei Eingabe eines BCC in eine Textarea- damit könnte man nicht spammen? Wieso nicht?

          danke für Deine Antwort

          ^da Powl

          1. Hallo Powl.

            ich glaube ich verstehe etwas nicht. Wenn die Postdaten mittels stripslashes "bearbeitet" werden, wird dann aus \r\n nicht automatisch
            rn?
            Das wäre dann doch harmlos, oder?

            Gut, ist möglich. Ich habe weder addslashes noch stripslashes bisher jemals gebraucht.

            Wieso müßte man dann noch wie Du es machst alle einzeiligen input's auf \r\n prüfen?
            Könnte man nicht auch mittels preg- oder string replace "\r\nBCC" durch "" ersetzen und gut ist's?

            Viele Wege führen nach Rom. Ich habe mich für den beschriebenen entschieden.

            Außerdem, bei Eingabe eines BCC in eine Textarea- damit könnte man nicht spammen? Wieso nicht?

            Deshalb.

            Einen schönen Samstag noch.

            Gruß, Ashura

            --
            sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
            „It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
            [HTML Design Constraints: Logical Markup]
            1. Hallo Gunnar™.

              ich glaube ich verstehe etwas nicht. Wenn die Postdaten mittels stripslashes "bearbeitet" werden, wird dann aus \r\n nicht automatisch
              rn?
              Das wäre dann doch harmlos, oder?

              Gut, ist möglich. Ich habe weder addslashes noch stripslashes bisher jemals gebraucht.

              … und muss deshalb erst einmal ausprobieren was eigentlich logisch ist:

              Nein, stripslashes entfernt nur das tatsächliche ASCII-Zeichen „\“, Steuerzeichen wie CR (\r) und LF (\n) werden nicht angerührt.

              Einen schönen Samstag noch.

              Gruß, Ashura

              --
              sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
              „It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
              [HTML Design Constraints: Logical Markup]
              1. Hallo Gunnar™.

                Nein, stripslashes entfernt nur das tatsächliche ASCII-Zeichen „\“, Steuerzeichen wie CR (\r) und LF (\n) werden nicht angerührt.

                Ich habe das mal lokal ausprobiert, kann es aber leider nicht online uppen [irgendwann besorge ich mir mal webspace zum daddeln ;) ].
                Wenn in ein input "\r\nBCC bla@bla.bla" eingegeben wird, liegen diese Zeichen im $_POST['wasimmer'] string doch als ASCII Zeichen vor, oder liege ich falsch.
                Mittels stripslashes werden die "" Backslashes entfernt, und der String $_POST['wasimmer'] enthält nur noch "rnBCC bla@bla.bla".
                Sofern ich nicht irgendwas übersehen habe, sollte das seinen Zweck erfüllen, oder vertehe ich da etwas falsch?

                Grüße
                ^da Powl

                1. Hiho,

                  Sofern ich nicht irgendwas übersehen habe, sollte das seinen Zweck erfüllen, oder vertehe ich da etwas falsch?

                  wie ich schon gesagt habe: was ist mit \r\n?

                  Grüße

                  Marc

                  1. Hiho,

                    Nachtrag. Kurzer Blick auf php.net hätte dir gezeigt, dass du auf dem verkehrten weg bist:

                    string stripslashes ( string str )

                    Returns a string with backslashes stripped off. (' becomes ' and so on.) Double backslashes (\) are made into a single backslash ().

                    Also definitiv nicht das richtige für dich!

                    Marc

                  2. Hallo AllesMeins.

                    Sofern ich nicht irgendwas übersehen habe, sollte das seinen Zweck erfüllen, oder vertehe ich da etwas falsch?

                    wie ich schon gesagt habe: was ist mit \r\n?

                    Das wird zu „rn“, wohingegen „\\r\\n“ zu einem Zeilenumbruch wird.

                    Einen schönen Samstag noch.

                    Gruß, Ashura

                    --
                    sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
                    „It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
                    [HTML Design Constraints: Logical Markup]
                    1. Hiho,

                      Das wird zu „rn“, wohingegen „\\r\\n“ zu einem Zeilenumbruch wird.

                      hab ich auch gerade festgestellt. Das widerspricht aber der Dokumentation, wonach \ zu einem \ werden sollte. Oder verstehe ich das falsch?

                      Marc

                      1. Hallo AllesMeins.

                        Das wird zu „rn“, wohingegen „\\r\\n“ zu einem Zeilenumbruch wird.

                        hab ich auch gerade festgestellt. Das widerspricht aber der Dokumentation, wonach \ zu einem \ werden sollte. Oder verstehe ich das falsch?

                        Ich könnte mir höchstens vorstellen, dass stripslashes von rechts nach links arbeitet, also würde aus „\r“ „r“ und aus „\“ „\“, woraus zusammengesetzt wiederum „\r“ würde.

                        Einen schönen Samstag noch.

                        Gruß, Ashura

                        --
                        sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
                        „It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
                        [HTML Design Constraints: Logical Markup]
                        1. Hallo Gunnar™.

                          Ich könnte mir höchstens vorstellen, dass stripslashes von rechts nach links arbeitet, also würde aus „\r“ „r“ und aus „\“ „\“, woraus zusammengesetzt wiederum „\r“ würde.

                          Wobei die Richtung eigentlich egal ist, das Resultat ist immer dasselbe.

                          Und bevor ich noch mehr Ingr^WGunnar-Postings absetze, lege ich mich lieber schlafen.

                          Eine schöne Samstagnacht noch.

                          Gruß, Ashura

                          --
                          sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
                          „It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
                          [HTML Design Constraints: Logical Markup]
                        2. Hiho,

                          probier mal ein "echo stripslashes('Hallo \ Hallo');" Daraus wird ein "Hallo  Hallo". Also irgendwie widerspricht das doch ganz deutlich dem beschriebenen verhalten der Funktion...

                          Marc

                          1. Hallo,

                            probier mal ein "echo stripslashes('Hallo \ Hallo');" Daraus wird ein "Hallo  Hallo". Also irgendwie widerspricht das doch ganz deutlich dem beschriebenen verhalten der Funktion...

                            Ja, aber nur innerhalb eines von PHP erzeugten Strings. Offensichtlich werden die "magic quotes" da bereits bei der Stringerzeugung berücksichtigt und das Zeichen "" kommt überhaupt nur in den String, wenn es keinerlei Maskierungsfunktion mehr haben kann. Das ist beim String $myString='O'reilly'; auch logisch. Was sollte das Zeichen "" da im String.

                            In anderen Fällen, wenn z.B. Daten aus einem Formular übernommen werden und da wirklich URL-encodiert das Zeichen "" mit übergeben wird oder magic_quotes da eventuell das Zeichen "" hinenschreibt, dann stimmt die Beschreibung schon.

                            Hier mal ein Testcase, welcher auch zeigt, dass stripslashes _wirklich_ keine Zeilenumbrüche entfernt, sondern eben nur das Zeichen "".

                              
                            <?php  
                            header("Content-Type: text/html; charset=ISO-8859-1");  
                              
                            function strip_CRLF_LF_CR($myString) {  
                              $myString = str_replace("\r\n", '', $myString);  
                              $myString = str_replace("\n", '', $myString);  
                              $myString = str_replace("\r", '', $myString);  
                              return $myString;  
                            }  
                              
                            echo '<pre>'.var_dump('O\'reilly\Test').'</pre>';  
                            echo '<pre>'.var_dump(stripslashes('O\'reilly\Test')).'</pre><hr>';  
                              
                            echo '<pre>'.var_dump('O\'reilly\\Test').'</pre>';  
                            echo '<pre>'.var_dump(stripslashes('O\'reilly\\Test')).'</pre><hr>';  
                              
                            echo '<pre>'.var_dump('O\'reilly\\\Test').'</pre>';  
                            echo '<pre>'.var_dump(stripslashes('O\'reilly\\\Test')).'</pre><hr>';  
                              
                            if (isset($_POST['textfeld'])) {  
                              $myString = $_POST['textfeld'];  
                              echo '<pre>'.$myString.'</pre><hr>';  
                              echo '<pre>'.stripslashes($myString).'</pre><hr>';  
                              echo '<pre>'.strip_CRLF_LF_CR($myString).'</pre><hr>';  
                              echo '<pre>'.stripslashes(strip_CRLF_LF_CR($myString)).'</pre><hr>';  
                            }  
                            ?>  
                            <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="POST">  
                            <textarea name="textfeld" cols="20" rows="5">  
                            O'reilly\r\nTest  
                            O'reilly\\r\\nTest  
                              
                            Test  
                            </textarea>  
                            <input type="Submit" name="ok" value="OK">  
                            </form>  
                            
                            

                            viele Grüße

                            Axel

                            1. Moin!

                              Offensichtlich werden die "magic quotes" da bereits bei der Stringerzeugung berücksichtigt und das Zeichen "" kommt überhaupt nur in den String, wenn es keinerlei Maskierungsfunktion mehr haben kann.

                              Nein, mit magic quotes hat das absolut nichts zu tun!

                              Das ist beim String $myString='O'reilly'; auch logisch. Was sollte das Zeichen "" da im String.

                              Das Zeichen ist das Escape-Zeichen, damit das nachfolgende ' seiner Sonderfunktion "String hier zu Ende" beraubt wird.

                              - Sven Rautenberg

                              --
                              My sssignature, my preciousssss!
                              1. Hallo,

                                Offensichtlich werden die "magic quotes" da bereits bei der Stringerzeugung berücksichtigt und das Zeichen "" kommt überhaupt nur in den String, wenn es keinerlei Maskierungsfunktion mehr haben kann.
                                Nein, mit magic quotes hat das absolut nichts zu tun!

                                Doch, schon. Das Zeichen "" wird ja auch von magic_quotes_gpc benutzt, um spezielle Zeichen zu maskieren. Ja, es war unglücklich formuliert. Was ich meinte war etwas Ähnliches, wie Du in Deiner Erklärung, nämlich, dass das, was für 'O'reilly' gilt, natürlich auch für 'O\reilly' gelten muss. Deine Erklärung ist aber wirklich logischer.

                                Das ist beim String $myString='O'reilly'; auch logisch. Was sollte das Zeichen "" da im String.
                                Das Zeichen ist das Escape-Zeichen, damit das nachfolgende ' seiner Sonderfunktion "String hier zu Ende" beraubt wird.

                                Ach was! Danke für die Erklärung. Das wusste ich noch gar nicht. ;-)

                                viele Grüße

                                Axel

                          2. Moin!

                            probier mal ein "echo stripslashes('Hallo \ Hallo');" Daraus wird ein "Hallo  Hallo". Also irgendwie widerspricht das doch ganz deutlich dem beschriebenen verhalten der Funktion...

                            Doch, alles ist perfekt.

                            Die Stringangabe ist
                            'Hallo \ Hallo'

                            Das wird intern umgesetzt in den String
                            Hallo \ Hallo

                            Da ja auch in einfachen Anführungszeichen einfache Anführungszeichen eingebbar sind, die mit Backslash escaped werden, muß auch der Backslash escapebar sein - und das wird dir hier zum Verhängnis. Im String stehen deshalb keine zwei Backslashes, sondern nur einer.

                            Der String mit dem einfachen Backslash geht dann in die stripslashes-Funktion rein, und dort wird dieser folgerichtig entfernt.

                            - Sven Rautenberg

                            --
                            My sssignature, my preciousssss!
                  3. Hi,

                    Sofern ich nicht irgendwas übersehen habe, sollte das seinen Zweck erfüllen, oder vertehe ich da etwas falsch?

                    wie ich schon gesagt habe: was ist mit \r\n?

                    Ja, ok. Nur warum sollte jemand diesen Term eingeben? Das würde doch nur Sinn machen, wenn er davon ausginge, daß mit stripslashes editiert wird. Ansonsten wäre eine solche Eingabe doch eher nutzlos.
                    Aber ich tendiere mittlerweile auch eher zu der Möglichkeit mittels preg_replace "\n" aus einzeiligen Eingabefeldern auszufiltern.

                    g N8

                    ^da Powl

                    1. Hallo Powl.

                      Aber ich tendiere mittlerweile auch eher zu der Möglichkeit mittels preg_replace "\n" aus einzeiligen Eingabefeldern auszufiltern.

                      Wenn, dann genügt hier str_replace vollkommen.

                      Und rein faktisch gesehen ist nur „\r\n“ relevant, da dies für einen standardkonformen MTA den Terminator für Mailheader darstellt.
                      Für defekte MTAs kann es aber nicht schaden, zusätzlich noch „\n“ hinzu zu nehmen.

                      Einen schönen Samstag noch.

                      Gruß, Ashura

                      --
                      sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
                      „It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
                      [HTML Design Constraints: Logical Markup]
                    2. Hi,

                      Ja, ok. Nur warum sollte jemand diesen Term eingeben? Das würde doch nur Sinn machen, wenn er davon ausginge, daß mit stripslashes editiert wird. Ansonsten wäre eine solche Eingabe doch eher nutzlos.

                      Spammer haben üblicherweise viel Zeit, sind weit weniger dumm als du denkst und wenig Probleme damit einfach erst mal (automatisiert) die üblichen fehler abzuklappern. Wenn du wüsstest, was bei meinem Mailformular schon alles an Testeingaben aufgeschlagen ist...

                      Man probiert halt einfach mal die üblichen fehler aus und versucht auf dem Weg eine Mail an die eigene Adresse zu leiten. Gelingt das, weiss der Spammer wie er dein Mailformular ausnutzen kann und setzt mal eben ein paar tausend Mails ab...

                      Marc

                2. Hallo Powl.

                  Wenn in ein input "\r\nBCC bla@bla.bla" eingegeben wird, liegen diese Zeichen im $_POST['wasimmer'] string doch als ASCII Zeichen vor, oder liege ich falsch.

                  Nein, da liegst du völlig richtig.

                  Mittels stripslashes werden die "" Backslashes entfernt, und der String $_POST['wasimmer'] enthält nur noch "rnBCC bla@bla.bla".
                  Sofern ich nicht irgendwas übersehen habe, sollte das seinen Zweck erfüllen, oder vertehe ich da etwas falsch?

                  Wie du selbst sagst, entfernst du hier lediglich die ASCII-Zeichen.
                  Der Wert „\r\nBCC …“ aus einem Eingabefeld enspricht tatsächlich dem, was eingegeben wird. Besagte Steuerzeichen hast du damit nicht eingefügt. Dafür könntest du bspw. folgendes in deiner Adresszeile ausführen:

                  javascript:document.getElementsByTagName('input')[0].value+="\r\nBCC: …";

                  Damit würdest du tatsächlich die Steuerzeichen für den Zeilenumbruch in das einzeilige Formularfeld einfügen. Sichtbar wird es aber höchstens als ein Leerzeichen. Wertest du diesen Wert nun serverseitig aus, wirst du sehen, dass nur bei letzterer Methode ein tatsächlicher Zeilenumbruch eingefügt wird, wohingegen bei der blanken Eingabe der ASCII-Zeichen nichts dergleichen bzw. wirklich nur die Zeichen selbst zu sehen ist.

                  PHP grast hier (glücklicherweise) nicht automatisch eingegebene Zeichen nach möglichen Steuerzeichen ab und erzeugt sie.

                  Die Eingabe der Steuerzeichen per maskierendem Backslash stellt lediglich eine Eingabevereinfachung dar, da es andernfalls so gut wie unmöglich wäre, Steuerzeichen einzugeben.

                  Einen schönen Samstag noch.

                  Gruß, Ashura

                  --
                  sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
                  „It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
                  [HTML Design Constraints: Logical Markup]
          2. Hiho,

            und was ist mit \r\n? Wenn ich mich erinnere ist stripslashes dazu da  die Slashes zu entfernen, die dazu dienten Sonderzeichen zu escapen. Ich kann mir aber gut vorstellen, das es so clever ist aus einem escapten backslash wieder einen backslash zu machen...

            Marc

          3. Moin!

            ich glaube ich verstehe etwas nicht. Wenn die Postdaten mittels stripslashes "bearbeitet" werden, wird dann aus \r\n nicht automatisch
            rn?

            Du bist hier, und nach dir auch alle anderen wie Ashura, AllesMeins, vollkommen auf dem falschen Dampfer.

            Die Schreibweise \r\n ist eine Ersatzschreibweise, um die zwei ASCII-Zeichen CR (Carriage Return, Bytewert 13) und LF (Linefeed, Bytewert 10) auf komfortable Weise in Programmcode in Strings integrieren zu können.

            Diese Schreibweise funktioniert nur direkt in den Skripten, also wenn du einen festen String im Code hast, der eines oder beide dieser zwei Zeichen ausgeben soll - beispielsweise, weil ein Zeilenumbruch gemeint ist.

            Der Parser übersetzt den String dann schon direkt in die zugehörigen Bytewerte.

            Und auch wenn Mailskripte angegriffen werden, werden direkt diese Bytewerte gesendet, und nicht die zwei Zeichen "Backslash" und "Buchstabe r" oder "Buchstabe n" - denn der Backslash wäre dann tatsächlich "Opfer" der addslashes-Operation.

            Deshalb gehen deine weiteren Vermutungen, und auch alle der ab diesem Zeitpunkt mitdiskutierenden Stammposter, leider vollkommen in die falsche Richtung, weil sie von Tatsachen ausgehen, die nicht stimmen.

            Wieso müßte man dann noch wie Du es machst alle einzeiligen input's auf \r\n prüfen?

            PHP und Perl wissen von irgendwelchen Formularfeldern nichts, wenn sie die GET-Parameter bzw. den POST-Body auseinandernehmen. Abgesehen davon kann man diesen auch durch eigene Skripte, die "passende" Daten senden, manipulieren. Der simpelste Trick wäre, einfach ein <input type="text"> durch eine Textarea zu ersetzen - und schon kann man mehrzeilige Absenderangaben sogar manuell im Browser ausprobieren und sehen, was passiert. Für die GET- oder POST-Daten ist das egal - die haben an den entsprechenden Stellen dann halt ein passendes Steuerzeichen (CR, LF, CR+LF) für "Zeilenumbruch" im String.

            Und weil das an der falschen Stelle gefährlich ist, muß man sicherstellen, dass es nicht durchflutscht.

            Könnte man nicht auch mittels preg- oder string replace "\r\nBCC" durch "" ersetzen und gut ist's?

            Es wäre sinnvoll, alle Vorkommen von CR und LF durch "nichts" zu ersetzen. Dann sind derartige Hinzufügungen ziemlich sicher ausgeschlossen. Allerdings kann man das nicht grundsätzlich für alle Formulardaten machen, da einige Textteile ja als "Text mit Zeilenumbrüchen" für den eigentlichen Mailtext vorgesehen sind - und auch unbearbeitet direkt übernommen werden dürfen, ohne Gefahr zu bergen.

            Außerdem, bei Eingabe eines BCC in eine Textarea- damit könnte man nicht spammen? Wieso nicht?

            Doch, kann man. Auf den Typ des Formularfeldes kommt es nicht an, das sind zur Verarbeitungszeit alles nur noch Strings mit Inhalt - und auf den Inhalt kommt es an.

            - Sven Rautenberg

            --
            My sssignature, my preciousssss!
            1. Hallo Sven.

              Du bist hier, und nach dir auch alle anderen wie Ashura, AllesMeins, vollkommen auf dem falschen Dampfer.

              Die Schreibweise \r\n ist eine Ersatzschreibweise, um die zwei ASCII-Zeichen CR (Carriage Return, Bytewert 13) und LF (Linefeed, Bytewert 10) auf komfortable Weise in Programmcode in Strings integrieren zu können.

              Öhm, das sagte ich doch bereits?

              Habe ich mich undeutlich ausgedrückt?

              Einen schönen Samstag noch.

              Gruß, Ashura

              --
              sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
              „It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
              [HTML Design Constraints: Logical Markup]
            2. Moin!

              Es wäre sinnvoll, alle Vorkommen von CR und LF durch "nichts" zu ersetzen.  ...

              Ok, aber die stehen ja wie gesagt dann nicht unbeingt als \r\n.
              Sollten sie gefiltert werden, wonach müßte PHP dann suchen?
              preg_match nach "CF" und "LF" suchen zu lassen geht denke ich nicht?!

              Ist sicherlich eine typische Anfängerfrage...

              Grüße
              ^da Powl

              1. Hallo Powl.

                Sollten sie gefiltert werden, wonach müßte PHP dann suchen?

                Wie bereits gesagt einfach nach "\r\n" in doppelten Anführungszeichen, damit sie als Steuerungszeichen erkannt werden.

                Oder alternativ nach chr(13).chr(10), was ebenfalls CR+LF entspricht.

                Ist sicherlich eine typische Anfängerfrage...

                Ganz und gar nicht, da hier schon ein wenig erweitertes Wissen rund um den Aufbau von Daten erforderlich ist.

                Einen schönen Samstag noch.

                Gruß, Ashura

                --
                sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
                „It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
                [HTML Design Constraints: Logical Markup]
                1. Hallo,

                  Sollten sie gefiltert werden, wonach müßte PHP dann suchen?

                  Wie bereits gesagt einfach nach "\r\n" in doppelten Anführungszeichen, damit sie als Steuerungszeichen erkannt werden.

                  Ich habe dazu eine ergänzende Frage:

                  In der mail()-Funktion bei PHP werden die additional headers im 4. Parameter angegeben. Reicht es aus, "\r\n" nur in den übergebenen Formularvariablen zu ersetzen, die in diesen 4. Parameter reinfließen? Oder kann ein Spammer auch ein Formularfeld für das Subject entsprechend modifizieren?

                  Viele Grüße
                  Frank

                  1. Hallo Frank.

                    In der mail()-Funktion bei PHP werden die additional headers im 4. Parameter angegeben. Reicht es aus, "\r\n" nur in den übergebenen Formularvariablen zu ersetzen, die in diesen 4. Parameter reinfließen? Oder kann ein Spammer auch ein Formularfeld für das Subject entsprechend modifizieren?

                    Wie dem PHP-internen Code in diesem Posting entnommen werden kann, ist der dritte Parameter der einzige, über den keine zusätzlichen Header eingeschmuggelt werden können. Bei allen anderen Parametern für die mail-Funktion ist dies also in der Tat möglich.

                    Da die zusätzlichen Header (vierter Parameter) normalerweise sowieso nicht vom Versendenden beeinflusst werden, bleiben also nur To (erster Parameter) und Subject (zweiter Parameter) als Einfallstor übrig.

                    Wie schon gesagt: eine chaotische Implementierung.

                    Einen schönen Samstag noch.

                    Gruß, Ashura

                    --
                    sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
                    „It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
                    [HTML Design Constraints: Logical Markup]
              2. Moin!

                Es wäre sinnvoll, alle Vorkommen von CR und LF durch "nichts" zu ersetzen.  ...

                Ok, aber die stehen ja wie gesagt dann nicht unbeingt als \r\n.

                Es ist in PHP definiert:

                Der String "\r" bzw. das Vorkommen von \r in einem String mit doppelten Anführungszeichen wird umgesetzt in einen String mit dem Byte 13(dezimal).

                Der String "\n" bzw. das Vorkommen von \n in einem String mit doppelten Anführungszeichen wird umgesetzt in einen String mit dem Byte 10(dezimal).

                Sollten sie gefiltert werden, wonach müßte PHP dann suchen?

                Da du die zwei Zeichen "direkt" in einem String angeben kannst, suchst du tatsächlich im PHP-Skript nach "\r" und "\n".

                Die Ersetzungsoperation würde beispielsweise so funktionieren:
                $gefiltert1 = str_replace("\r", "", $ungefiltert);
                $gefiltert2 = str_replace("\n", "", $gefiltert1);

                preg_match nach "CF" und "LF" suchen zu lassen geht denke ich nicht?!

                Doch, geht auch. Ist aber nicht so simpel einzugeben, weil die Backslashes und der reguläre Ausdruck ggf. doppelt escapet werden müssen. Es "sieht also nicht mehr so schön einfach aus".

                - Sven Rautenberg

                --
                My sssignature, my preciousssss!
        2. Hallo,

          Wie könnte dieser denn ein BCC Feld einschmuggeln?

          Zum Beispiel indem er in ein kritisches Formularfeld die Zeichenkette „\r\nBCC: spam-me@example.org, etc“ einfügt. (\r\n ist der Terminator für Mailheader)

          Die PHP- und Perl-Mail-Funktionen sind aber auch so was von lustlos programmiert. Das sieht man denen richtig an:

          bool mail ( string to, string subject, string message [, string additional_headers [, string additional_parameters]] )

          Da hat jemand gedacht: "Was brauch ich _unbedingt_ aus RFC 2822? TO, Subject, Message. Was, da gibts noch mehr? Das wird Sonstiges."

          Würde es für jedes Feld im Internet Message Format einen Parameter in den mail-Funktionen geben, wären diese lange nicht so unsicher und die Prüfung wäre weit einfacher.

          Oder gibts da mittlerweile schon bessere?

          viele Grüße

          Axel

          1. Hallo Axel.

            Da hat jemand gedacht: "Was brauch ich _unbedingt_ aus RFC 2822? TO, Subject, Message. Was, da gibts noch mehr? Das wird Sonstiges."

            Ja, über diese chaotische Implementation bin ich auch schon gestolpert.

            Würde es für jedes Feld im Internet Message Format einen Parameter in den mail-Funktionen geben, wären diese lange nicht so unsicher und die Prüfung wäre weit einfacher.

            Oder gibts da mittlerweile schon bessere?

            Ja: manchereiner schwört auf PEAR::Mail.

            Einen schönen Samstag noch.

            Gruß, Ashura

            --
            sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
            „It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.“
            [HTML Design Constraints: Logical Markup]
      2. Hallo.

        Wüde ich ein Formular einsetzen, wäre es sicherlich sinnvoll dem Sender die Möglichkeit zu geben, seine Adresse anzugeben. Wie sonst könnte ich antworten?

        Indem du dir eine Zielgruppe suchst, die eine Aufforderung wie "Bitte fügen Sie ihrem Text bei, unter welcher Kontaktadresse (E-Mail, Telefon etc.) und innerhalb welchen Zeitrahmens ich Sie am besten erreichen kann." versteht und ihr nachkommt.
        MfG, at

  2. hallo,

    Woran liegt es, dass diese immer wieder mißbraucht werden können oder anders gefragt: Worauf ist zu achten bei der Verwendung eines Formmailers (die ja zahlreich angeboten werden).

    In den letzten Wochen bzw. Monaten kommt dieses Thema hier immer wieder vor - in dere Regel in Verbindung mit PHP.

    Was ich bisher werfahren konnte, ist dass Javascript-Prüfungen offenbar so durchlässig sind wie Schweizer Käse!

    Sie sind vollkommen unwirksam, da die bots, die deinen mailer oder dein Gästebuch "mißbrauchen", ohne Javascript arbeiten.

    Wenn man die Felder aber in dem gerufenen CGI (Perl-Script) prüft, kann da noch etwas passieren ?

    Natürlich. Es kommt auf die "Prüfung" an. Im einzelnen wird mir dir erts genauer antworten können, wenn du dein Script bekanntgibst. Die derzeit hier am häufigaten geäußerte Maßnahme, wenigstens ansatzweise den "Mißbrauch" einzudämmen, betsht darin, daß die zwangsweise eine Vorschau einbaust, ehe dein Formular irgendwelche Daten absenden läßt. Das scheinen die bots zur Zeit noch nicht kapiert zu haben.

    PS: Ob der Beitrag hierher gehört, weiß ich leider nicht. Ich hätte ihn lieber unter einem Kapitel wie 'Internet-Sicherheit' untergebracht.

    Es ist tatsächlich kein spezielles Perl-Problem. Aber so ganz falsch ist deine Wahl nicht.

    Grüße aus Berlin

    Christoph S.

    --
    Visitenkarte
    ss:| zu:) ls:& fo:) va:) sh:| rl:|
    1. auweia,

      auch wenn mir hier jemand ein "hilfreich" aufgeklebt hat, finde ich beim erneuten Durchlesen, daß ich doch unerlaubt viele Tippfehler drin habe stehenlassen. Sie sind nicht einmal besonders originell, sondern bloß peinlich ...

      Grüße aus Berlin

      Christoph S.

      --
      Visitenkarte
      ss:| zu:) ls:& fo:) va:) sh:| rl:|
  3. Habe jetzt nicht den Artikel bereit, aber die Idee ist ziemlich simpel und effizient.

    Gebe den Hauptformularfeldern irgendwelche unlogischen Namen und füge unsichtbare Formularfelder ein mit solchen Namen wie 'Titel' 'Mail' 'Mailadresse' 'Homepage' usw.

    Diese unsichtbaren Felder müssen leer bleiben damit der Datensatz übernommen wird.

    Die meisten Spams werden von Bots versendet, die die Formularfelder analysieren sich nur an bestimmte Begriffe halten. Man stellt diesen Bots also eine Falle.

    Gruß,
    Flash

    1. Hallo.

      Die meisten Spams werden von Bots versendet, die die Formularfelder analysieren sich nur an bestimmte Begriffe halten. Man stellt diesen Bots also eine Falle.

      Prinzipiell ist mir dein Ansatz sehr sympathisch. Bedenke aber, dass bereits ein einziger groß angelegter und nicht rechtzeitig unterbundener Missbrauchsfall ernste Konsequenzen haben kann. Und bedenke, dass Browser manche Felder gegebenefalls automatisch mit vom Nutzer vorher definierten Standardangaben füllen und der Nutzer diesen Fehler nicht bemerken kann. Und wenn die Browser das bei unsichbaren Feldern nicht tun, handeln Bots vielleicht ähnlich klug.
      MfG, at

  4. Hi,
    jetzt wurde ja munter diskutiert, aber den Königsweg gibt es anscheinend nicht. Und es hat leider auch niemand die Stimme erhoben, dass er ein sicheres Skript kennt.
    Schade !
    Die Gauner (Spammer) scheinen dem anständigen Bürger immer einen Tick voraus zu sein !

    1. hallo Ingolf,

      jetzt wurde ja munter diskutiert

      Das kommt in diesem Forum häufiger vor.

      aber den Königsweg gibt es anscheinend nicht.

      Nein. Man könnte dir mehr Ratschläge geben und müßte nicht Theoriedebatten führen, wenn du dein Script vorstellen würdest.

      Und es hat leider auch niemand die Stimme erhoben, dass er ein sicheres Skript kennt.

      Wir kennen halt eher die möglichen "Stolperstellen". Ein wirklich sicheres Script besteht nur aus der einzigen Zeile "exit;" - da kann nichts passieren. Also auch nichts Schlimmes.

      Grüße aus Berlin

      Christoph S.

      --
      Visitenkarte
      ss:| zu:) ls:& fo:) va:) sh:| rl:|
      1. Hallo Christoph,

        Wir kennen halt eher die möglichen "Stolperstellen". Ein wirklich sicheres Script besteht nur aus der einzigen Zeile "exit;"

        Das darf doch nicht wahr sein !?
        Ich war früher in der Softwareentwicklung (Großrechner) beschäftigt und da konnte man bei einem Testaufwand, der so groß war wie der Entwicklungsaufwand, behaupten, das Programm sei sicher - wobei marginale Fehler immer wieder auftraten und korrigiert wurden.

        Wäre das nichts für die Profis der Selfhtml-Gemeinde:
        Ein Open-Source-Programm, das die ganzen Ideen verwirklicht ?

        1. hallo Ingolf,

          Wäre das nichts für die Profis der Selfhtml-Gemeinde:

          Wäre es denn auch nichts für einen Fragesteller, nach mehrfacher Bitte um seinen vermutlich fehlerhaften Code eben diesen Code endlich auch bekanntzugeben? Dein ursprüngliches Anliegen ist mittlerweile kaum noch Gegenstand der Debatte. Aber es liegt in deiner Hand, den Thread wieder auf die ursprünglich gewünschte Thematik zurückzuholen.

          Grüße aus Berlin

          Christoph S.

          --
          Visitenkarte
          ss:| zu:) ls:& fo:) va:) sh:| rl:|
          1. Hallo Christoph,
            es geht mir ja nicht darum, "mein" Script auf Schwächen untersuchen zu lassen oder den Thread wieder aufleben zu lassen.
            Denn morgen kommt der Nächste, der ein derartiges Problem hat und und und.
            Ich habe mich schon früher immer geärgert, wenn in jeder Entwicklungsabteilung das Rad immer wieder neu erfunden wurde, obwohl im 'Nachbarzimmer' bereits eine Lösung vorlag.
            Aus diesem Grunde wäre ein gemeinsames Vorgehen gegen diese ^'§ä?%&/
            sinnvoll. Eins Schritt wäre eine gemeinsame Entwicklung sicherer Software.
            Wenn ich die modernen Sprachen besser beherrschen würde, würde ich mich sofort beteiligen !
            Ich könnte aber gerne testen - hier habe ich schon die unmöglichsten Macken entdeckt.
            "Mein" ist im übrigen gar nicht meines, sondern eines der zahlreichen im Internet angebotenen, das ich mit meinem bescheidenen Wissen auf meine Bedürfnisse angepasst habe.
            Ich glaube, Du würdest mich steinigen, wenn ich mehrere Tausend Code-Zeilen veröffentlichen würde.
            Gruß
            Ingolf

            1. Hallo Ingolf,

              Ich habe mich schon früher immer geärgert, wenn in jeder Entwicklungsabteilung das Rad immer wieder neu erfunden wurde, obwohl im 'Nachbarzimmer' bereits eine Lösung vorlag.
              Eins Schritt wäre eine gemeinsame Entwicklung sicherer Software.

              Ich dachte, unser einfacher Formmailer wäre mittlerweile wasserdicht?

              Grüße
               Roland

              1. Hallo,
                das würde ich ja gerne glauben, aber warum dann immer wieder diese Diskussionen (auch in diesem Thread). Dann könnte man ja sagen "Nehmt diesen, dann seid Ihr auf der sicheren Seite"
                Grüße
                Ingolf