Entwickler meistern Sicherheit: Share & Learn-Serie – E-Mail-Header-Injection

Heutzutage ist es üblich, dass Websites und Anwendungen es Nutzern ermöglichen, Feedback, Terminerinnerungen und andere Informationen per E-Mail zu versenden. Normalerweise ist dieser Prozess recht harmlos, und die meisten Menschen betrachten ihn nicht einmal als potenzielles Sicherheitsrisiko.

Wie bei jedem anderen Designelement, das Benutzereingaben zulässt, können diese scheinbar unbedeutenden Funktionen jedoch bei unsachgemäßer Konfiguration von böswilligen Akteuren für schädliche Zwecke manipuliert werden. Es reicht aus, dem Benutzer die Möglichkeit zu geben, Code in ein Eingabefeld einzugeben, der dann fälschlicherweise vom Server verarbeitet wird. Plötzlich kann eine E-Mail-Anwendung zur Waffe werden.

In dieser Folge erfahren Sie:

• Wie Angreifer eine E-Mail-Header-Injection auslösen können
• Warum E-Mail-Header-Injections gefährlich sind
• Techniken zur Behebung dieser Schwachstelle.

Wie lösen Angreifer eine E-Mail-Header-Injection aus?

Obwohl man sie selten als programmierbar betrachtet, können die meisten E-Mail-Kontaktanwendungen oder -funktionen auf Websites Eingaben akzeptieren, die die Art der Abfrage verändern. Dies geschieht normalerweise automatisch durch den Server, nachdem ein Benutzer seine Informationen, wie z. B. seine E-Mail-Adresse, in das Kontaktfeld eingegeben hat. Das Programm konfiguriert dann die Nachricht, fügt die entsprechenden Empfänger hinzu und versendet die Nachricht über den Standard-E-Mail-Server.

Eine typische E-Mail-POST-Anfrage könnte so aussehen:

POST /contact.php HTTP/1.1
Host: www.example.com

Und nach der Eingabe der Benutzerinformationen Code generieren, der so aussieht:

name=RealName&replyTo=RealName@ValidServer.com&message=YourAppointmentReminder

Das Problem entsteht, wenn Hacker beginnen, Code in den Prozess einzuschleusen, anstatt nur ihre Kontaktinformationen anzugeben. Dies ähnelt einem SQL-Injection-Angriff, richtet sich jedoch gegen die E-Mail-Anwendung. Ein Beispiel für eine manipulierte Abfrage, die stattdessen Spam von Ihrer Anwendung an einen Zielbenutzer senden würde, könnte so aussehen:

name=FakeName\nbcc: SpammedVictim@TargetAddress.com&replyTo= FakeName@ValidServer.com&message=Spammed message

Warum ist E-Mail-Header-Injection gefährlich?

Je nach Fähigkeiten und Absichten des Angreifers können E-Mail-Header-Injection-Angriffe von einfach nur lästig bis hin zu hochgefährlich reichen. Am unteren Ende der Schweregradskala könnten sie in der Lage sein, ihre Kontaktinformationen in das BCC-Feld einer ausgehenden Nachricht einzufügen, die an ein geheimes oder nicht öffentliches Postfach innerhalb Ihres Unternehmens gesendet wird, und dieses so für den Hacker offenzulegen.

Besorgniserregender ist, dass sie möglicherweise die vollständige Kontrolle über Ihren E-Mail-Server erlangen, um Spam, Phishing oder andere schädliche E-Mails von Ihrer Organisation aus zu versenden. Sie müssten nicht einmal vortäuschen, dass die E-Mail von Ihren internen Servern stammt, da sie tatsächlich von dort aus gesendet würde. Wenn Sie diese Aktivitäten nicht überwachen, können sie den Prozess sogar automatisieren und Hunderte oder Tausende von E-Mails über die Server Ihres Unternehmens versenden – und zwar so, dass es aussieht, als würden Sie diese Aktivitäten selbst veranlassen.

Das Problem der E-Mail-Header-Injection beseitigen

Wie bei SQL-Injection und anderen Angriffen dieser Art besteht der Schlüssel zur Beseitigung der Gefahr, dass ein böswilliger Benutzer eine E-Mail-Header-Schwachstelle ausnutzt, darin, Benutzereingaben niemals zu vertrauen. Wenn ein Benutzer Informationen eingeben kann, selbst wenn es sich um einen trivialen Vorgang wie die Eingabe seiner E-Mail-Adresse handelt, müssen Sie vom Schlimmsten ausgehen. Oder zumindest davon ausgehen, dass das Schlimmste möglich ist.

Für alle Parameter sollte eine Eingabevalidierung durchgeführt werden, auch wenn eine E-Mail-Kontaktfunktion zu einer App oder Website hinzugefügt wird. Mithilfe von Whitelisting können Prozesse und Felder, die Sie als gültig erachten, gezielt freigegeben und alles andere blockiert werden. Tatsächlich verfügen die meisten Frameworks über Bibliotheken, mit denen Funktionen auf das notwendige Maß beschränkt werden können. Dies verhindert, dass von böswilligen Benutzern eingegebener Code oder Befehle von Ihren Servern erkannt und verarbeitet werden.

Weitere Informationen zu E-Mail-Header-Injections

Weiterführende Informationen finden Sie in den Hinweisen von OWASP zu E-Mail-Header-Injections. Sie können Ihr neu erworbenes Wissen zur Abwehr auch direkt mit der kostenlosen Demo der Secure Code Warrior-Plattform testen, die Cybersicherheitsteams zu echten Cyber-Experten ausbildet. Um mehr über die Bekämpfung dieser Schwachstelle und eine Vielzahl weiterer Bedrohungen zu erfahren, besuchen Sie den Secure Code Warrior-Blog.

Sie sind bereit, eine E-Mail-Injection sofort zu finden und zu beheben? Besuchen Sie unsere Plattform und stellen Sie Ihre Fähigkeiten unter Beweis: [Hier starten]