FYI: Email Injection

[Borusse]

Hallo ich bin jetzt auch von Spam über mein Kontakt formular betroffen.
Habe das direkt vom Netz genommen.
Frage:
Wenn ich das jetzt entsprechend umschreibe gibt es eine möglichkeit direkt zu testen ob es sicher ist oder geht das nur mit so einem Bot.
Was müsste ich zb. in die Adresszeile schreiben um zu testen ob der Header noch manipulierbar ist.

[Andreas aus B.]

Hallo alle miteinander,

habe mir hier schon die ein oder andere Anregung geholt bin aber erneut "Opfer" von email injection geworden. Kann jemand mal bitte ein komplettes Script, dass nach eurer Meinung weitgehend sicher ist, posten oder zumindest mitteilen, wo man eins im Web findet? Ich bin an dem Zusammensetzen der vielen Codeschnippsel kläglich gescheitert und habe den Überblick verloren.

Gruß Andreas

[skipperjan]

Hm,

bei meinen bisherigen Mailern habe ich relativ wenig auf diese Dinge geachtet.
Wegen einigen unseriösen Diensten wie sog. Gewinnspieldiensten die eine auf 5000 Gewinnspielseiten eintragen wollen habe ich vor drei Jahren angefangen, für jedes Formular mit Einmalschlüsseln zu arbeiten.

Seit dem gab es nie wieder Spam. Die Idee ist ja einfach, bevor jemand auf eines meiner ssl Formulare kommt, muss er vorher auf einer anderen Seite eines Auftrittes gewesen sein. Es wird ein Schlüssel generiert, der kommt in die Tabelle und wird in der Session des Users gespeichert. Die Tabelle ist je nach größe der Seite und Traffic auf 10 bis 50 Zeilen begrenzt. Sobald also 10-50 andere Leute auf der Einstigsseite waren, fliegt der Schlüssel aus der DB raus und ein User kann so lange kein Formular abschicken, bis er wieder auf eine definierte "Einstigsseit" kommt und einen neuen Key erhält, schickt er rechtzeitig sein Formular ab, wird der Key aus der DB gelöscht und der User muss sich erst wieder einen neuen holen.

Das Formular trägt selbst keine Informationen über seine Zieladresse, man kann zwar ein Thema vergeben, aber das Subject wird dynamisch aus dem Navigationsstatus generiert und ist im Formular nicht sichtbar. Die Zieladresse
wird dynamisch aus der DB gezogen, aus der Navigationstabelle, steht da nix wird ein default-Wert gesetzt.

Das Verfahren ist unsichtbar im Hintergrund und kann nur schwer von einem bot nachvollzogen werden. html und slashes werden bei jedem Feld "gestrippt",
ist bei einer solchen Konstruktion überhaupt eine Injection möglich?

Da ich jetzt übers Wochenende weg bin, werde ich mal in Ruhe überlegen und am Sonntag ein paar Szenarien durchspielen. Entscheidend ist dabei, ob Manipulationen im Mail-Body möglich sind oder nur der Head der Mail geprüft werden müsste.

So long,

skip

[HoRnominatoR]

der message-body wird durch eine neue, leere zeile eingeleitet, da kein eigener header exisitert, und kann somit nur durch einen vorangegangen, modifizierten header fruehzeitig eingeleitet werden - durch mail-injection einer leeren zeile. alles, was nach der neuen, leeren zeile folgt, ist der message-body und wird als plain-text interpretiert - header-anweisungen eingeschlossen. der mesage-body wird nicht geparsed. alle header muessen vor dieser neuen, leeren zeile eingefuegt werden.

simpel waere es natuerlich, aus allen fuer den header relevanten feldern die mail-injection-faehigen zeichen zu entfernen.

PHP-Code:

// letzteres ist der line-feed aus dem artikel im ersten posting
$injection_characters = array("\n", "\r", "%0A");

// muss je nach formular angepasst werden
$injection_inputs = array('subject', 'from', 'to');

// in jeder relevanten formularvariable die injection_characters ersetzen
foreach($injection_inputs as $val) $_POST[$val] = str_replace($injection_characters, '', $_POST[$val]); 


[steffenk]

besser als nur diese Zeichen zu entfernen ist es, den String dort abzuscheiden.

[HoRnominatoR]

in wie fern "besser"? solange kein injection_character vorhanden ist, kann auch keine injection stattfinden. um den string abzuschneiden, muesste man in jedem feld nach jedem zeichen suchen und den string ab dort bearbeiten.

PHP-Code:

foreach($injection_inputs ...) foreach($injection_characters ...) substr(..., strpos(...)); 


das halte ich fuer unnoetig. wer solche zeichen einfuegt, braucht nicht damit zu rechnen, dass man die mail bearbeitet um sie dennoch abschicken zu koennen.

[steffenk]

besser deswegen, weil das entfernen der Umbrüche auch eine ungültige email erzeugt.
Man könnte natürlich den Versand solcher mails einfach unterbinden, wenn diese Zeichen gefunden werden, da es sich ja offensichtlich um spams handelt.

[Nina]

Hm, verzeiht mir wenn ich hier nur Bahnhof verstehe (für PHP ist bei uns jemand anders zuständig, der im Moment im Urlaub ist) ...

Kann vielleicht einer von euch ein einfaches PHP-Formular posten, das gegen diese Injection sicher ist?
Also nix aufwendiges, sondern einfach nur "Name, Firma, Anliegen(textarea)". Wäre wirklich sehr hilfreich, da ich gerade versuche alle Problemfälle einzugrenzen, die dazu geführt haben könnten dass unsere Emailadressen immer sofort als Spam geflaggt werden

[Nina]

Ich nutze normalerweise gerne dieses Script (Kontaktformular steht davor im Code)

PHP-Code:

Code gelöscht, bitte einfach per PM anfragen :) 


[Nele]

Moin,

Ausschlaggebend bei dieser Spammethode ist ja, dass Eingabefelder mit zusätzlichen Mail-Headern gefüttert werden, die dafür sorgen, dass eine Mail auch an andere Empfänger gesendet wird. Diese extra Header müssen durch Zeilenumbrüche voneinander getrennt sein.

Deshalb habe ich folgenden Code in meine Formulare eingebaut (und nach einigen Attacken zuvor ist auch nix mehr durchgekommen):

PHP-Code:

foreach($_POST as $var=>$val) {
    if (($var!='Bemerkung') AND (eregi("\r",$val) || eregi("\n",$val))){
        echo "Falsche Eingabe!";
        die();
    }
    elseif ($var!='submit') $text.="$var: $val\n\n";
} 


Jedes Textfeld hat ja einen Namen (hier:$var) und einen Wert (hier:$val).
In der zweiten Zeile wird überprüft, ob ein Eingabefeld außer dem Textfeld namens "Bemerkung" einen Zeilenumbruch enthält (in Textfeldern sollen Zeilenumbrüche erlaubt sein und die können meines Wissens nach auch nicht für zusätzliche Header genutzt werden). Ist dies der Fall, wird das Script abgebrochen und eine Fehlermeldung ausgegeben. Ansonsten werden bei Betätigung des Submit-Buttons der Variable $text alle Textfelder und die dazugehörigen Werte zugewisen (hier wäre natürlich auch auch etwas anderes möglich).

Ich hoffe, dass ich mich einigermaßen verständlich ausgedrückt habe. Bin selbst nicht so der PHP Profi. Vielleicht weiß ja jemand noch eine bessere Methode oder kann mich berichtigen.

[Nina]

Wenn man hier jetzt vor //Alle Felder ausgefüllt - Email generieren folgenden Zusatz einfügt, ist es dann sicher?

PHP-Code:

  $email = preg_replace( "/[^a-z0-9 !?:;,.\/_\-=+@#$&\*\(\)]/im", "", 
  $email );

  $email = preg_replace( "/(content-type:|bcc:|cc:|to:|from:)/im", "", 
  $email );

  $nachricht = preg_replace( "/(content-type:|bcc:|cc:|to:|from:)/im", "", 
  $nachricht ); 


[steffenk]

ich hab wohl eine Methode, die unhackbar ist.
Wars wirklich so einfach ?

PHP-Code:

$mailheaders="From: Homepage <website@xxx.de>\r\nContent-Type: text/html";
    $msg="\r\n"
        .'Name : '.$name."\r\n"
        .'E-Mail : '.$email."\r\n"
        .'Webseite : '.$url."\r\n"
         ." hat folgende Nachricht abgeschickt :\r\n\r\n"
        .stripslashes($comments);    
    
    $msg=nl2br(htmlentities($msg));

if (@mail("admin@domain.de", "Kontakt von der Website", $msg, $mailheaders)) {
...
} 


[Boris]

Du meinst durch das stripslashes?

Was mich irgendwie stört ist das nl2br und htmlentities ... dadurch werden doch auch in einer normalen Emails alle Umlaute in &auml (usw.) und alle Umbrüche als <br /> reingeschrieben - in einer Textmail!

[steffenk]

ich meine eigentlich die Tatsache, das keinerlei Angabe den Header beeinflusst. Die Hacker/Bots können also eintragen was sie wollen, sie werden das nie missbrauchen können.

Das Format des Bodys ist reine Nebensache und habe ich hier so formatiert, da ich sie ja erhalte, unzwar als html.

[Boris]

Oh, stimmt (Content-Type: text/html) ... hab ich übersehen.

Wie kommt es hier zu der "Tatsache"? Durch das stripslashes ja eigentlich nicht, du benutzt es ja nur für die $comments? Ich denke, durch das nl2br() werden die "bösen" Einträge abgefangen, oder?