SCW-Symbole
Held-Hintergrund ohne Trennlinie
Blog

Coders Conquer Security: Share & Learn シリーズ-メールヘッダーインジェクション

ヤープ・キャラン・シン
Veröffentlicht Mar 21, 2019
Zuletzt aktualisiert am 10. März 2026

Heutzutage ist es üblich, dass Websites und Anwendungen den Benutzern erlauben, Feedback, Terminerinnerungen und verschiedene andere Informationen über eine Anwendung per E-Mail zu senden. Normalerweise ist dieser Vorgang ziemlich harmlos, und die meisten Leute denken nicht einmal über ein potenzielles Sicherheitsrisiko nach.

Wie jedes andere Designelement, das Benutzereingaben zulässt, können jedoch auch diese scheinbar unbedeutenden Funktionen, wenn sie nicht richtig konfiguriert sind, von böswilligen Benutzern für schändliche Zwecke manipuliert werden. Es genügt, dem Benutzer die Möglichkeit zu geben, Code in das Eingabefeld einzugeben, der dann fälschlicherweise vom Server verarbeitet wird. Plötzlich kann eine E-Mail-Anwendung zur Waffe werden.

In dieser Folge lernen wir:

  • Wie Angreifer eine E-Mail-Header-Injection auslösen können
  • Warum E-Mail-Header-Injektionen gefährlich sind
  • Techniken, die diese Sicherheitslücke beheben können.

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

Obwohl es nicht oft als programmierbar angesehen wird, können die meisten E-Mail-Kontaktanwendungen oder Funktionen, die in Websites oder Anwendungen eingebaut sind, Eingaben akzeptieren, die die Art der Abfrage ändern. Dies geschieht normalerweise automatisch durch den Server, nachdem ein Benutzer seine Informationen, wie z. B. seine E-Mail-Adresse, in das Vertragsfeld eingegeben hat. Das Programm konfiguriert dann die Nachricht, fügt die entsprechenden Empfänger hinzu und sendet die Nachricht über seinen Standard-E-Mail-Server.

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

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

Und generieren Sie Code, der so aussieht, nachdem ein Benutzer seine Informationen eingegeben hat:

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

Das Problem tritt auf, wenn Hacker beginnen, Code in den Prozess zu injizieren, anstatt nur ihre Kontaktdaten. Dies ist einem Angriff vom Typ SQL-Injection nicht unähnlich, richtet sich aber gegen die E-Mail-Anwendung. Ein Beispiel für eine manipulierte Abfrage, die stattdessen Spam aus Ihrer Anwendung an einen gezielten Benutzer senden würde, könnte so aussehen:

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

Warum ist Email Header Injection gefährlich?

Abhängig von der Geschicklichkeit des böswilligen Benutzers und seinen Absichten können E-Mail-Header-Injection-Angriffe in Bezug auf den Schweregrad von einfach nur lästig bis 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 bekannt gegebenes Postfach innerhalb Ihres Unternehmens gesendet wurde, und sie so einem Hacker zu offenbaren.

Noch bedenklicher ist, dass es ihnen erlauben könnte, Ihren E-Mail-Server vollständig zu kontrollieren, um Spam-, Phishing- oder andere Angriffs-E-Mails von Ihrer Organisation aus zu versenden. Sie bräuchten nicht zu versuchen, die Tatsache vorzutäuschen, dass die E-Mail von Ihren internen Servern kommt, da sie tatsächlich von dort stammen würde. Und 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 so aussieht, als würden Sie diese Aktivitäten tatsächlich veranlassen.

Eliminierung des E-Mail-Header-Injection-Problems

Wie bei SQL-Injection und anderen Angriffen dieser Art liegt der Schlüssel zum Ausschluss der Möglichkeit, dass ein böswilliger Benutzer eine E-Mail-Header-Schwachstelle ausnutzt, darin, den Benutzereingaben niemals zu vertrauen. Wenn ein Benutzer in der Lage ist, Informationen einzugeben, selbst wenn es sich um einen scheinbar 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.

Die Eingabevalidierung sollte für alle Parameter durchgeführt werden, auch beim Hinzufügen einer E-Mail-Kontaktmöglichkeit zu einer App oder Website. Whitelisting kann verwendet werden, um gezielt Prozesse und Felder zu aktivieren, die Sie als gültig erachten, während alles andere verweigert wird. Die meisten Frameworks verfügen über Bibliotheken, die dabei helfen können, Funktionen nur auf die benötigten zu beschränken. Auf diese Weise wird verhindert, dass Code oder Befehle, die von böswilligen Benutzern eingegeben werden, von Ihren Servern erkannt und verarbeitet werden.

Weitere Informationen über E-Mail-Header-Injektionen

Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über E-Mail-Header-Injektionen sagt. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Secure Code Warrior Plattform testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

Sind Sie bereit, eine E-Mail-Injection zu finden und zu beheben? Gehen Sie auf die Plattform und testen Sie Ihre Fähigkeiten: [Hier starten]

リソースを表示
リソースを表示

Webサイトやアプリケーションでは、ユーザーが電子メールを使用してアプリケーションを通じてフィードバックやその他のさまざまな情報を送信できるのが一般的です。また、ほとんどの人は、潜在的なセキュリティリスクという観点からは考えていません。

もっと興味がありますか?

Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

mehr erfahren

Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.

デモを予約
シェア:
LinkedIn-MarkenSozialx Logo
Autor
ヤープ・キャラン・シン
Veröffentlicht Mar 21, 2019

Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

シェア:
LinkedIn-MarkenSozialx Logo

Heutzutage ist es üblich, dass Websites und Anwendungen den Benutzern erlauben, Feedback, Terminerinnerungen und verschiedene andere Informationen über eine Anwendung per E-Mail zu senden. Normalerweise ist dieser Vorgang ziemlich harmlos, und die meisten Leute denken nicht einmal über ein potenzielles Sicherheitsrisiko nach.

Wie jedes andere Designelement, das Benutzereingaben zulässt, können jedoch auch diese scheinbar unbedeutenden Funktionen, wenn sie nicht richtig konfiguriert sind, von böswilligen Benutzern für schändliche Zwecke manipuliert werden. Es genügt, dem Benutzer die Möglichkeit zu geben, Code in das Eingabefeld einzugeben, der dann fälschlicherweise vom Server verarbeitet wird. Plötzlich kann eine E-Mail-Anwendung zur Waffe werden.

In dieser Folge lernen wir:

  • Wie Angreifer eine E-Mail-Header-Injection auslösen können
  • Warum E-Mail-Header-Injektionen gefährlich sind
  • Techniken, die diese Sicherheitslücke beheben können.

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

Obwohl es nicht oft als programmierbar angesehen wird, können die meisten E-Mail-Kontaktanwendungen oder Funktionen, die in Websites oder Anwendungen eingebaut sind, Eingaben akzeptieren, die die Art der Abfrage ändern. Dies geschieht normalerweise automatisch durch den Server, nachdem ein Benutzer seine Informationen, wie z. B. seine E-Mail-Adresse, in das Vertragsfeld eingegeben hat. Das Programm konfiguriert dann die Nachricht, fügt die entsprechenden Empfänger hinzu und sendet die Nachricht über seinen Standard-E-Mail-Server.

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

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

Und generieren Sie Code, der so aussieht, nachdem ein Benutzer seine Informationen eingegeben hat:

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

Das Problem tritt auf, wenn Hacker beginnen, Code in den Prozess zu injizieren, anstatt nur ihre Kontaktdaten. Dies ist einem Angriff vom Typ SQL-Injection nicht unähnlich, richtet sich aber gegen die E-Mail-Anwendung. Ein Beispiel für eine manipulierte Abfrage, die stattdessen Spam aus Ihrer Anwendung an einen gezielten Benutzer senden würde, könnte so aussehen:

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

Warum ist Email Header Injection gefährlich?

Abhängig von der Geschicklichkeit des böswilligen Benutzers und seinen Absichten können E-Mail-Header-Injection-Angriffe in Bezug auf den Schweregrad von einfach nur lästig bis 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 bekannt gegebenes Postfach innerhalb Ihres Unternehmens gesendet wurde, und sie so einem Hacker zu offenbaren.

Noch bedenklicher ist, dass es ihnen erlauben könnte, Ihren E-Mail-Server vollständig zu kontrollieren, um Spam-, Phishing- oder andere Angriffs-E-Mails von Ihrer Organisation aus zu versenden. Sie bräuchten nicht zu versuchen, die Tatsache vorzutäuschen, dass die E-Mail von Ihren internen Servern kommt, da sie tatsächlich von dort stammen würde. Und 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 so aussieht, als würden Sie diese Aktivitäten tatsächlich veranlassen.

Eliminierung des E-Mail-Header-Injection-Problems

Wie bei SQL-Injection und anderen Angriffen dieser Art liegt der Schlüssel zum Ausschluss der Möglichkeit, dass ein böswilliger Benutzer eine E-Mail-Header-Schwachstelle ausnutzt, darin, den Benutzereingaben niemals zu vertrauen. Wenn ein Benutzer in der Lage ist, Informationen einzugeben, selbst wenn es sich um einen scheinbar 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.

Die Eingabevalidierung sollte für alle Parameter durchgeführt werden, auch beim Hinzufügen einer E-Mail-Kontaktmöglichkeit zu einer App oder Website. Whitelisting kann verwendet werden, um gezielt Prozesse und Felder zu aktivieren, die Sie als gültig erachten, während alles andere verweigert wird. Die meisten Frameworks verfügen über Bibliotheken, die dabei helfen können, Funktionen nur auf die benötigten zu beschränken. Auf diese Weise wird verhindert, dass Code oder Befehle, die von böswilligen Benutzern eingegeben werden, von Ihren Servern erkannt und verarbeitet werden.

Weitere Informationen über E-Mail-Header-Injektionen

Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über E-Mail-Header-Injektionen sagt. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Secure Code Warrior Plattform testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

Sind Sie bereit, eine E-Mail-Injection zu finden und zu beheben? Gehen Sie auf die Plattform und testen Sie Ihre Fähigkeiten: [Hier starten]

リソースを表示
リソースを表示

Um den Bericht herunterzuladen, füllen Sie bitte das folgende Formular aus.

Wir bitten um Ihre Erlaubnis, Ihnen Informationen zu unseren Produkten und/oder zu Themen rund um sicheres Programmieren zuzusenden. Wir behandeln Ihre personenbezogenen Daten stets mit größter Sorgfalt und verkaufen sie niemals zu Marketingzwecken an andere Unternehmen weiter.

送信
scw Erfolgssymbol
scw-Fehlersymbol
Um das Formular zu senden, aktivieren Sie bitte das „Analytics“-Cookie. Nach Abschluss der Einstellungen können Sie es wieder deaktivieren.

Heutzutage ist es üblich, dass Websites und Anwendungen den Benutzern erlauben, Feedback, Terminerinnerungen und verschiedene andere Informationen über eine Anwendung per E-Mail zu senden. Normalerweise ist dieser Vorgang ziemlich harmlos, und die meisten Leute denken nicht einmal über ein potenzielles Sicherheitsrisiko nach.

Wie jedes andere Designelement, das Benutzereingaben zulässt, können jedoch auch diese scheinbar unbedeutenden Funktionen, wenn sie nicht richtig konfiguriert sind, von böswilligen Benutzern für schändliche Zwecke manipuliert werden. Es genügt, dem Benutzer die Möglichkeit zu geben, Code in das Eingabefeld einzugeben, der dann fälschlicherweise vom Server verarbeitet wird. Plötzlich kann eine E-Mail-Anwendung zur Waffe werden.

In dieser Folge lernen wir:

  • Wie Angreifer eine E-Mail-Header-Injection auslösen können
  • Warum E-Mail-Header-Injektionen gefährlich sind
  • Techniken, die diese Sicherheitslücke beheben können.

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

Obwohl es nicht oft als programmierbar angesehen wird, können die meisten E-Mail-Kontaktanwendungen oder Funktionen, die in Websites oder Anwendungen eingebaut sind, Eingaben akzeptieren, die die Art der Abfrage ändern. Dies geschieht normalerweise automatisch durch den Server, nachdem ein Benutzer seine Informationen, wie z. B. seine E-Mail-Adresse, in das Vertragsfeld eingegeben hat. Das Programm konfiguriert dann die Nachricht, fügt die entsprechenden Empfänger hinzu und sendet die Nachricht über seinen Standard-E-Mail-Server.

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

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

Und generieren Sie Code, der so aussieht, nachdem ein Benutzer seine Informationen eingegeben hat:

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

Das Problem tritt auf, wenn Hacker beginnen, Code in den Prozess zu injizieren, anstatt nur ihre Kontaktdaten. Dies ist einem Angriff vom Typ SQL-Injection nicht unähnlich, richtet sich aber gegen die E-Mail-Anwendung. Ein Beispiel für eine manipulierte Abfrage, die stattdessen Spam aus Ihrer Anwendung an einen gezielten Benutzer senden würde, könnte so aussehen:

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

Warum ist Email Header Injection gefährlich?

Abhängig von der Geschicklichkeit des böswilligen Benutzers und seinen Absichten können E-Mail-Header-Injection-Angriffe in Bezug auf den Schweregrad von einfach nur lästig bis 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 bekannt gegebenes Postfach innerhalb Ihres Unternehmens gesendet wurde, und sie so einem Hacker zu offenbaren.

Noch bedenklicher ist, dass es ihnen erlauben könnte, Ihren E-Mail-Server vollständig zu kontrollieren, um Spam-, Phishing- oder andere Angriffs-E-Mails von Ihrer Organisation aus zu versenden. Sie bräuchten nicht zu versuchen, die Tatsache vorzutäuschen, dass die E-Mail von Ihren internen Servern kommt, da sie tatsächlich von dort stammen würde. Und 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 so aussieht, als würden Sie diese Aktivitäten tatsächlich veranlassen.

Eliminierung des E-Mail-Header-Injection-Problems

Wie bei SQL-Injection und anderen Angriffen dieser Art liegt der Schlüssel zum Ausschluss der Möglichkeit, dass ein böswilliger Benutzer eine E-Mail-Header-Schwachstelle ausnutzt, darin, den Benutzereingaben niemals zu vertrauen. Wenn ein Benutzer in der Lage ist, Informationen einzugeben, selbst wenn es sich um einen scheinbar 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.

Die Eingabevalidierung sollte für alle Parameter durchgeführt werden, auch beim Hinzufügen einer E-Mail-Kontaktmöglichkeit zu einer App oder Website. Whitelisting kann verwendet werden, um gezielt Prozesse und Felder zu aktivieren, die Sie als gültig erachten, während alles andere verweigert wird. Die meisten Frameworks verfügen über Bibliotheken, die dabei helfen können, Funktionen nur auf die benötigten zu beschränken. Auf diese Weise wird verhindert, dass Code oder Befehle, die von böswilligen Benutzern eingegeben werden, von Ihren Servern erkannt und verarbeitet werden.

Weitere Informationen über E-Mail-Header-Injektionen

Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über E-Mail-Header-Injektionen sagt. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Secure Code Warrior Plattform testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

Sind Sie bereit, eine E-Mail-Injection zu finden und zu beheben? Gehen Sie auf die Plattform und testen Sie Ihre Fähigkeiten: [Hier starten]

Online-Seminar ansehen
Beginnen wir
mehr erfahren

Klicken Sie auf den folgenden Link, um die PDF-Datei dieser Ressource herunterzuladen.

Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.

Bericht anzeigenデモを予約
PDF herunterladen
リソースを表示
シェア:
LinkedIn-MarkenSozialx Logo
もっと興味がありますか?

シェア:
LinkedIn-MarkenSozialx Logo
Autor
ヤープ・キャラン・シン
Veröffentlicht Mar 21, 2019

Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

シェア:
LinkedIn-MarkenSozialx Logo

Heutzutage ist es üblich, dass Websites und Anwendungen den Benutzern erlauben, Feedback, Terminerinnerungen und verschiedene andere Informationen über eine Anwendung per E-Mail zu senden. Normalerweise ist dieser Vorgang ziemlich harmlos, und die meisten Leute denken nicht einmal über ein potenzielles Sicherheitsrisiko nach.

Wie jedes andere Designelement, das Benutzereingaben zulässt, können jedoch auch diese scheinbar unbedeutenden Funktionen, wenn sie nicht richtig konfiguriert sind, von böswilligen Benutzern für schändliche Zwecke manipuliert werden. Es genügt, dem Benutzer die Möglichkeit zu geben, Code in das Eingabefeld einzugeben, der dann fälschlicherweise vom Server verarbeitet wird. Plötzlich kann eine E-Mail-Anwendung zur Waffe werden.

In dieser Folge lernen wir:

  • Wie Angreifer eine E-Mail-Header-Injection auslösen können
  • Warum E-Mail-Header-Injektionen gefährlich sind
  • Techniken, die diese Sicherheitslücke beheben können.

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

Obwohl es nicht oft als programmierbar angesehen wird, können die meisten E-Mail-Kontaktanwendungen oder Funktionen, die in Websites oder Anwendungen eingebaut sind, Eingaben akzeptieren, die die Art der Abfrage ändern. Dies geschieht normalerweise automatisch durch den Server, nachdem ein Benutzer seine Informationen, wie z. B. seine E-Mail-Adresse, in das Vertragsfeld eingegeben hat. Das Programm konfiguriert dann die Nachricht, fügt die entsprechenden Empfänger hinzu und sendet die Nachricht über seinen Standard-E-Mail-Server.

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

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

Und generieren Sie Code, der so aussieht, nachdem ein Benutzer seine Informationen eingegeben hat:

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

Das Problem tritt auf, wenn Hacker beginnen, Code in den Prozess zu injizieren, anstatt nur ihre Kontaktdaten. Dies ist einem Angriff vom Typ SQL-Injection nicht unähnlich, richtet sich aber gegen die E-Mail-Anwendung. Ein Beispiel für eine manipulierte Abfrage, die stattdessen Spam aus Ihrer Anwendung an einen gezielten Benutzer senden würde, könnte so aussehen:

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

Warum ist Email Header Injection gefährlich?

Abhängig von der Geschicklichkeit des böswilligen Benutzers und seinen Absichten können E-Mail-Header-Injection-Angriffe in Bezug auf den Schweregrad von einfach nur lästig bis 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 bekannt gegebenes Postfach innerhalb Ihres Unternehmens gesendet wurde, und sie so einem Hacker zu offenbaren.

Noch bedenklicher ist, dass es ihnen erlauben könnte, Ihren E-Mail-Server vollständig zu kontrollieren, um Spam-, Phishing- oder andere Angriffs-E-Mails von Ihrer Organisation aus zu versenden. Sie bräuchten nicht zu versuchen, die Tatsache vorzutäuschen, dass die E-Mail von Ihren internen Servern kommt, da sie tatsächlich von dort stammen würde. Und 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 so aussieht, als würden Sie diese Aktivitäten tatsächlich veranlassen.

Eliminierung des E-Mail-Header-Injection-Problems

Wie bei SQL-Injection und anderen Angriffen dieser Art liegt der Schlüssel zum Ausschluss der Möglichkeit, dass ein böswilliger Benutzer eine E-Mail-Header-Schwachstelle ausnutzt, darin, den Benutzereingaben niemals zu vertrauen. Wenn ein Benutzer in der Lage ist, Informationen einzugeben, selbst wenn es sich um einen scheinbar 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.

Die Eingabevalidierung sollte für alle Parameter durchgeführt werden, auch beim Hinzufügen einer E-Mail-Kontaktmöglichkeit zu einer App oder Website. Whitelisting kann verwendet werden, um gezielt Prozesse und Felder zu aktivieren, die Sie als gültig erachten, während alles andere verweigert wird. Die meisten Frameworks verfügen über Bibliotheken, die dabei helfen können, Funktionen nur auf die benötigten zu beschränken. Auf diese Weise wird verhindert, dass Code oder Befehle, die von böswilligen Benutzern eingegeben werden, von Ihren Servern erkannt und verarbeitet werden.

Weitere Informationen über E-Mail-Header-Injektionen

Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über E-Mail-Header-Injektionen sagt. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Secure Code Warrior Plattform testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

Sind Sie bereit, eine E-Mail-Injection zu finden und zu beheben? Gehen Sie auf die Plattform und testen Sie Ihre Fähigkeiten: [Hier starten]

目次

PDF herunterladen
リソースを表示
もっと興味がありますか?

Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

mehr erfahren

Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.

デモを予約[ダウンロード]
シェア:
LinkedIn-MarkenSozialx Logo
リソースハブ

Ressourcen für den Einstieg

Weitere Beiträge
リソースハブ

Ressourcen für den Einstieg

Weitere Beiträge