Entwicklertools · UUID Generator
Warum crypto.randomUUID() auf HTTP-Seiten fehlschlägt: Sichere Kontexte erklärt
· Wie es funktioniert
UUID Kryptographie Browser-APIs
crypto.randomUUID funktioniert auf localhost und HTTPS und verschwindet dann auf einem reinen HTTP-Staging-Host. In diesem Beitrag wird die Secure-Context-Regel hinter diesem Verhalten erläutert und wie ein UUID sicher dort generiert wird, wo er gilt.
TypeError beim Staging, überall sonst in Ordnung – das Symptom und der Umgebungsunterschied, der ihn verursacht
Ein Entwickler überprüft seine Arbeit auf localhost:3000 und der UUID-Generator funktioniert einwandfrei. Sie werden im Staging bei http://staging. intern bereitgestellt. Beispiel. com (einfaches HTTP im Firmen-LAN) und der Code löst TypeError aus: crypto.randomUUID ist keine Funktion. Der gleiche Code in der Produktion auf https://example. com funktioniert einwandfrei. Die Inkonsistenz ist verblüffend, bis sie die MDN-Dokumente lesen: crypto.randomUUID ist auf sichere Kontexte beschränkt. Ein sicherer Kontext ist entweder HTTPS oder localhost; Ein reiner HTTP-Ursprung in einem LAN ist durch die Browserregel nicht sicher, selbst wenn das Netzwerk privat ist. Die Lösung besteht darin, crypto.getRandomValues mit manuellen Bitoperationen zu verwenden oder den Staging-Server auf HTTPS zu aktualisieren. Die Secure-Context-Regel wurde eingeführt, um zu verhindern, dass sensible APIs in unverschlüsselte Verbindungen gelangen.
Was ein sicherer Kontext ist – die Browserregel, die bestimmte APIs für HTTPS-Ursprünge und für localhost reserviert
Eine Seite über einfaches HTTP kann von einem Netzwerkangreifer abgefangen werden; Das Offenlegen kryptografischer APIs auf einer solchen Seite würde es einem Angreifer ermöglichen, mithilfe einer kompromittierten API Identifikatoren zu generieren. HTTPS verschlüsselt die Seite und die gesamte API-Kommunikation, sodass ein Angreifer im Netzwerk den Code nicht abfangen oder ändern kann. Localhost wird als inhärent sicher behandelt, da es nur auf dem lokalen Computer vorhanden ist und nicht über das Netzwerk abgefangen werden kann. Jeder andere HTTP-Ursprung (eine LAN-Adresse, eine öffentliche Domäne ohne HTTPS, ein Reverse-Proxy, der an HTTP weiterleitet) ist per Definition nicht sicher. Die Web Crypto API ist in zwei Funktionen aufgeteilt: crypto.randomUUID, beschränkt auf sichere Kontexte, und crypto.getRandomValues, verfügbar in sicheren und nicht sicheren Kontexten. Beide verwenden dasselbe Betriebssystem CSPRNG.
Welche Teile von Web Crypto sind geschützt – crypto.randomUUID und crypto.subtle erfordern einen sicheren Kontext, crypto.getRandomValues hingegen nicht
Der Unterschied besteht darin, dass getRandomValues nicht die Tatsache verbirgt, dass Sie Kryptografie verwenden; Eine Seite, die es verwendet, muss explizit zufällige Bytes anfordern. Die randomUUID-Funktion ist eine praktische Funktion, die auch einen sicheren Kontext erzwingt. Wenn Ihre Anwendung UUIDs auf einer nicht sicheren Seite generieren muss, müssen Sie getRandomValues verwenden und die Versions- und Variantenbits manuell festlegen. RFC 9562 gibt die Bitoperationen an: setze Byte 6 auf (byte6 & 0x0f) | 0x40 für Version 4 und Byte 8 bis (byte8 & 0x3f) | 0x80 für RFC-Variante. Die ToolAcre-Bibliothek führt genau dies als Fallback aus, wenn randomUUID nicht verfügbar ist. Reproduzieren des Fehlers: Stellen Sie eine einfache Seite von einem einfachen HTTP-Ursprung bereit, der nicht als potenziell vertrauenswürdig gilt. Überprüfen Sie, ob randomUUID verfügbar ist, und vergleichen Sie dann getRandomValues, was die Web Crypto-Referenz in unsicheren Kontexten zulässt.
Erstellen eines v4 UUID aus getRandomValues – dem Maskierungs- und Formatierungs-Fallback, der Sie auf dem CSPRNG hält, wenn randomUUID fehlt
Derselbe Code in einer über HTTPS bereitgestellten Datei kann randomUUID offenlegen. Wenn die Produktion „randomUUID ist keine Funktion“ meldet, überprüfen Sie zunächst, ob der Ursprung ein sicherer Kontext ist, überprüfen Sie dann die Browserunterstützung und ob ein anderes Skript das Kryptoobjekt ersetzt hat. Die Abhilfe kann HTTPS oder eine getRandomValues-Implementierung sein, die die UUID-Bits explizit setzt. Eine Math.random-Polyfüllung ist kein gleichwertiger Fallback: Sie reproduziert die Form, während der kryptografische Quellvertrag gelöscht wird. Tests, die nur Bindestriche und Versionsziffern bestätigen, werden diese Ersetzung übersehen. Überprüfen Sie daher den Quellpfad und die resultierende Zeichenfolge.
Funktioniertes Beispiel – Reproduzieren des Fehlers auf einem http://-Ursprung und Bestätigen des Fixes
Aber die Kennung ist jetzt vorhersehbar. Ein Angreifer, der ein paar UUIDs von Ihrem System erfasst, kann die nächste vorhersagen. Wenn eine Anwendung eine solche Kennung fälschlicherweise als Inhaberberechtigung behandelt, wird die Vorhersehbarkeit eher zu einem Autorisierungsfehler als zu einem kosmetischen Mangel. Die richtige Strategie besteht darin, den Server auf HTTPS zu aktualisieren (immer der richtige Schritt für jede Seite mit Authentifizierung oder sensiblen Daten) oder getRandomValues mit expliziten Bitoperationen zu verwenden (was mehr Code erfordert, aber kryptografisch einwandfrei ist). Der Browser erzwingt einen sicheren Kontext. Sie können es nicht mit Konfigurations- oder Umgebungsvariablen umgehen. Der ToolAcre-Generator wird über HTTPS bereitgestellt, sodass crypto.randomUUID verfügbar ist. Wenn Sie im Tool ein UUID generieren, verwendet es entweder randomUUID (wenn die sichere Kontextprüfung erfolgreich ist) oder getRandomValues mit Bitoperationen (wenn Sie einfaches HTTP verwenden, was jedoch selten vorkommt).
Warum Sie nicht mit Math.random polyfillen sollten – die verlockende Abkürzung und die damit verbundenen Sicherheitskosten
Keiner der Pfade greift auf Math.random zurück. Wenn Sie Ihren eigenen UUID-Generator erstellen und auf nicht sichere Ursprünge abzielen, verwenden Sie getRandomValues und führen Sie die Bitoperationen selbst durch. Testen Sie sowohl auf HTTPS als auch auf localhost, um zu bestätigen, dass randomUUID funktioniert, und testen Sie dann auf einem http://-Ursprung, um zu bestätigen, dass Ihr getRandomValues-Fallback korrekt ist. Wenn Sie die Einschränkung des sicheren Kontexts verstehen, können Sie Bereitstellungsstrategien entwerfen. Wenn Ihre Anwendung in einem privaten LAN ohne HTTPS (Legacy-Infrastruktur, eingebettete Systeme) ausgeführt werden muss, ist der getRandomValues-Fallback Ihr Weg nach vorne. Wenn Sie die Wahl haben, aktualisieren Sie überall auf HTTPS; Mit Let's Encrypt ist es kostenlos und die Investition zahlt sich in der Sicherheit der gesamten Anwendung aus. Für die Entwicklung auf localhost gibt es keine Einschränkungen. Testen Sie daher Ihren UUID-Generator auf localhost und im HTTPS-Staging, bevor Sie ihn in der Produktion bereitstellen. Die Produktion sollte immer HTTPS sein.
Was dies nicht abdeckt – Serverlaufzeiten wie Node.js und Deno, die die API ohne eine Secure-Context-Regel verfügbar machen
Die Einschränkung ist kein Fehler oder Ärgernis; Dabei handelt es sich um eine Sicherheitsfunktion, die Unfälle verhindert und Sie dazu zwingt, über Verschlüsselung nachzudenken. Das allgemeinere Muster besteht darin, dass Web-Kryptografie-APIs durch einen sicheren Kontext gesteuert werden. crypto.getRandomValues, Krypto. subtil. verschlüsseln, krypto. subtil. genericKey und alle anderen sensiblen Vorgänge erfordern HTTPS oder localhost. Es gibt keine Ausnahme, keine Außerkraftsetzung und keine Möglichkeit, die Prüfung zu deaktivieren. Eine einzelne unsichere Seite bricht die Sicherheitsgarantien für Ihre Benutzer. Selbst wenn Sie darauf achten, Krypto-APIs nur auf bestimmten Seiten zu verwenden, kann ein Fehler (oder eine Abhängigkeit, die einen UUID-Generator enthält) dazu führen, dass die Zufallsgenerierung auf eine unverschlüsselte Seite übertragen wird. Der ToolAcre-Generator erzwingt dies auf Codeebene: Wenn randomUUID nicht verfügbar ist (nicht sicherer Kontext), verwendet er getRandomValues, das verfügbar ist, aber jeden Codeprüfer darauf aufmerksam macht, dass etwas Ungewöhnliches passiert.
Takeaway: Korrigieren Sie den Ursprung, nicht den Generator – ToolAcre wird über HTTPS bereitgestellt, sodass sein Generator standardmäßig in einem sicheren Kontext ausgeführt wird
Besser noch: Es verweigert die Generierung einer Kennung, wenn der sichere Kontext wirklich nicht verfügbar ist (in Umgebungen, in denen getRandomValues auch nicht verfügbar ist, was selten vorkommt, aber in älteren oder eingebetteten Systemen möglich ist). Die Migration eines bestehenden Systems auf HTTPS zur Unterstützung sicherer Kryptografie-APIs ist ein häufiges Projekt. Beginnen Sie mit dem Ursprung, von dem UUIDs generiert werden (Ihr Authentifizierungsserver, API-Backend oder Schlüsselanwendungsdienst). Erwerben Sie ein TLS-Zertifikat (Let's Encrypt stellt es kostenlos zur Verfügung). Konfigurieren Sie Ihren Webserver so, dass er standardmäßig HTTPS bereitstellt und HTTP-Anfragen an HTTPS umleitet. Testen Sie mit mehreren Browsern und API-Clients, um sicherzustellen, dass alles funktioniert. Überprüfen Sie dann Ihren Code auf verbleibende Krypto-APIs, die möglicherweise auf unverschlüsselten Seiten aufgerufen werden, und beheben Sie diese. Der ToolAcre-Generator geht von HTTPS aus; Wenn Sie es nutzen, sind Sie bereits auf dem Weg dorthin.