Trennen Sie den Nachrichtenaufbau von der Domänenauthentifizierung
Eine Anwendung kann eine korrekt authentifizierte Nachricht senden, die sie niemals hätte erstellen dürfen. SPF, DKIM Und DMARC Beantworten Sie Fragen zu Sendeberechtigungen, Signaturen usw Domänenausrichtung. Sie entscheiden nicht darüber, ob ein Kontaktformular Empfänger auswählen durfte, ob ein Betrefffeld als weiterer Header interpretiert wurde oder ob ein Workflow die Anfrage genehmigt hat. Diese Unterscheidung ist wichtig für Passwortbenachrichtigungen, Supportformulare, Rechnungen und alle Anwendungen, die E-Mails aus externen Eingaben zusammenstellen. Ein erfolgreiches DMARC Ergebnis ist kein Ersatz für die Validierung dieser Eingabe vor der Nachrichtenserialisierung.
RFC 9989 schließt Inhaltsanalyse und Authentifizierung anderer Entitäten als Domänen ausdrücklich von den Zielen von DMARC aus. Diese Grenze ist der Ausgangspunkt für dieses Bedrohungsmodell und kein Grund, die Authentifizierung zu schwächen. Sorgen Sie für eine einheitliche Authentifizierung und steuern Sie separat, wie Anwendungen Nachrichten erstellen. Dieses Manuskript schlägt defensive Überprüfungsschritte vor. Es reproduziert keinen Exploit, sendet keine Nachrichten, überprüft keine echte Anwendung und stellt keine Angriffsnutzlast bereit.
Verstehen Sie die Serialisierungsgrenze
RFC 5322, Abschnitt 2.2, beschreibt ein Header-Feld als einen Feldnamen, gefolgt von einem Doppelpunkt und einem Feldkörper, abgeschlossen durch CRLF. Die Norm beschreibt auch das Falten und Entfalten langer Felder. Das sind Regeln für das Nachrichtenformat. Sie bedeuten nicht, dass ein beliebiges Formularfeld Kopfzeilentrennzeichen oder Fortsetzungszeilen bereitstellen darf. Eine Anwendung muss Daten, die für ein Feld bestimmt sind, von der Struktur unterscheiden, die Felder trennt.
Header-Injection ist der Fehlermodus, bei dem extern gesteuerte Daten diese strukturelle Grenze überschreiten und sich auf Header auswirken, die über ihre vorgesehene Position hinausgehen. Seine praktischen Auswirkungen hängen von der Mailbibliothek, der API, dem Transport und dem Autorisierungsmodell ab. Gehen Sie nicht davon aus, dass jede von einem Webformular akzeptierte neue Zeile unverändert SMTP erreicht. Gehen Sie auch nicht davon aus, dass ein nachgelagerter Unterzeichner eine unsichere Bauentscheidung repariert. Eine Signatur kann die Nachricht abdecken, die die Anwendung tatsächlich erzeugt hat, einschließlich eines unerwünschten, aber syntaktisch gültigen Ergebnisses.
Inventareingabe und Autorität, bevor Sie sich für die Validierung entscheiden
Erstellen Sie eine Feldkarte für die Anwendung. Notieren Sie, woher ein Wert stammt, welche Komponente ihn analysiert, welchen beabsichtigten Typ er hat, wer ihn bereitstellen darf und wo er landet. Unterscheiden Sie ein Anzeigeetikett von einer Adresse, einen Betreff von einem Text und sichtbare Empfängerfelder vom Transportumschlag. Eine von einem Besucher übermittelte Kontaktadresse sollte nicht automatisch zu einer autorisierten Adresse werden Umschlagabsender. Die Kundenkennung eines Supportformulars sollte nicht als uneingeschränkte Empfängerliste behandelt werden.
Definieren Sie zunächst geschäftliche Einschränkungen. Manche Anwendungen benötigen genau einen Empfänger, der aus einer internen Zuordnung ausgewählt wird; andere unterstützen rechtmäßig mehrere zugelassene Empfänger. Freier Text ist im Hauptteil möglicherweise zulässig, in einem Routing-Feld jedoch nicht. Legen Sie Grenzen für Größe und Kardinalität fest und lehnen Sie unerwartete Strukturzeichen ab, wenn der Feldvertrag dies verbietet. Hierbei handelt es sich um vorgeschlagene Anwendungsanforderungen und nicht um die Behauptung, dass RFC 5322 eine Validierungsimplementierung für jede Sprache oder jedes Produkt vorschreibt.
Bevorzugen Sie eine strukturierte Konstruktion und überprüfen Sie dann deren Verhalten
Verwenden Sie die unterstützte strukturierte E-Mail-Schnittstelle für das ausgewählte Framework, anstatt komplette Kopfzeilen aus der Eingabe manuell zu verketten. Der Python EmailMessage-Dokumentation veranschaulicht diese Trennung: Das Objekt stellt Header und Nutzlast dar, bietet Feldoperationen an und serialisiert gemäß einer E-Mail-Richtlinie. Außerdem wird gewarnt, dass die Reduzierung Änderungen wie die Generierung MIME Grenzen auslösen kann. Diese dokumentierten Funktionen stellen nicht sicher, dass jede Anwendung, die diese Klasse verwendet, sicher ist oder dass alle Bibliotheksversionen dieselben ungültigen Eingaben ablehnen.
Überprüfen Sie die tatsächliche Bibliotheksversion und Richtlinie in der Anwendung, bevor Sie sich auf deren Handhabung verlassen. Führen Sie vor dem Erstellen der Nachricht eine Validierung durch und führen Sie eine separate Autorisierungsprüfung für Ziele durch. Vermeiden Sie eine Reparaturroutine, die verdächtige Zeichen stillschweigend entfernt und die Bedeutung eines Werts ändert. Eine vorhersehbare Ablehnung mit einem sicheren Fehler ist oft einfacher zu begründen als ein Wert, der in einen anderen Empfänger umgewandelt wird. Protokollieren Sie niemals Passwörter, setzen Sie Token zurück oder füllen Sie vertrauliche Benachrichtigungstexte aus, nur um den Aufbau zu debuggen.
Ein Arbeitsblatt zur zerstörungsfreien Abnahme
Erstellen Sie eine Arbeitsblattzeile für jeden Eingabe-zu-Ausgabe-Pfad. Geben Sie die Anwendungskomponente, das Eingabefeld, den erwarteten Typ, die zulässige Zielquelle, Parser- und Serializer-Versionen, die Validierungsentscheidung und das erwartete beobachtbare Ergebnis an. Fügen Sie eine Spalte für den Prüfer hinzu, dem der Feldvertrag gehört. Ein Geschäftsinhaber kann das beabsichtigte Empfängerverhalten genehmigen, während ein Techniker prüft, wie die Implementierung es durchsetzt. Keine der Genehmigungen sollte aus einem E-Mail-Authentifizierungs-Dashboard abgeleitet werden.
Vorgeschlagene lokale Fälle können einen normalen kurzen Betreff, einen leeren erforderlichen Wert, einen Überlängenwert, unerwartete Steuerzeichen, die als Testmetadaten dargestellt werden, und eine Anzeigebezeichnung mit Satzzeichen umfassen. Bewahren Sie die Hüllen in einem isolierten Kabelbaum auf, der keine Verbindung zu einem Postdienst herstellen kann. Überprüfen Sie die analysierte Nachrichtenstruktur, anstatt einen Exploit an einen Produktionsempfänger zu senden. Akzeptanz bedeutet, dass das vorgesehene Feld innerhalb seines Vertrags bleibt, unbefugte Empfänger über diesen Eingabepfad ausgeschlossen sind und Fehler behandelt werden, ohne dass Geheimnisse preisgegeben werden. Für dieses Manuskript wurde kein solcher Kabelbaum ausgeführt.
Fiktive Diagnose: eine Unterstützungsform mit gemischten Verantwortlichkeiten
Stellen Sie sich ein fiktives Unternehmen vor, Cedar Support, dessen Formular es einem Besucher ermöglicht, eine Antwortadresse und eine Beschreibung der Anfrage einzugeben. Ein Entwickler lässt auch einen Abfrageparameter die Ziel-Support-Warteschlange auswählen. Die Nachricht besteht DMARC , da sie vom zugelassenen Dienst von Cedar signiert wird. Das Team betrachtet dieses Ergebnis zunächst als Beweis dafür, dass das Formular sicher ist. Es ist weder ein Beweis für die Autorisierung des Empfängers noch für die Eingabevalidierungsregeln.
Die vorgeschlagene Untersuchung trennt zwei Fragen. Erstens: Ist der Warteschlangenparameter nur genehmigten internen Zielen zugeordnet? Zweitens: Kann ein beliebiger Freitextwert die Struktur der serialisierten Nachricht ändern? Das Team würde die örtlichen Bauleistungen und Genehmigungsentscheidungen überprüfen, ohne E-Mails zu versenden. Selbst wenn der Serialisierer fehlerhafte Header-Daten ablehnt, könnte ein uneingeschränkter Zielparameter ein eindeutiger Missbrauchspfad bleiben. Umgekehrt beweist eine korrekte Ziel-Zulassungsliste nicht, dass jedes Header-Feld sicher erstellt ist. Hierbei handelt es sich um ein erfundenes Diagnoseszenario, nicht um eine entdeckte Schwachstelle oder einen abgeschlossenen Test.
Freigabekriterien und Beweise sind noch erforderlich
Dokumentieren Sie, was jede Schicht beweist. Durch die Eingabevalidierung wird festgestellt, dass die übermittelten Daten dem Vertrag der Anwendung entsprechen. Durch die Autorisierung wird festgelegt, ob dieser Akteur dieses Ziel oder diese Aktion anfordern darf. Die Serialisierung erzeugt das beabsichtigte Nachrichtenformat. Die Authentifizierung hilft empfangenden Systemen bei der Bewertung der Domänennutzung. Die Zustellungsüberwachung verrät, was danach geschah. Die Kombination dieser Schichten ist gerade deshalb sinnvoll, weil keine allein die anderen beweist.
Der Katalog erfordert ein vertretbares Bedrohungsmodell und eine zerstörungsfreie Laborreproduktion, die an die ursprüngliche Forschung gebunden ist. Diese Beweise sind noch offen. Dieser Entwurf enthält ein vorgeschlagenes Modell und Arbeitsblatt, keine Originalforschung oder Laborreproduktion. Während der Recherche angeforderte OWASP-Seiten waren nicht verfügbar und werden nicht als Unterstützung zitiert; Sie wurden nicht über eine andere Route erneut versucht. Ein qualifizierter Anwendungsprüfer muss die Implementierung überprüfen, ein kontrolliertes Labor muss seine tatsächlichen Beobachtungen aufbewahren und die Anwendbarkeit der Quelle, Produktionswege, Zugänglichkeit und Eigentümerfreigabe müssen vor der Veröffentlichung überprüft werden. Es sind keine Produktionseingaben, Anmeldeinformationen oder echte Nachrichten erforderlich, um die hier beschriebene Grenze zu verstehen.