Blog

Coders Conquer Security: Share & Learn Series - Email Header Injection

Jaap Karan Singh
Veröffentlicht Mar 21, 2019

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]

Ressource anzeigen
Ressource anzeigen

Es ist üblich, dass Websites und Anwendungen den Benutzern erlauben, Feedback und verschiedene andere Informationen über eine Anwendung per E-Mail zu senden. Und die meisten Leute denken dabei nicht einmal an ein potenzielles Sicherheitsrisiko.

Interessiert an mehr?

Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Demo buchen
Weitergeben:
Autor
Jaap Karan Singh
Veröffentlicht Mar 21, 2019

Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.

Weitergeben:

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]

Ressource anzeigen
Ressource anzeigen

Füllen Sie das folgende Formular aus, um den Bericht herunterzuladen

Wir bitten Sie um Ihre Erlaubnis, Ihnen Informationen über unsere Produkte und/oder verwandte Themen der sicheren Codierung zuzusenden. Wir werden Ihre persönlichen Daten immer mit äußerster Sorgfalt behandeln und sie niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Senden
Um das Formular abzuschicken, aktivieren Sie bitte "Analytics"-Cookies. Sie können die Cookies wieder deaktivieren, sobald Sie fertig sind.

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]

Starten

Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Bericht ansehenDemo buchen
Ressource anzeigen
Weitergeben:
Interessiert an mehr?

Weitergeben:
Autor
Jaap Karan Singh
Veröffentlicht Mar 21, 2019

Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.

Weitergeben:

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]

Inhaltsübersicht

PDF herunterladen
Ressource anzeigen
Interessiert an mehr?

Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Demo buchenHerunterladen
Weitergeben:
Ressourcendrehscheibe

Ressourcen für den Einstieg

Mehr Beiträge
Ressourcendrehscheibe

Ressourcen für den Einstieg

Mehr Beiträge