Vinzenz Mai: /Email: Schutz vor Headerinjektion

Beitrag lesen

Hallo Gunther,

Während der Doppelpunkt im Headerfeldnamen nicht vorkommen darf, ist der Doppelpunkt im Body erlaubt.
Der Punkt ist doch, dass zwischen dem field name und dem field body _immer_ ein Doppelpunkt stehen _muss_. Daher wäre für mich unter dem Sicherheitsaspekt die Eingabe eines Doppelpunkts seitens des Users im Formular ein Ausschlusskriterium.

Warum? Er ist erlaubt, er ist gegebenenfalls sinnvoll. Warum ausschließen? Versteh' ich nicht. Entferne die Zeilenumbrüche und der Möchtegerncracker kann kein Headerfeld selbst erzeugen.

Nein. Du willst also viele zulässige E-Mail-Adressen und Headerinhalte ausschließen. Das ist keine gute Idee.

  1. Wieso Headerinhalte? Die Benutzer _sollen_ ja wohl _keine_ Headerangaben selbst in das Formular eintragen.

Äh selbstverständlich, darum geht es ja in diesem Thread. Sonst wäre Headerinjektion gar nicht möglich. Wenn Dein Formular keine Möglichkeit bietet, durch Headerinjektion eigene Header zu erzeugen, dann kann es natürlich auch keine Header erzeugen - klingt logisch.
Und Headerinjektion ist das Erzeugen von vom Formularanbieter nicht gewollten Headerzeilen.

  1. Und ja, im local part einer Emailadresse wäre auch der Doppelpunkt erlaubt (allerdings müsste der local-part dann entweder in doppelte Anführungsstriche eingeschlossen werden oder der Doppelpunkt durch einen vorangestellten Backslash escaped werden).

Und genau hier sehe ich einen gravierenden Unterschied zwischen Theorie und Praxis, bzw. den Sicherheitsanforderungen eines Webmasters.

Und ja, ich sehe es durchaus als vertretbar an, wenn man Emailadressen, die einen Doppelpunkt enthalten, zurückweist (zumindest bei einem Kontaktformular)! Denn wie oft wird daran das Zutsandekommen einer Kommunikation in der Praxis wirklich scheitern? Kann man nicht eher davon ausgehen, dass User mit einer solchen Emailadresse (mit Doppelpunkt) auch noch mind. eine Alternative ohne haben?

Sorry. Nein. Verstehe ich nicht. Habe ich kein Verständnis dafür. Wenn keine Sicherheitsprobleme vorhanden sind, dann ist es keine gute Idee, auch nur einen einzigen möglichen Nutzer auszuschließen. Es ist nicht notwendig. Warum also? Warum? Was hat es mit den Sicherheitsanforderungen zu tun?

Verhindere Headerinjektion und gut ist.
Verhindere keine richtigen Eingaben aus einem Bauchgefühl heraus, dass durch nichts begründbar ist. Der Doppelpunkt ist ok, durch Ausfiltern gewinnst Du meiner Meinung nach nichts dazu.

Ich glaube schon, denn ansonsten dürften diese Leute eh des öfteren erhebliche Probleme haben, da es seit Jahren durchaus gängige Praxis im Web ist, Adressen in dieser Form zu überprüfen. Und da spielen die RFCs eben keine Rolle.

Jaja, diese gängige Praxis verhindert alles Neue. Sich auf diese zu berufen, diese fortzuschreiben ist der größte Fehler, den es gibt - siehe IE6 und Webstandards.

Diese gängige Praxis muss weg. Sei offen. Es gibt keinen Grund, sie fortzusetzen. Ganz im Gegenteil: Du weißt jetzt, dass diese Praxis beschränkt ist.

Wie heißt der Grundsatz so schön:
Sei liberal mit dem, was Du entgegennimmst.
Sei konservativ mit dem, was Du versendest.

Freundliche Grüße

Vinzenz