Quoting/Escaping Variablen im Mail Body

Ich fühle mich etwas peinlich, weil ich eine Mail-Körper mit PHP generieren, ohne die Variablen zu entkommen. In HTML verwende ich htmlspecialchars() oder ähnliche Funktionen, für Befehlszeilen escapeshellarg(), aber für Mails? Zum Beispiel so etwas wie dieses:Quoting/Escaping Variablen im Mail Body

<?php 
$usercontent = $_GET['usercontent']; 
mail("[email protected]", "My Subject", "My body with $usercontent included"); 
?>

Was könnte ein möglicher Angreifer mit einem Skript tun, wie die oben und wie könnte ich schützen gegen einen solchen Angriff? Oder ist PHP Mail() gespeichert und warum?

aktualisieren

Bitte beachten Sie das Beispiel:

Nur der Körper (keine Header!) Betroffen ist
Content-Type ist text/plain
Einige Beweis der Antwort wäre nett
MTA ist ein Postfix sendmail mit "/ usr/sbin/sendmail -t-i"

Quelle

2013-04-17 Trendfischer

Die riskantere Verwendung der Mail-Funktion ist auf dem 4. Parameter, und solange Sie es nicht mit benutzergenerierten Inhalten verwenden, denke ich, dass Sie sicher genug sind, damit zu gehen. Wie auch immer, ich würde empfehlen, eine Bibliothek von Drittanbietern wie Swiftmailer http://swiftmailer.org/ – arraintxo

zu verwenden. Für die Sicherheitsprobleme, die den 4. Parameter betreffen, können Sie auch hier nachschauen: http://stackoverflow.com/questions/ 4834337/phps-mail-was-sind-potenzial-auswertungsfragen-für- – arraintxo

Danke für die Kommentare, über die Sicherheitsprobleme aus den anderen Parametern, mir ist klar, ich interessiere mich nur für den Körper wie injizieren Multi-Part-Mails oder so ähnlich. – Trendfischer

Es ist nicht gegen XSS atack gesichert, denn wenn Ihre Mail HTML enthält, kann jemand es in Mail injizieren.

Das gute Verhalten ist zu prüfen und gültig Daten, die Sie erwarten. Wenn ich du wäre, würde ich dieser Schnur entkommen. Es kostet fast nichts und man muss sich keine Sorgen machen, dass es nicht benutzt wird.

Quelle

2013-04-17 12:10:18 Robert

Ja, das wäre die Antwort, die ich mir gegeben hätte ;-) Aber welche Art von Flucht wäre angebracht? – Trendfischer

Gute Frage. Ich glaube nicht, dass Sie den Fließtext umgehen müssen, aber ich weiß, dass es möglich ist, Kopfzeilen zu einer Mail hinzuzufügen (wie ein BCC zu Tausenden von Adressen), wenn Sie dem Benutzer erlauben, eine von Adresse einzugeben. Also, wenn Sie Variablen in diese setzen, überprüfen Sie auf jeden Fall Newlines (\n und \r), um sicherzustellen, dass keine zusätzlichen Header hinzugefügt werden.

Quelle

2013-04-17 12:11:43 Rijk

Ich dachte darüber nach, Zeilenumbrüche zu umgehen, aber die Variablen sind nicht am Anfang des Körpers. Wie sollte man zusätzliche Header hinzufügen? Es geht mir eher darum, das Problem zu verstehen, aber danke für die Antwort. – Trendfischer

Also ich denke, du bist in Ordnung, ohne persönlich zu entkommen. – Rijk

Der grundlegende E-Mail-Nachrichtentext ist reiner Text. Wenn Sie einen anderen Typ wie HTML oder eine mehrteilige Nachricht verwenden möchten, müssen Sie die MIME-Erweiterung verwenden und den Typ entsprechend angeben. Verwenden Sie dazu Content-Type (z. B. text/html für HTML oder multipart/… für eine mehrteilige Nachricht).

So aus der Sicherheitsperspektive, gibt es keine Möglichkeit, etwas schädlich zu injizieren (zumindest nicht gemäß Spezifikation). Auch Nicht-ASCII-Zeichen sollten trotz der fehlenden Deklaration der verwendeten Zeichencodierung korrekt behandelt werden.

Allerdings kann es immer noch einige Fehler in E-Mail-Clients geben, die auf diese Weise ausgenutzt werden können. Aber ich bezweifle das.

Quelle

2013-04-17 16:27:22 Gumbo

Imho, das ist die beste Antwort bisher. Content-Type text/html sollte klar sein, multipart/... könnte gefährlich sein. Obwohl meine Zweifel noch nicht erfüllt sind. Was ist mit einem einzigen "." in einer Zeile, wie "\ r \ n. \ r \ n"? Könnte das gefährlich sein? – Trendfischer

Denken Sie an den Körper der E-Mail auf diese Weise: "Mission Top Secret Destination unbekannt." Wir wissen vielleicht nicht, welche Art von Client die Nachricht lesen wird, aber wir können vermuten, dass wir nicht wollen, dass Live, user-unescaped HTML in ihm auftaucht. Da viele Clients E-Mails in HTML lesen, wäre das Beste, was zu tun wäre, htmlentities() der Benutzer E-Mail-Nachricht.

Eine Methode aus meiner Escape-Klasse.

<?php 
class escaper 
{ 
    public function superHtmlEntities($string) 
    { 
     return htmlentities($string, ENT_QUOTES | ENT_HTML5, 'UTF-8', true); 
    } 
} 
?>

========================================

Betrachten Sie mindestens so etwas und mehr bei Ihrer Recherche.

Quelle

2015-04-30 17:39:11

Escaping HTML sollte das Minimum sein. Einverstanden. Zumindest bei Content-Type 'text/html'. Aber sei vorsichtig mit dem Zeichensatz und achte darauf, dass die Doppelcodierung in Ordnung ist. In einigen Validierungsbibliotheken haben Sie bereits eine codierte Eingabe. – Trendfischer

Antwort

Verwandte Themen