URL-Parser vergleichen
Füge eine oder mehrere URLs (eine pro Zeile) ein, um Abweichungen zwischen Browser-/WHATWG-Parsing und älteren oder strengeren RFC-3986-Parsern in manchen Backend-Sprachen zu erkennen. Das kann ein Sicherheitsproblem und nicht nur ein Formatunterschied sein.
Die Verarbeitung erfolgt lokal in Ihrem Browser. Ihre Datei wird niemals hochgeladen.
Anleitung Tool
- Füge eine vollständige URL je Zeile ein; sie bleibt im Browser.
- Starte die URL-Analyse.
- Prüfe Abweichung, betroffene Parser und mögliche Bedeutung.
- Nutze Umschreibungen nur dort, wo sie eindeutig sicher sind. Userinfo- und Nicht-ASCII-Host-Mehrdeutigkeiten werden nicht geraten.
Annahmen
- Jede nicht leere Zeile gilt als vollständige URL; eingebettete URL-Fragmente werden nicht gesucht.
- Zeilen ohne Schema und ohne `//` werden als Klartext übersprungen.
- WHATWG-Seite nutzt den echten Browser-`URL`-Konstruktor. Die RFC-3986-Seite beschreibt dokumentiertes Parserverhalten; es wird keine Bibliothek einer anderen Sprache ausgeführt.
- Es werden sieben Unterschiede geprüft: Backslash-Normalisierung, Userinfo/Host-Verwechslung, zusätzliche führende Schrägstriche, Nicht-ASCII-/IDN-Hosts, schemabezogene relative URLs ohne Schema, eingebettete Leer-/Steuerzeichen und nicht kodierte Leerzeichen.
Quellen und Referenzdaten
Methodik
Statische Prüfungen auf die sieben dokumentierten Unterschiede. Sichere Normalisierungen wie Backslashes, überzählige Leerzeichen, zusätzliche Schrägstriche und wörtliche Leerzeichen werden vorgeschlagen. Userinfo und Nicht-ASCII-Hosts werden nicht umgeschrieben, weil der beabsichtigte Host nicht sicher ableitbar ist.
Rechenbeispiel
Userinfo-Verwechslung
Eingaben: https://trusted.com@evil.com/
Ergebnis: Vor `@` steht Userinfo; der tatsächliche Host ist evil.com, nicht trusted.com. Eine Prüfung per Textsuche kann dadurch umgangen werden.
Backslashes statt Schrägstrichen
Eingaben: https:\\example.com\path
Ergebnis: Browser normalisieren Backslashes bei Sonder-Schemata wie https oft zu Schrägstrichen. Andere Parser können einen anderen Host lesen oder scheitern. Sichere Normalisierung: `https://example.com/path`.
Zusätzliche führende Schrägstriche
Eingaben: https:///example.com
Ergebnis: Parser behandeln drei Schrägstriche nicht einheitlich. Vorschlag: kanonisches `https://example.com`.
Praktische Hinweise
- Prüfe Host und Ursprung mit einer URL-Bibliothek und vergleiche den tatsächlich geparsten Host; vertraue nicht `startsWith` oder `includes`.
- Behandle Backslashes in URLs als Warnsignal.
- Verwende ein explizites Schema, wenn mehrere Systeme die URL parsen.
Häufige Fehler
- Annehmen, eine URL zeige auf eine vertrauenswürdige Domain, weil sie optisch so aussieht.
- Eine erfolgreich geparste URL als gleichbedeutend in allen Laufzeiten ansehen.
Häufige Fragen
Warum ist Userinfo ein Fehler und ein Nicht-ASCII-Host nur ein Hinweis?
Die Userinfo-Verwechslung ist eine dokumentierte Umgehungsmethode ohne üblichen legitimen Nutzen in dieser Form. Internationale Domainnamen sind meist legitim; problematisch ist die unterschiedliche Parserbehandlung.
Öffnet oder ruft das Werkzeug die URL auf?
Nein. Es analysiert den Text lokal, besucht oder rendert die Adresse nicht.
Bedeutet ein unauffälliges Ergebnis, dass die URL sicher ist?
Nein. Es wurden nur die sieben benannten Parserabweichungen geprüft; andere Risiken oder bösartige Ziele werden nicht bewertet.
Zuletzt geprüft:
Statischer Textprüfer, kein zweiter aktiver Parser. Relative URLs werden nicht aufgelöst, Weiterleitungen nicht verfolgt und URLs nicht über die sieben benannten Fälle hinaus auf Bösartigkeit bewertet.
Design- und Tool-Einstellungen sowie gespeicherte und zuletzt verwendete Listen werden nur in diesem Browser gespeichert.