imported>MarcoMA8: /* Weblinks */ Nicht mehr erreichbare Weblinks ersetzt

2025-11-29T15:33:04Z

Weblinks: Nicht mehr erreichbare Weblinks ersetzt

Neue Seite

'''Header-Injection''' ist eine Klasse von Sicherheitslücken in Webanwendungen, welche auftreten, wenn die [[Header]] eines Protokolls dynamisch unter Hinzunahme von unzureichend geprüften Benutzereingaben generiert werden.

Header-Injection in [[HTTP]] kann z. B. zu [[HTTP-Response-Splitting]] und [[Cross-Site Scripting]] führen. Bei der dynamischen Erstellung von [[E-Mail]]s über eine Webanwendung kann ein Header-Injection-Angriff genutzt werden, um andere Empfänger in eine E-Mail einzutragen und so z. B. [[Spam]] zu versenden ([[E-Mail-Injektion]]).

== Beispiel ==
Eine Website hat ein Formular mit den Eingabefeldern für Betreff und Nachricht, über das Besucher dem Betreiber schreiben können. Ein serverseitiges Skript baut aus den übermittelten Daten dann die E-Mail-Nachricht zusammen und sendet diese an eine vordefinierte Adresse. Die resultierende E-Mail-Nachricht sieht dann z. B. so aus:

Subject: ''Betreff''
From: besucher@some.example.com
To: webmaster@some.example.com

''Nachricht''

Wenn nun ein Angreifer in das Eingabefeld des Formulars für den Betreff die Zeichenfolge [[Wagenrücklauf|Carriage Return]] und [[Zeilenvorschub|Linefeed]] sowie <code>BCC: user1@another.example.com, user2@another.example.com, …</code> eingibt und das Skript diese Eingaben ungeprüft in die E-Mail-Nachricht übernimmt:

Subject: '''Spam'''
'''BCC: user1@another.example.com, user2@another.example.com, …'''
From: besucher@some.example.com
To: webmaster@some.example.com

'''Spam'''

So wird die E-Mail ebenfalls als Blindkopie an User1, User2, … versendet.

Da einen Spammer die Antwort des Servers auf das Abschicken des E-Mail-Formulars nicht interessiert, kann er sich hinter [[IP-Spoofing]] verstecken. Der Administrator des Servers sieht dann in seinem Logfile, dass jede Spam-Mail von einer anderen IP-Adresse verschickt wurde. Der Spammer bleibt so völlig anonym.

Da der Webmaster auch eine Kopie des Spams erhält, wird er diese Sicherheitslücke aber baldmöglichst schließen.

== Gegenmaßnahmen ==
Zum Verhindern einer Header-Injection müssen Benutzereingaben sorgfältig geprüft werden, vor allem auf die je nach Kontext geltenden [[Metazeichen]].

So werden in der Regel die einzelnen Header-Felder durch die [[Zeilenumbruch|Zeilenumbruchsequenz CRLF]] getrennt. Deshalb gilt es, diese in Benutzereingaben herauszufiltern beziehungsweise zu maskieren. Beim [[HTTP]] und [[SMTP]] wird zum Maskieren z. B. die [[URL-Kodierung]] eingesetzt, beim SMTP zusätzlich noch die [[Quoted-Printable-Kodierung]].

=== PHP ===
In der weit verbreiteten Skriptsprache [[PHP]] wird seit den Versionen 4.4.2 bzw. 5.1.2 eine Injektion über die <code>header</code>-Funktion automatisch verhindert, indem nur ein HTTP-Header pro Funktionsaufruf zulässig ist.<ref>[https://www.php.net/manual/de/function.header.php Referenzseite der <code>header()</code>-Funktion] des [https://www.php.net/manual/de/ PHP-Handbuchs]</ref> Bei der <code>mail</code>-Funktion hingegen muss dies jedoch noch manuell gesichert werden.<ref>[https://www.php.net/manual/de/function.mail.php Referenzseite der <code>mail()</code>-Funktion] des [https://www.php.net/manual/de/ PHP-Handbuchs]</ref>

== Einzelnachweise ==
<references />

== Weblinks ==
* [https://outpost24.com/de/blog/http-request-smuggling-exploit-walkthrough/ Beispielhafte Beschreibung von HTTP Request Smuggling]
* [https://capec.mitre.org/data/definitions/273.html Eine Definition von HTTP Response Smuggling] (englisch)

[[Kategorie:Sicherheitslücke]]
[[Kategorie:HTTP]]
[[Kategorie:E-Mail]]

Header-Injection - Versionsgeschichte

imported>MarcoMA8: /* Weblinks */ Nicht mehr erreichbare Weblinks ersetzt