Wie Unicode-Hostname-Aufforderungen das falsche Ziel genehmigen können

Eine Genehmigungskarte für die HTTP-Anfrage eines Agenten ist eine Sicherheitsgrenze und keine bloße Höflichkeitsbenachrichtigung. Wenn auf der Karte ein Ziel steht, der HTTP-Stack Zugangsdaten aber an ein anderes Ziel sendet, konnte die Person keine informierte Entscheidung treffen. Das Gateway hat an ihrer Stelle entschieden, nur mit einer schöneren Schrift.

Unicode macht solche Abweichungen leicht möglich, weil ein Hostname mehrere Formen hat, die ähnlich aussehen, aber unterschiedliche Aufgaben erfüllen. Eine Person sieht möglicherweise Unicode. DNS erhält ASCII-kompatible Labels. Ein URL-Parser kann Trennzeichen, Prozent-Escapes, Groß- und Kleinschreibung, IPv4-Schreibweisen oder ein leeres abschließendes Label normalisieren. Ein Weiterleitungs-Handler kann das nächste Ziel über einen anderen Codepfad parsen. Wenn eine Schicht eine Darstellung genehmigt und eine andere Schicht eine Verbindung mit einer anderen Darstellung herstellt, können Zugangsdaten bei der falschen Autorität landen.

Die Lösung lautet nicht «Nicht-ASCII-Domains verbieten». Das würde legitime internationalisierte Namen bestrafen und weiterhin ASCII-Tricks wie irreführende Subdomains, Userinfo, numerische IP-Formen und Weiterleitungsketten zulassen. Die Lösung besteht darin, einen einzigen geparsten Autoritätsdatensatz zum einzigen Objekt zu machen, das sowohl die Genehmigungsoberfläche erreichen als auch das Einfügen von Zugangsdaten autorisieren darf. Danach müssen die problematischen Eingaben getestet werden, bevor sie in die Produktion gelangen.

Die Genehmigungskarte muss die tatsächlich ausgeführte Anfrage beschreiben

Eine Genehmigungsaufforderung muss aus demselben kanonischen Anfrageobjekt stammen, das der HTTP-Client ausführt. Alles andere erzeugt zwei Wahrheiten: eine Darstellungszeichenfolge für Menschen und eine Transportzeichenfolge für den Code. Genau an dieser Trennung wird Hostname-Verwechslung zur Offenlegung von Zugangsdaten.

Bauen Sie die Anfrage in dieser Reihenfolge auf:

1. Akzeptieren Sie die rohe URL als nicht vertrauenswürdige Eingabe und parsen Sie sie genau einmal mit der für das Gateway ausgewählten URL-Implementierung.
2. Lehnen Sie nicht unterstützte Schemas, fehlerhafte Autoritäten, eingebettete Zugangsdaten und Eingaben ab, deren kanonische Form Ihre Hostname-Regeln verletzt.
3. Leiten Sie einen strukturierten Autoritätsdatensatz mit Schema, kanonischem Host, effektivem Port und einem Kennzeichen dafür ab, ob die Eingabe einen abschließenden Punkt der DNS-Wurzel enthielt.
4. Erzeugen Sie die Genehmigungskarte aus diesem Datensatz und übergeben Sie denselben Datensatz an den Code, der Zugangsdaten auswählt und einfügt.
5. Verlangen Sie eine neue Genehmigung, wenn eine Weiterleitung, ein Wiederholungsziel, ein Proxy-Ziel oder eine alternative Adresse den Autoritätsdatensatz verändert.

Eine rohe URL ist ein Beleg, aber keine Autorität. Bewahren Sie sie im Aktivitätsdatensatz auf, weil sie hilft zu erklären, was der Agent versucht hat. Verwenden Sie sie allein jedoch nicht für den Abgleich von Zugangsdaten, das Caching von Genehmigungen oder die Anzeige des Ziels.

Bei HTTP ist die Autorität mehr als ein bloßer Hostname. https://api.example.test:8443/ und https://api.example.test/ können zu unterschiedlichen Diensten und Zertifikatsrichtlinien führen. Der Standardport kann in der Anzeige weggelassen werden, sobald der Parser ihn festgestellt hat. Ein abweichender Port gehört jedoch auf die Karte. Zeigen Sie außerdem das Schema an. Ein Bearer-Token über http statt über https zu senden, verändert das Risiko, selbst wenn der Hosttext identisch ist.

RFC 3986 definiert den Hostteil als IP-Literal, IPv4-Adresse oder registrierten Namen. Das ist für die Syntax nützlich, sagt einem Genehmigungssystem aber nicht, was eine Person sicher erkennen kann. Betrachten Sie das Parsen als Voraussetzung und bauen Sie danach eine sicherheitsspezifische Darstellung um das geparste Ergebnis.

Punycode ist eine Kennung, kein verständlicher Name

Punycode gibt es, damit DNS internationalisierte Labels mit ASCII übertragen kann. Ein A-Label beginnt mit dem ASCII-Präfix xn, gefolgt von zwei Bindestrichen, während ein U-Label die entsprechende Unicode-Form ist. Die Umwandlung ist nur dann reversibel, wenn das Label nach den geltenden IDNA-Regeln gültig ist. Das ist wichtig, weil eine Zeichenfolge, die lediglich wie ein A-Label aussieht, nicht automatisch gültig oder sicher als Unicode darstellbar ist.

RFC 5891 verlangt von einer IDNA-fähigen Lookup-Anwendung, ein scheinbares A-Label zu validieren, bevor sie seine decodierte Unicode-Ausgabe als U-Label behandelt. Wenn eine Anwendung ein A-Label für die Anzeige in der Landessprache decodiert, sollte sie insbesondere prüfen, ob die erneute Umwandlung das ursprüngliche Label ergibt. Dieser Roundtrip ist keine akademische Übung. Ohne ihn kann eine Oberfläche fehlerhaftes ASCII in überzeugenden Unicode-Text verwandeln und der prüfenden Person eine Geschichte präsentieren, die der Transport tatsächlich nie erzählt hat.

Die Genehmigungskarte sollte bei internationalisierten Eingaben beide Formen anzeigen:

Destination
https://xn--example-ascii-label.test
Unicode rendering: example-unicode-label.test
Port: 443
Credential: deploy token

Setzen Sie den kanonischen ASCII-Hostnamen in eine eigene Zeile und verwenden Sie eine Festbreitenschrift oder eine ähnlich gut lesbare Darstellung. Verstecken Sie ihn nicht hinter einem Aufklappelement. Die Unicode-Darstellung hilft Menschen, einen legitimen Dienst zu erkennen. Die ASCII-Form ist jedoch die dauerhafte Kennung, die mit Allowlists, Audit-Einträgen, Cache-Schlüsseln und dem tatsächlichen DNS-Lookup-Pfad übereinstimmen sollte.

Decodieren Sie nicht jedes Label, nur weil es mit dem A-Label-Marker beginnt. Decodieren, validieren, erneut codieren und vergleichen Sie. Wenn die Validierung fehlschlägt, zeigen Sie das wörtliche ASCII-Label mit einer deutlichen Warnung an, dass der Hostname die IDNA-Validierung nicht bestanden hat. Die sichere Aktion besteht darin, das Einfügen von Zugangsdaten zu verweigern, nicht darin, zu erraten, was der Agent gemeint haben könnte.

Hier versagt eine verbreitete Empfehlung: «Immer Unicode anzeigen, weil Punycode verdächtig aussieht.» Dieser Rat erzeugt zwar eine freundliche Oberfläche, entfernt aber die einzige Darstellung, die über Schriften und Schriftsysteme hinweg stabil bleibt. Nur ASCII anzuzeigen, ist für einen legitimen internationalisierten Dienst ebenfalls schlechte Praxis. Zeigen Sie beides, machen Sie ASCII maßgeblich und stellen Sie sicher, dass beide Formen aus demselben validierten Parsergebnis stammen.

Gemischte Schriften verdienen eine Warnung, kein falsches Urteil

Ein Hostname, der lateinische und kyrillische Zeichen kombiniert, kann einem ASCII-Hostnamen fast vollständig gleichen. Ein Label kann beispielsweise einen kyrillischen Kleinbuchstaben enthalten, der in vielen Schriften wie das lateinische a, c, e, o, p oder x aussieht. Beim Überfliegen einer Genehmigungskarte kann eine prüfende Person die Ersetzung übersehen, besonders wenn der aussagekräftige Teil des Namens kurz ist.

Der Unicode Technical Standard #39 bezeichnet dies als Confusable mit gemischten Schriften, wenn Zeichenfolgen visuell verwechselbar sind und das Ergebnis keine Confusable mit nur einer Schrift ist. Er beschreibt außerdem Confusables ganzer Schriften, bei denen ein Label nur eine Schrift verwendet, aber einem Label aus einer anderen Schrift ähnelt. Der Standard weist offen auf die Grenze hin: Die Verwechselbarkeit hängt von Schriften, kontextabhängiger Formgebung und menschlicher Vertrautheit ab. Ein Detektor kann ein Risiko erkennen, aber nicht beweisen, dass ein Name täuschen soll.

Genau deshalb sollte ein Gateway die Prüfung auf gemischte Schriften nicht in eine automatische Blocklist verwandeln. Eine japanische, koreanische, chinesische, griechische oder mehrsprachige Organisation kann eine legitime Domain besitzen, die eine vereinfachte Regel verletzt. Verwenden Sie das Signal stattdessen, um die Genehmigung strenger zu behandeln:

• Kennzeichnen Sie jedes Label mit einem Ergebnis für gemischte Schriften als genehmigungspflichtig für jeden einzelnen Aufruf.
• Zeigen Sie Schriften und Codepunkte in einer Detailansicht an, wenn die prüfende Person den Host aufklappt.
• Vergleichen Sie das UTS-#39-Skelett des Hostnamens mit geschützten internen Namen und ausdrücklich konfigurierten wichtigen Zielen.
• Verweigern Sie die automatische Wiederverwendung von Zugangsdaten, wenn das Ziel einem geschützten Namen ähnelt, auch wenn es zuvor noch nicht aufgetreten ist.
• Protokollieren Sie Version und Ergebnis des Detektors im Aktivitätslog, damit die Entscheidung später nachvollzogen werden kann.

Das Skelett ist ein Vergleichsartefakt und kein Ersatz für den Hostnamen. UTS #39 sagt ausdrücklich, dass Skelettergebnisse nicht als Kennungen angezeigt, gespeichert oder übertragen werden sollen. Speichern Sie den kanonischen ASCII-Host. Verwenden Sie ein Skelett nur für eine eng begrenzte Frage: «Ähnelt dieser Kandidat einem Namen, den wir als besonders schützenswert eingestuft haben?»

Eine Menge geschützter Namen sollte klein und bewusst zusammengestellt sein. Nehmen Sie Ihre eigenen Bereitstellungsendpunkte, Paketregistries, Quellcode-Hosts, Identitätsanbieter sowie Zahlungs- oder Produktions-APIs auf. Erzeugen Sie keine riesige Liste jeder öffentlichen Domain, die wichtig sein könnte. Sonst entstehen Warnungen, die niemand mehr liest, und die eine Warnung, die zählt, wirkt alltäglich.

Unsichtbare Codepunkte machen die Prüfung zu einem Darstellungsproblem

Unsichtbare Zeichen sind schlimmer als offensichtlich nicht-ASCII-Zeichen, weil die prüfende Person sie nicht zuverlässig sehen kann. Je nach Zeichen und eingesetzter Software können sie das Verbinden von Zeichen, die Schreibrichtung, Zeilenumbrüche oder die Auswahl einer Glyphe beeinflussen. Manche werden von IDNA abgelehnt. Andere werden von Bibliotheken unterschiedlich abgebildet oder verarbeitet. Der Genehmigungsprozess darf nicht davon abhängen, dass jemand das Fehlen von Tinte bemerkt.

Teams vermischen häufig zwei verschiedene Fragen:

1. Ist dieser Codepunkt in einem IDNA-Hostname-Label gültig?
2. Kann dieser Codepunkt die Genehmigungsanzeige irreführend, das Protokoll mehrdeutig oder den Vergleichscode inkonsistent machen?

Die erste Frage mit Ja zu beantworten, erledigt die zweite nicht. IDNA hat Kontextregeln für bestimmte Codepunkte, und seine Lookup-Validierung lehnt mehrere Kategorien ungültiger Eingaben ab. Ein HTTP-Gateway verarbeitet jedoch auch rohe URLs, die Darstellung in der Oberfläche, JSON-Logs, kopierten Text und möglicherweise Hostformen außerhalb von DNS. Die Sicherheitsprüfung braucht Regeln für den gesamten Weg, nicht nur für die DNS-Gültigkeit. RFC 5891 sagt, dass IDNA für Domainnamen und nicht für beliebigen Freitext gedacht ist. Beschränken Sie es auf die Verarbeitung von Hostnamen und tun Sie nicht so, als würde es eine vollständige URL bereinigen.

Lehnen Sie einen Hostnamen vor dem Einfügen von Zugangsdaten ab, wenn seine geparste Unicode-Darstellung einen standardmäßig ignorierbaren Codepunkt, ein bidirektionales Steuerzeichen oder ein Zeichen enthält, das die gewählte IDNA-Implementierung als ungültig meldet. Das ist bewusst strenger als «Versuchen wir den Lookup und sehen, was passiert». Ein anonymer öffentlicher Browser kann einen Lookup versuchen. Ein Zugangsdaten-Gateway sollte jedoch kein Token senden, während es eine mehrdeutige Zeichenfolge untersucht.

Bewahren Sie beim Protokollieren einer abgelehnten Eingabe zwei Formen auf: eine sicher maskierte Codepunktfolge und die ursprüngliche Bytefolge oder den UTF-8-Text in einem Feld, das keiner stillen Normalisierung unterliegt. Ein guter Aktivitätseintrag enthält beispielsweise:

raw_host_escaped: "api\\u200d.example.test"
parsed_host_ascii: null
rejection: "default-ignorable code point in hostname display"
credential_attached: false

Setzen Sie den rohen Hostnamen nicht in einen Satz, den eine zuständige Person nur überfliegt. Logs werden bei der Reaktion auf Vorfälle oft zur nächsten Genehmigungsoberfläche. Wenn ein unsichtbares Zeichen in einem Terminal wieder unsichtbar wird, haben Sie die Falle nur verschoben.

Ein abschließender Punkt ist eine Information, auch wenn DNS ihn als Wurzel behandelt

Ein Hostname mit einem Punkt am Ende enthält keine bloße kosmetische Zeichensetzung. In der Darstellungsform von DNS bezeichnet der letzte Punkt das Wurzel-Label und markiert den Namen als absolut. RFC 1034 erklärt, dass jeder vollständige Domainname mit dem Wurzel-Label endet und die gedruckte Form deshalb mit einem Punkt abschließt.

Das bedeutet nicht, dass jede HTTP-Komponente api.example.test und api.example.test. gleich behandelt. Ein Parser kann den Punkt in seiner Hostname-Eigenschaft beibehalten. Ein anderer kann ihn vor dem Verbindungsaufbau normalisieren. Ein Zertifikatsprüfer, eine Cookie-Implementierung, ein Proxy, eine Allowlist oder ein Weiterleitungs-Cache kann sich wiederum anders verhalten. Die einzige sichere Regel lautet, zu entscheiden, ob Ihr Gateway beide Formen als gleichwertig behandelt, und diese Entscheidung in jeder Komponente zu testen, die die Anfrage verarbeitet.

Für ein Zugangsdaten-Gateway empfehle ich, die Eingabeinformation zu bewahren und die Autorität erst nach einer dokumentierten Vergleichsregel zu normalisieren. Speichern Sie beides:

input_host: "api.example.test."
canonical_dns_name: "api.example.test"
had_root_dot: true

Verwenden Sie dann canonical_dns_name, um den Ziel-Datensatz abzugleichen, zeigen Sie den abschließenden Punkt aber auf der Genehmigungskarte an, wenn er vorhanden war. Die prüfende Person sollte sehen, dass der Agent eine leicht ungewöhnliche Form geliefert hat. Ein normaler Punkt darf die Autorität nicht stillschweigend erweitern. Wenn eine Genehmigung für api.example.test erteilt wurde, darf eine Anfrage an api.example.test. diese Genehmigung nur wiederverwenden, wenn Parser, Resolver, TLS-Namensprüfer und Vergleichsregel des Gateways sich auf dasselbe Ziel einigen.

Entfernen Sie einen abschließenden Punkt nicht vor dem Parsen mit allgemeinem Zeichenketten-Code. Aus einem solchen Entfernen wird schnell «Host bereinigen», woraufhin bald Leerraum, Satzzeichen oder Unicode-Trennzeichen entfernt werden, die eigentlich eine Ablehnung hätten auslösen müssen. Erst parsen, dann nur Attribute normalisieren, für die eine schriftlich festgelegte semantische Regel existiert.

Die Parser-Testdaten brauchen feindselige Fälle, keine Beispiele aus einer Präsentation

Eine Hostname-Testsuite sollte die Übereinstimmung zwischen Parsing, Kanonisierung, Anzeige, Abgleich von Zugangsdaten, Verbindungsaufbau und Protokollierung prüfen. Es ist sinnvoll, einen Helfer zu testen, der ein Unicode-Label in ASCII umwandelt. Das beweist jedoch nicht, dass der Anfragepfad sicher ist.

Verwenden Sie für den ersten Durchlauf die URL-Laufzeitumgebung aus Ihrer Produktion. Das folgende Node-Skript prüft den WHATWG-URL-Parser und gibt die Felder aus, die ein Genehmigungs-Gateway vergleichen sollte. Es gibt absichtlich JSON aus, damit Unterschiede in CI gut lesbar sind.

const cases = [
  "https://example.test/",
  "https://example.test./",
  "https://münich.example.test/",
  "https://xn\\u002d\\u002dexample-ascii-label.test/",
  "https://pаypal.example.test/",
  "https://api\\u200d.example.test/",
  "https://[email protected]/",
  "https://example.test:8443/",
  "https://127.0.0.1./"
];

for (const raw of cases) {
  try {
    const u = new URL(raw);
    console.log(JSON.stringify({
      raw,
      href: u.href,
      protocol: u.protocol,
      hostname: u.hostname,
      host: u.host,
      port: u.port,
      username: u.username,
      passwordPresent: u.password.length \u003e 0
    }));
  } catch (error) {
    console.log(JSON.stringify({ raw, rejected: error.message }));
  }
}

Die erwartete Struktur der Ausgabe ist wichtiger als eine universell erwartete Zeichenfolge, weil sich Laufzeitumgebungen ändern und Regeln für Hostnamen je nach Plattform unterscheiden. Jeder akzeptierte Fall sollte genau einen kanonischen Hostnamen erzeugen, der alle nachfolgenden Stufen erreicht. Jeder abgelehnte Fall sollte beweisen, dass das Gateway keine Zugangsdaten anhängt und keine Netzwerkanfrage sendet.

Erweitern Sie die Testdaten um Labels aus Schriften, denen Ihr Team tatsächlich begegnet, Unicode-Zeichen ähnlich einem Punkt, Prozentkodierung im Host, führende kombinierende Zeichen, Klammern und IPv6-Formen, A-Labels in Großschreibung, fehlerhafte A-Labels, leere Labels, lokale Namen und Weiterleitungen. Fügen Sie Fälle aus Fehlerberichten hinzu. Die Testsuite wird nützlich, wenn sie die Zeichenfolgen enthält, die einen Entwickler beim Blick in eine Logdatei fluchen ließen, nicht wenn sie zehn Varianten von example.com enthält.

Der WHATWG URL Standard ist eine gute Grundlage für das Verhalten von Web-URLs, weil er Host-Parsing, Fehler bei prozentkodierten Hosts, die Umwandlung von Unicode in ASCII und Sonderfälle bei IPv4 beschreibt. Er erlaubt jedoch nicht die Annahme, dass jeder HTTP-Stack, jede DNS-Bibliothek und jedes UI-Widget identisch arbeitet. Führen Sie die Testdaten durch Ihren tatsächlichen Stack.

Weiterleitungen brauchen eine neue Autoritätsentscheidung

Die erste Genehmigung autorisiert nicht jeden Host, den eine Anfrage später besuchen könnte. Die Verarbeitung von Weiterleitungen liegt oft unterhalb des Anwendungscodes, der die Aufforderung angezeigt hat. Dadurch wird sie zu einer typischen Stelle, an der Zugangsdaten versehentlich weitergegeben werden.

Angenommen, ein Agent fordert https://build.example.test/artifact an. Die Person genehmigt ein Bereitstellungs-Token für diesen Host. Die Antwort leitet zu https://downloads.example.test/file oder, schlimmer noch, zu einem ähnlich aussehenden Unicode-Hostnamen weiter. Wenn der Client Weiterleitungen automatisch folgt und den Authorization-Header behält, hat das Gateway die Genehmigungsgrenze umgangen.

Verwenden Sie eine einfache Regel: Eine HTTP-Weiterleitung, die Schema, kanonischen Hostnamen oder effektiven Port verändert, macht die vorherige Autorisierung der Zugangsdaten ungültig. Das Gateway darf der Weiterleitung ohne Zugangsdaten folgen, wenn dies für den Vorgang sicher ist. Es muss jedoch anhalten, bevor es Zugangsdaten an der neuen Autorität einfügt. Zeigen Sie eine neue Genehmigungskarte an, die aus der neu geparsten URL erstellt wurde.

Trennen Sie außerdem eine Änderung der Origin von einer Pfadänderung. Eine Weiterleitung innerhalb desselben kanonischen Schemas, Hosts und Ports kann die Autorisierung behalten, wenn die Pfadregeln des Vorgangs das erlauben. Reduzieren Sie dies nicht auf einen Vergleich von Textpräfixen. https://api.example.test.evil.test/ beginnt mit einer beruhigend wirkenden Zeichenfolge, gehört aber zu einem anderen Host.

Bei Bearer-Tokens sollten Sie den Authorization-Header bei jeder Weiterleitung über eine andere Autorität standardmäßig entfernen. Bei Clientzertifikaten und SSH-ähnlichen Zugangsdaten kann die Transportschicht eine Identität bereits auswählen, bevor eine Weiterleitung überhaupt möglich ist. Das Gateway braucht deshalb eine gleichwertige Regel beim Aufbau der Verbindung. Das Prinzip bleibt gleich: Die Autorisierung ist an eine geparste Autorität gebunden, nicht an die ursprüngliche Absicht des Agenten.

Die Auswahl von Zugangsdaten braucht genaue Grenzen

Ein Gateway, das mehrere API-Schlüssel verwaltet, muss entscheiden, welcher Schlüssel an einen Host gesendet werden darf. Das ist keine Frage der Oberfläche. Hier wird ein Darstellungsfehler zu einer Netzwerkaktion.

Speichern Sie die Bindung eines Zugangsdatenobjekts als strukturierte Daten, zum Beispiel:

{
  "scheme": "https",
  "host_ascii": "api.example.test",
  "port": 443,
  "allow_subdomains": false,
  "require_per_call_approval": true
}

Vermeiden Sie eine Regel wie host.endsWith("example.test"). Sie akzeptiert notexample.test, und eine nachlässige Variante mit Prüfung eines vorangestellten Punkts kann Unicode-Normalisierung oder einen abschließenden Punkt der DNS-Wurzel weiterhin falsch behandeln. Wenn Sie Subdomains unterstützen, teilen Sie kanonische ASCII-Labels auf und vergleichen Sie die Labels von rechts nach links. api.example.test darf nur dann mit dem übergeordneten example.test übereinstimmen, wenn die Bindung Subdomains ausdrücklich erlaubt. Der übergeordnete Name darf niemals umgekehrt mit dem untergeordneten Namen übereinstimmen.

Halten Sie IP-Literale und registrierte Namen getrennt. Führen Sie keine umgekehrte DNS-Auflösung einer IP durch, um anschließend eine Hostname-Regel für Zugangsdaten anzuwenden. DNS-Namen können sich ändern, und Reverse-DNS beweist nicht, dass eine IP für ein API-Credential autorisiert ist. Lösen Sie ebenso wenig einen Hostnamen auf und genehmigen Sie dann jede Adresse, die er liefert. Die Zugangsdaten sind an den Hostnamen gebunden, der für TLS und die HTTP-Autorität verwendet wird. Verbindungsregeln können private, Loopback-, Link-Local- oder andere nicht erlaubte Adressen unabhängig davon begrenzen.

Ein Gateway sollte außerdem eine Bindung von Zugangsdaten und eine Genehmigung unterscheiden. Die Bindung beantwortet die Frage: «Dürfte dieses Credential hier überhaupt jemals verwendet werden?» Die Genehmigung beantwortet: «Hat eine Person diesen Agentenprozess autorisiert, es für diese Anfrage oder Sitzung zu verwenden?» Wenn diese Fragen vermischt werden, kann aus einer Allowlist ein unbeaufsichtigter Signierdienst werden.

Audit-Datensätze müssen bewahren, was die prüfende Person gesehen hat

Wenn eine Genehmigung später fragwürdig wirkt, müssen zuständige Personen drei Fragen beantworten können: Was hat der Agent gesendet, welche kanonische Autorität hat das Gateway ausgeführt und welchen genauen Text hat die prüfende Person gesehen? Eine einzige dargestellte URL kann nicht alle drei Fragen beantworten.

Zeichnen Sie diese Felder getrennt auf:

• die rohe URL oder eine sicher maskierte Darstellung davon;
• geparstes Schema, kanonischen ASCII-Hostnamen, effektiven Port und Pfad;
• validierte Unicode-Darstellung des Hostnamens, sofern vorhanden;
• Risikokennzeichen des Hostnamens wie abschließender Punkt der DNS-Wurzel, Ergebnis für gemischte Schriften, Übereinstimmung mit einem geschützten Namen und Ablehnung wegen unsichtbarer Zeichen;
• Genehmigungsentscheidung, Kennung der Zugangsdaten und die Information, ob das Gateway Zugangsdaten angefügt hat.

Machen Sie den Genehmigungsdatensatz unveränderlich, bevor der Client die Anfrage startet. Folgt der Client später einer Weiterleitung, erstellen Sie einen verknüpften untergeordneten Datensatz mit eigener geparster Autorität und Entscheidung. Eine Logzeile mit dem Text «genehmigte Anfrage erfolgreich» reicht nicht aus, wenn die relevante Tatsache darin besteht, dass der erste Host einen Location-Header zu einem zweiten Host zurückgegeben hat.

Die Trennung von Sitzungsjournal für Agentenläufe und Aktivitätsjournal für einzelne Aufrufe bei Sallyport ist eine sinnvolle Form für diese Belege: Die Sitzung zeigt, welcher Prozess Autorität erhalten hat, während der Aufrufdatensatz zeigt, welches Ziel sie genutzt hat. Das hashverkettete Audit-Log kann die Historie offline überprüfen. Die nützlichen Felder müssen aber weiterhin vor der Aktion erfasst werden. Ein manipulationssicheres leeres Feld ist immer noch ein leeres Feld.

Machen Sie verdächtige Hostnamen für den Agenten aufwendig, nicht für die prüfende Person verwirrend

Die sicherste Genehmigungsoberfläche verlangt nicht, dass eine Person innerhalb von zwei Sekunden zur Unicode-Spezialistin wird. Sie sorgt dafür, dass riskante Formen mehr Autorität vom Agenten verlangen, und gibt der prüfenden Person zugleich genügend Informationen für eine klare Entscheidung.

Verwenden Sie diese Verhaltensmatrix:

Gestalten Sie die Warnkarte nicht theatralisch. Eine Wand aus rotem Text bringt Menschen dazu, sie wegzuklicken. Nennen Sie den Grund in klarer Sprache: «Dieser Hostname mischt lateinische und kyrillische Zeichen» oder «Dieser Hostname enthält ein unsichtbares Unicode-Zeichen». Zeigen Sie danach den kanonischen ASCII-Host, die angeforderten Zugangsdaten und die Aktion. Menschen genehmigen Aktionen, keine Vorträge.

Der erste Test sollte eine Anfrage sein, die für eine unaufmerksame Person wie ein geschützter Host aussieht, aber zu einer anderen Autorität geparst wird. Führen Sie sie durch genau den Agenten-Shim, die Genehmigungsoberfläche, die Auswahl der Zugangsdaten, die HTTP-Bibliothek, den Weiterleitungscode und den Audit-Logger. Wenn irgendeine Stufe eine andere Hostnamen-Zeichenfolge erzeugt, ohne eine Ablehnung auszulösen, hat das Gateway noch immer zwei Wahrheiten. Beheben Sie das, bevor Sie eine weitere Richtlinienoption hinzufügen.