Trennen Sie Internationalisierung von Identitätswechsel
Internationalisierte Domänennamen ermöglichen die Verwendung von Domänenbezeichnungen, die über die herkömmlichen ASCII-Buchstaben, Ziffern und Bindestriche hinausgehen. Diese Fähigkeit ist legitim und wichtig. Das Sicherheitsrisiko besteht nicht im Vorhandensein eines bestimmten Skripts; Es geht darum, ob eine angezeigte Kennung in einem Folgekontext mit einer anderen Identität verwechselt werden kann. Eine Homograph- oder Confusable-Domain-Untersuchung muss daher den tatsächlichen Namen, seine validierte DNS Darstellung und die Darstellung des Empfängers bewahren, ohne jeden Nicht-ASCII-Namen als bösartig zu deklarieren.
RFC 5890 definiert die Terminologie für internationalisierte Domänennamen in Anwendungen, einschließlich A-Labels und U-Labels. Technischer Unicode-Standard 39 beschreibt Mechanismen zur Identifizierung verwechselbarer Zeichenfolgen. Dabei handelt es sich um verwandte, aber unterschiedliche Aufgaben. Die Repräsentation und Gültigkeit von IDNA ist kein Urteil über die Zugehörigkeit; Ein Verwechselbarkeitsvergleich ist kein Beweis für einen Betrug. Dieser Artikel schlägt eine defensive Überprüfungsmethode vor, ohne Namen zu registrieren, Nachrichten zu senden oder verdächtige Domänen zu besuchen.
Bewahren Sie die Formulare auf, anstatt sie zu reduzieren
RFC 5890 Abschnitt 2.3.2.1 definiert ein A-Label als die ASCII-kompatible Form eines IDNA-gültigen Labels und ein U-Label als dessen Unicode-Form unter den angegebenen Anforderungen. Nicht jede Zeichenfolge, die mit dem bekannten Präfix xn-- beginnt, ist ein gültiges A-Label. Ein Parser muss die Beziehung validieren, anstatt das Präfix allein als Beweis zu betrachten. Ebenso ist eine beliebige Unicode-Zeichenfolge nicht automatisch ein gültiges U-Label, nur weil sie wie ein Domänenlabel aussieht.
Behalten Sie den beobachteten Rohwert vor der Transformation bei. Notieren Sie dann den verwendeten Parser und die verwendete Version, die von ihm erstellten validierten Etikettenformulare und etwaige Fehler. Behalten Sie den angezeigten Wert des E-Mail-Clients als separate Beobachtung bei. Ein Screenshot kann das Erscheinungsbild dokumentieren, aber er kann die zugrunde liegenden Codepunkte oder die analysierte Adresse nicht ersetzen. Dieses Manuskript verfügt über kein Normalisierungstool und liefert keine angeblich gemessenen Konvertierungen. Tatsächliche Beispiele müssen in einer autorisierten Beweisaufnahme erstellt und aufbewahrt werden.
Ein verwechselbares Skelett ist kein DNS Name
Unicode TR39 beschreibt die verwechselbare Erkennung mithilfe definierter Transformationen und Daten. Das beibehaltene aktuelle Dokument enthält eine richtungsbewusste Skelettverarbeitung und weist darauf hin, dass Vergleiche zu umfassend sein können. Ein Skelett ist ein Vergleichsartefakt. Es sollte nicht als abzufragende Adresse, Domäne zur Zulassungsliste oder als Wert zur Veröffentlichung im DNS verwendet werden. Zwei mit einer Vergleichsmethode übereinstimmende Zeichenfolgen werden nicht zur gleichen Domäne und erhalten nicht den gleichen Eigentümer.
Notieren Sie die Unicode-Datenversion, den Algorithmus und die relevanten Richtungsannahmen, wenn Sie eine solche Methode verwenden. Vereinfachen Sie die aktuelle Spezifikation nicht in eine undokumentierte Anweisung, Kleinbuchstaben zu schreiben und visuell ähnliche Zeichen zu ersetzen. Das wäre ein anderer Algorithmus mit unbekanntem Verhalten. Wenn ein Produkt einen Ähnlichkeitswert bietet, behalten Sie die Methode und Einschränkungen des Produkts getrennt vom Standard bei. Eine Bewertung kann die menschliche Überprüfung priorisieren, ohne eine böswillige Absicht oder das tatsächliche Anzeigeverhalten des Empfängers festzustellen.
Die Darstellung richtet sich nach der jeweiligen Anwendung
Die gleiche zugrunde liegende Domäne kann in verschiedenen Anwendungen und Kontexten unterschiedlich dargestellt werden. Versprechen Sie nicht, dass jeder E-Mail-Client Unicode anzeigt, immer ein ASCII-Formular bereitstellt oder ständig vor gemischten Skripten warnt. Ein aktuelles Empfängerergebnis erfordert eine tatsächliche Beobachtung des relevanten Client-, Versions-, Plattform- und Nachrichtenkontexts. Dieser Artikel hat diese Beobachtungen nicht durchgeführt und erhebt daher keinen Anspruch darauf, dass ein bestimmter Anbieter einen bestimmten Testnamen anzeigen oder blockieren würde.
Bewahren Sie bei der späteren Sammlung autorisierter Beweise sowohl die reine Identität als auch das, was der Benutzer gesehen hat. Geben Sie an, ob die Adresse erweitert oder reduziert wurde, ob der Anzeigename separat angezeigt wurde und welche Schnittstelle eine Warnung ausgegeben hat. Vermeiden Sie die Verallgemeinerung eines Screenshots auf alle Empfänger. Auch die Überprüfung der Barrierefreiheit ist wichtig: Eine visuelle Ähnlichkeit und eine gesprochene Wiedergabe können zu unterschiedlichen Verständnisproblemen führen, aber keines davon sollte ohne ein entsprechendes beobachtetes Beispiel behauptet werden.
Die Authentifizierung folgt Domänen, nicht der wahrgenommenen Ähnlichkeit
RFC 9989, Abschnitt 2.2, besagt dies DMARC befasst sich nicht mit visuell ähnlichen Domainnamen oder dem Missbrauch von Anzeigenamen. Eine separate Domäne kann E-Mails selbst dann authentifizieren, wenn ein Empfänger sie mit einer vertrauenswürdigen Organisation verwechselt. Das ist kein Grund, mit der Überprüfung aufzuhören Ausrichtung. Es ist ein Grund, die Unterscheidung zwischen der tatsächlichen Domäne und der Identität, die der Empfänger aus ihrem Aussehen abgeleitet hat, beizubehalten.
Verwenden Sie vertrauenswürdige Authentifizierungsnachweise für Empfänger und beachten Sie dabei die Bedenken hinsichtlich der Vertrauensgrenzen in RFC 8601. Notieren Sie, welche Domäne authentifiziert wurde und welche sichtbare Absenderdomäne ausgewertet wurde. Ersetzen Sie diese Domänen nicht durch ein verwirrendes Grundgerüst, bevor Sie ihre Beziehung beurteilt haben. Das Normalisieren einer Anzeige zum Vergleich darf die untersuchte Protokollidentität nicht stillschweigend ändern. Behalten Sie das Authentifizierungsergebnis und das Problem der menschlichen Erkennung als verknüpfte, aber unterschiedliche Beobachtungen bei.
Ein Arbeitsblatt zur Identitätsdarstellung
Erstellen Sie ein Arbeitsblatt mit dem ursprünglichen Nachrichtenfeld, der roh extrahierten Domäne, der Codepunktdarstellung (sofern erforderlich), validierten A-Label- und U-Label-Formularen, der Parser-Version, dem Validierungsergebnis und dem angezeigten Client-Formular. Fügen Sie das Vergleichsziel aus einem vertrauenswürdigen Geschäftsdatensatz, die Methode und Version zur Erkennung von Verwechslungen, das Vergleichsergebnis, die Herkunft der Empfängerauthentifizierung und die angeforderte Aktion hinzu. Fügen Sie separate Spalten für beobachtete Fakten und Analysteninterpretationen hinzu.
Schwärzen Sie aus Datenschutzgründen nicht verwandte Nachrichteninhalte und persönliche Identifikatoren und behalten Sie dabei die genauen Domänenunterscheidungen bei, die für den Fall erforderlich sind. Veröffentlichen Sie eine wirklich verdächtige Domain nicht als anklickbaren Link, nur um das Arbeitsblatt zu veranschaulichen. Verwenden Sie eine genehmigte nicht interaktive Beweispräsentation. Wenn für den Unterricht fiktive Zeichenfolgen verwendet werden, kennzeichnen Sie diese als illustrativ und behaupten Sie nicht, dass sie registriert, von einem Anbieter akzeptiert oder von einem Empfänger angezeigt wurden. Ein erfundenes Ergebnis des Empfängers würde den Zweck der Beweispflicht zunichte machen.
Fiktive Diagnose: ein Name, der bekannt vorkommt
Einem fiktiven Beschaffungsanalysten fällt auf, dass in einer Lieferantennachricht scheinbar ein bekannter Name verwendet wird, eine erweiterte Adressansicht jedoch eine andere zugrunde liegende Domäne offenbart. Das Sicherheitsteam schlägt vor, die Rohadresse beizubehalten und validierte Darstellungen mithilfe eines dokumentierten Tools zu vergleichen. Zum jetzigen Zeitpunkt hat das Team Bedenken hinsichtlich der Verwechslung und nicht wegen des Nachweises einer böswilligen Absicht oder eines Besitzes. Die angeforderte Änderung des Lieferantendatensatzes bleibt im Rahmen des normalen Geschäftsprozesses angehalten.
Das Team würde die Zugehörigkeit anhand eines Lieferantenkontakts überprüfen, der bereits unabhängig erfasst wurde. Es würde auch Beweise für den tatsächlichen Empfänger behalten, wenn eine autorisierte Untersuchung fortgesetzt wird. Der hypothetische Fall beinhaltet bewusst keine erfundene Unicode-Konvertierung, keine Skelettausgabe oder die Behauptung, dass ein benannter Mail-Client eine bestimmte Zeichenfolge angezeigt habe. Dabei handelt es sich um Beobachtungen, die gesammelt werden müssen, und nicht um Details, die der Einfachheit halber ergänzt werden müssen. Während dieser Arbeit wurde keine Domain abgefragt, registriert oder zum Versenden von E-Mails verwendet.
Veröffentlichung nur mit den erforderlichen Beispielen
Eine vertretbare Schlussfolgerung unterscheidet gültige Darstellung, Ähnlichkeit, Zugehörigkeit, Authentifizierung und beobachteten Schaden. Es kann festgestellt werden, dass eine Vergleichsmethode eine Verwechslung festgestellt hat, ohne eine Straftat zu beanspruchen. Es kann angegeben werden, dass eine andere Domäne authentifiziert wurde, ohne die Geschäftsanfrage zu zertifizieren. Es kann die Präsentation eines Empfängers dokumentieren, ohne zu behaupten, dass sich jeder Empfänger gleich verhält. Diese Unterscheidungen machen die daraus resultierenden Leitlinien sowohl für legitime internationalisierte Namensgebung als auch für Ermittlungen wegen Identitätsdiebstahls nützlich.
Der Katalog erfordert rohe und angezeigte Identitätsbeispiele mit normalisierten DNS Formularen und Empfängerergebnissen. Diese ursprünglichen Beobachtungen bleiben offen. Dieses Manuskript enthält ein Arbeitsblatt und einen fiktiven Diagnoseprozess, nicht diese Beweise. Auch die Prüfung durch menschliche Spezialisten, die Anwendbarkeit der Quelle, Produktionswege, die visuelle Zugänglichkeit und die Freigabe durch den Eigentümer bleiben offen. Für die Veröffentlichung sind aufbewahrte, autorisierte Beispiele mit genauen Tool-Versionen und beobachteten Ergebnissen erforderlich, die überprüft werden, ohne dass unnötige persönliche Daten preisgegeben werden oder unbegründete Behauptungen über einen Domain-Betreiber aufgestellt werden.