Mail Versand - Zeilenlänge & Injection Frage

[einermeiner]

Warum sollte die Zeilenlänge nicht größer als 70 sein?
Aufgrund der hohen Komplexität der E-Mail Syntax aufgrund der IDNs würde ich gerne auf eine E-Mail Validierung verzichten, doch wie sieht es dann bzgl. E-Mail-Header-Injection aus?

In der Beschreibung von SwiftMailer wird erwähnt, dass es sicher gegenüber solchen Angriffen ist, da alle nicht-ASCII-Zeichen umgewandelt würden, ist das so?

Gehört \r und \n nicht zu ASCII, also ist '\' + 'n' nicht das Gleiche wie '\n' (weil '\' und 'n' in ASCII enthalten sind)?

[AmicaNoctis]

Hallo,

Warum sollte die Zeilenlänge nicht größer als 70 sein?

Empfohlen sind 78 Zeichen, da E-Mails früher auf textbasierten Systemen gelesen wurden. Da hatte man noch zwei Stellen frei, um mit Grafikzeichen einen Fensterrahmen drum zu machen, bis man an die 80-Zeichen-Grenze der Konsole anstieß.

Diese Grenze wurde inoffiziell nach unten gedrückt, um bei Mehrfachzitaten die sogenannten Kammzitate zu vermeiden.

Aufgrund der hohen Komplexität der E-Mail Syntax aufgrund der IDNs würde ich gerne auf eine E-Mail Validierung verzichten, doch wie sieht es dann bzgl. E-Mail-Header-Injection aus?

Solange keine Zeilenumbrüche drin sind, könnte man die E-Mail nur ungültig machen und dann wird sie nicht mehr weitergeleitet, also hätte man als Angreifer nichts davon. Wenn du Zeilenumbrüche findest, solltest du sie einfach zu CRLF umwandeln (falls es einzelne CRs oder LFs sind) und durch ein vorangestelltes Leerzeichen maskieren (Linear WhiteSpace).

Gehört \r und \n nicht zu ASCII, also ist '\' + 'n' nicht das Gleiche wie '\n' (weil '\' und 'n' in ASCII enthalten sind)?

CR und LF gehören zu ASCII und werden in C-basierten Sprachen oft durch die Escape-Sequenzen \r und \n dargestellt. Das heißt aber nicht, dass ein \ und ein n auch einen Umbruch darstellt, denn wenn man diese Zeichen einzeln hintereinander in einem PHP-String schreiben würde, sähen sie so aus: "\\n".

Vermutlich soll der Satz von Swiftmailer bedeuten, dass es Zeichen jenseits von 127 (0x7f) maskiert, denn die gehören nicht zu US-ASCII.

Gruß,

Amica

[einermeiner]

Wenn der Empfänger also einen grafischen Mailclienten hat, entstehen keine Probleme, wenn ich eine größere Zeilenlänge nutze?

Zitat von Swift Mailer

No header -- including text headers -- in Swift Mailer is vulnerable to header-injection attacks. Swift Mailer breaks any attempt at header injection by encoding the dangerous data into a non-dangerous form.

Aber selbst in US-ASCII ist doch CR und LF enthalten?

Wenn du Zeilenumbrüche findest, solltest du sie einfach zu CRLF umwandeln (falls es einzelne CRs oder LFs sind) und durch ein vorangestelltes Leerzeichen maskieren (Linear WhiteSpace).

Wie sähe das in Code aus?
Oftmals werden auch hexadezimale Schreibweisen durchsucht, also würde ein einfaches Suchen nach \n und \r nicht reichen (bei vorherigem urldecode())?

Der message-Teil ist nicht anfällig, darf also beliebige Zeichen enthalten oder? (gehört ja nicht zum header)

[AmicaNoctis]

Wenn der Empfänger also einen grafischen Mailclienten hat, entstehen keine Probleme, wenn ich eine größere Zeilenlänge nutze?

Solange sie nicht größer ist als 998, ist es vertretbar. Die 78 sind eine Empfehlung, die 998 eine Bedingung.

Aber selbst in US-ASCII ist doch CR und LF enthalten?

Ja US-ASCII enthält alles von 0x00 bis 0x7f. Alles darüberhinaus ist Extended ASCII bzw. ANSI.

Der message-Teil ist nicht anfällig, darf also beliebige Zeichen enthalten oder? (gehört ja nicht zum header)

Fast. Wenn es eine Multipart-E-Mail ist, darf das Boundary nicht vorkommen. Ansonsten darf bei 8bit-Encoding jedes beliebige Zeichen enthalten sein, bei anderen Encodings muss man sich schon an die entsprechende Codierung halten.

[einermeiner]

Ja US-ASCII enthält alles von 0x00 bis 0x7f.

Deswegen verstehe ich nicht, warum die Kodierung vor der Header Injection schützen soll.

Wenn es eine Multipart-E-Mail ist, darf das Boundary nicht vorkommen.

OK. Wird eine reine HTML Mail, somit muss ich also kein Boundary setzen und es kann nichts passieren.

[AmicaNoctis]

Deswegen verstehe ich nicht, warum die Kodierung vor der Header Injection schützen soll.

Vermutlich weil der Mailer neben dem Codieren von Non-ASCII-Zeichen auch Zeilenumbrüche in LWS umwandelt. Aber du hast damit recht, dass die Codierung alleine nicht vor Injection schützen würde.

[einermeiner]

Nochmal zu den LWS, wie würde man diese denn in PHP darstellen, also wie kann ich einen String "abc\nxyz" mit dem LWS maskieren und was passiert mit einem solchen maskierten \n, wird es dann beim Client wieder angezeigt als Zeilenumbruch?

[AmicaNoctis]

Mal grundsätzlich: Wenn du Swiftmailer nimmst, kümmert der sich selbst um solche Sachen. Wenn du es selbst bauen willst, musst du die entsprechenden RFCs lesen. Ich hab die mal gelesen und halte mich für relativ fit, dennoch kann man das alles unmöglich im Kopf behalten.

Und nein, LWS wird zu einem Leerzeichen kollabiert und nicht als Umbruch angezeigt, deshalb heißt es auch Linear WhiteSpace. Wenn du Umbrüche unbedingt von Hand zu LWS machen willst, kannst du

preg_replace("`(?<![\\t ])(?:\\n|\\r\\n?)+)`", " \r\n", $text); 

benutzen. Achte aber auf die bekannten Probleme mit UNIX sendmail, welches alle LFs in CRLF umwandelt und damit lauter ungültige CRCRLF-Sequenzen produziert.

[einermeiner]

Ich habe bei meiner Seite gerade einen solchen Angriff probiert, wenn ich den Code im "From:"-Teil unterbringe, funktioniert die Injection, aber im Subject nicht, warum?

<?php 
$receiver = "";
$receiver2 = "";
$from = "";
$sub = "Betreff\nCc: $receiver";

mail($receiver2, $sub, 'Inhalt', "From: $from"); 
?>

Vertausche ich, $sub und $from, dann funktioniert es.

[AmicaNoctis]

Weil der Subject-Parameter sozusagen atomar ist und PHP alle nicht erlaubten Zeichen maskiert. Bei den Extra-Headers kann es das nicht, denn man muss ja die Möglichkeit haben, dort mehrere Header anzugeben. Dass du dort nur From benutzt, ist reiner Zufall.

[einermeiner]

Also ist der Subject header nicht anfällig für Injection, nur der From header, nachdem ich diverse Internetquellen gelesen hatte, erschien es mir so, als ob es auch mit den anderen funktionieren würde.

[AmicaNoctis]

Das kann ich dir nicht mit Sicherheit bestätigen. Für ganz simple Versuche mag PHP das abfangen können, aber es gibt ja noch zahlreiche andere Tricks mit gespooften UTF-8-Sequenzen und so. Ich würde mich also nicht blind darauf verlassen, dass der Betreff sauber ist.

Da du den Betreff sowieso behandeln musst, weil er ja gerade auch in unserem Land Sonderzeichen, wie Umlaute oder ß enthalten kann, die allesamt als Encoded-Word übergeben werden müssen, solltest du das auch gleich selbst absichern.

Aber nochmal: Warum nimmst du den Swiftmailer nicht? Meines Wissens ist der doch ganz brauchbar.

[einermeiner]

Weil ich ein Framework nutze, das aber keinen eingebauten Mailer hat und die Integration zwar möglich ist, aber mit Aufwand verbunden ist, dachte ich, dass es bei einem so einfachen Mailversand auch schnell selbst implementiert ist...
Muss ich mir dann wohl doch anders überlegen, was nutzt du zum Mailversand?

Im Beispiel 4 auf PHP: mail - Manual sind in der message und im subject Sonderzeichen enthalten, warum funktioniert dort der Versand anscheinend auch ohne Kodierung, was ja alleine schon wegen ISO-8859-1 eigentlich nicht korrekt sein dürfte?

aber es gibt ja noch zahlreiche andere Tricks mit gespooften UTF-8-Sequenzen und so

Hast du dazu einen Link, ich finde immer nur die Standardangriffe.

[AmicaNoctis]

was nutzt du zum Mailversand?

Ich benutze etwas selbst gebautes aus der Zeit, als ich mich mit den E-Mail-RFCs beschäftigt hatte.

Im Beispiel 4 auf PHP: mail - Manual sind in der message und im subject Sonderzeichen enthalten, warum funktioniert dort der Versand anscheinend auch ohne Kodierung, was ja alleine schon wegen ISO-8859-1 eigentlich nicht korrekt sein dürfte?

Hab mir das Beispiel jetzt mindestens viermal angesehen, aber ich kann kein einziges Sonderzeichen entdecken. Was meinst du genau?

[einermeiner]

[COLOR=#000000][COLOR=#DD0000]für August[/COLOR][/COLOR]

das "ü"