URL zerlegen

Die Zerlegung stammt aus der eingebauten `URL`-Schnittstelle und nicht aus einem selbstgeschriebenen regulären Ausdruck. Das ist der Punkt, an dem sich Werkzeuge dieser Art unterscheiden: Die WHATWG-Spezifikation für URLs ist voller Regeln, die man beim Selbstbauen nicht ahnt, und genau in denen entstehen die interessanten Fehler.

Ein Beispiel ist die Normalisierung des Hosts: Groß- und Kleinschreibung wird vereinheitlicht, ein abschließender Punkt entfernt, internationalisierte Namen werden nach Punycode umgesetzt. Ein regulärer Ausdruck lässt all das stehen — und dann meldet er einen Unterschied zwischen zwei Adressen, die für jeden Browser dieselbe sind.

In `https://[email protected]/` ist der Host `evil.example` und nicht `example.com` — alles vor dem Klammeraffen sind Zugangsdaten. Das ist regelkonform und die Grundlage einer der ältesten Phishing-Techniken überhaupt, weil das Auge beim ersten vertrauten Namen hängen bleibt.

Genau deshalb ist der Host hier eine eigene Zeile. Wer eine verdächtige Adresse prüft, muss nicht abzählen, sondern liest ab, wohin sie tatsächlich zeigt. Ergänzend gilt: Ein Bindestrich-Name wie `example.com.evil.example` ist ebenso eine Adresse bei `evil.example`, denn das letzte Namenspaar vor dem Ende entscheidet.

Die Adresse wird zerlegt und nicht besucht. Es gibt keine Anfrage an den Host, keine Vorschau, keinen Weiterleitungsauflöser — und das ist eine Entscheidung, keine fehlende Funktion. Wer eine verdächtige URL untersucht, will als Letztes, dass das Werkzeug sie aufruft.

Ein Aufruf würde zudem etwas verraten: Die Anfrage käme von einem Server, ihre IP-Adresse und der Zeitpunkt landeten im Log des Gegenübers, und bei einer einmalig gültigen Adresse — ein Bestätigungslink, ein Passwort-Zurücksetzen — würde sie dabei verbraucht. Zerlegen ist die harmlose Operation, und nur die findet hier statt.

Ein `..` im Pfad wird beim Zerlegen aufgelöst: Aus `/docs/a/../b` wird `/docs/b`. Das ist Teil der Normalisierung und nicht etwas, das dieses Werkzeug zusätzlich tut — jeder Browser macht es, bevor er die Anfrage stellt, und ein Server sieht deshalb nie die ursprüngliche Form.

Wichtig ist das bei allem, was Pfade vergleicht oder auf ihnen Rechte prüft. Wer eine Zugriffsregel gegen die rohe Zeichenkette prüft statt gegen den normalisierten Pfad, prüft etwas anderes als das, was tatsächlich abgerufen wird — eine Lücke, die unter dem Namen Path Traversal seit Jahrzehnten dieselbe ist.

Alles nach dem `#` bleibt im Browser. Es wird nicht mitgeschickt, erreicht keinen Server und taucht in keinem Zugriffsprotokoll auf. Das ist eine Eigenschaft von HTTP und keine Datenschutzfunktion, und es schneidet in beide Richtungen.

Nützlich ist es, weil ein Wert im Anker den Server nicht erreicht — historisch der Grund, warum OAuth-Tokens dort transportiert wurden. Unangenehm ist es, weil er trotzdem im Browserverlauf, in der Referrer-Kette mancher Skripte und in jedem geteilten Link steht. „Erreicht den Server nicht“ heißt nicht „ist privat“.

Ist der Port der für das Schema übliche — 443 bei https, 80 bei http —, lässt der Parser ihn weg, weil er redundant ist. `https://example.com:443/` und `https://example.com/` sind dieselbe Adresse, und die Normalisierung macht das sichtbar.

Das ist regelmäßig die Erklärung dafür, warum ein Vergleich zweier URL-Zeichenketten scheitert, obwohl beide dasselbe meinen. Wer URLs vergleicht, sollte sie vorher durch einen Parser schicken und die normalisierte Form vergleichen — genau die, die hier in den Zeilen steht.

Ein Tippfehler wie `htp://example.com` wird nicht abgelehnt, sondern als Adresse mit dem Schema `htp` gelesen. Das ist kein Fehler des Parsers: Die Spezifikation lässt beliebige Schemata zu, weil es Hunderte gibt — `mailto:`, `tel:`, `git+ssh:`, `spotify:` — und ein Parser nicht wissen kann, welche in deiner Welt gültig sind.

Praktisch heißt das: Wenn hier ein Schema steht, das du nicht erwartet hast, hast du deinen Tippfehler gefunden. Und es heißt, dass eine Prüfung nach dem Muster „lässt sich das parsen“ keine Prüfung ist, ob eine Adresse ins Web zeigt — dafür muss man das Schema ausdrücklich gegen eine Liste halten.

Die Form `https://benutzer:passwort@host/` gibt es noch, und sie begegnet einem in alten Skripten, in Datenbank-Verbindungszeichenketten und in Beispielen aus Dokumentationen. Browser haben die Unterstützung eingeschränkt, weil sie ideal für Phishing war, aber Bibliotheken und Kommandozeilenwerkzeuge akzeptieren sie weiterhin.

Der Benutzername wird hier angezeigt, das Passwort nicht — es steht als maskierter Hinweis da, dass eines vorhanden ist. Der Grund ist banal und zählt trotzdem: Diese Ergebnisse landen regelmäßig in einem Screenshot oder in einem Ticket, und ein Passwort, das man ohnehin schon hat, muss dort nicht noch einmal abgedruckt werden.

Ein Host mit Umlauten wird nach Punycode umgesetzt: Aus `münchen.example` wird `xn--mnchen-3ya.example`. Das ist die Form, die tatsächlich im DNS steht, denn das Namenssystem kennt nur ASCII — die lesbare Schreibweise ist eine Anzeigehilfe des Browsers.

Sichtbar zu machen, was wirklich abgefragt wird, hat einen Sicherheitsnutzen. Homographen-Angriffe benutzen Zeichen aus anderen Schriften, die lateinischen zum Verwechseln ähneln; in der Punycode-Form fällt das sofort auf, weil dort statt eines vertrauten Namens eine Buchstabensuppe steht.

URLs aus Logs und Analytics-Exporten sind selten harmlos: Sie enthalten Sitzungskennungen, Tokens aus Bestätigungslinks, gelegentlich E-Mail-Adressen als Parameter. Weil hier in der Seite zerlegt wird, verlässt nichts davon dein Gerät, und es entsteht keine Auftragsverarbeitung für den Inhalt.

Dazu kommt der zweite Punkt, der dieser Seite eigen ist: Die Adresse wird auch nicht aufgerufen. Ein Werkzeug, das das täte, würde dem Betreiber der Zieladresse mitteilen, dass jemand diesen Link untersucht — und bei einem einmalig gültigen Link würde es ihn dabei entwerten.

Diese Seite listet die Query-Parameter mit auf, sie beantwortet aber eine andere Frage: Wohin zeigt diese Adresse und aus welchen Teilen besteht sie. Die häufigsten Anlässe sind ein verdächtiger Link, eine kaputte Weiterleitung und ein Vergleich zweier Adressen, die gleich sein sollten.

Wer dagegen einen Query-String aus einem Analytics-Export vor sich hat, hat gar keine ganze URL, sondern ein Bruchstück, und interessiert sich für wiederholte Schlüssel, für verschachtelte URLs in Parameterwerten und für die Frage, ob ein Wert noch kodiert ist. Dafür gibt es die zweite Seite, und sie erklärt genau das.