أدوات المطور · مولد UUID
لماذا يفشل crypto.randomUUID() في صفحات HTTP: شرح السياقات الآمنة
· كيف يعمل
uuid التشفير متصفح API
يعمل crypto.randomUUID على المضيف المحلي وعلى HTTPS، ثم يختفي على مضيف مرحلي عادي HTTP. يشرح هذا المنشور قاعدة السياق الآمن وراء هذا السلوك وكيفية إنشاء UUID بأمان حيثما ينطبق ذلك.
خطأ TypeError عند التدريج، وهو جيد في كل مكان آخر - وهو العرض واختلاف البيئة الذي يسببه
يقوم أحد المطورين بفحص عمله على المضيف المحلي:3000 ويعمل المولد UUID بشكل مثالي. يتم نشرهم للتدريج في http://staging. داخليًا. مثال. com (عادي HTTP على الشركة LAN) والكود يلقي TypeError: crypto.randomUUID ليس وظيفة. نفس الكود المستخدم في الإنتاج على https://example. com يعمل بشكل جيد. كان التناقض محيرًا حتى قرأوا مستندات MDN: crypto.randomUUID يقتصر على السياقات الآمنة. السياق الآمن هو إما HTTPS أو مضيف محلي؛ الأصل العادي HTTP على LAN ليس آمنًا بموجب قاعدة المتصفح، حتى لو كانت الشبكة خاصة. الإصلاح هو استخدام crypto.getRandomValues مع عمليات البت اليدوية، أو ترقية الخادم المرحلي إلى HTTPS. تم تقديم قاعدة السياق الآمن لمنع تسرب واجهات برمجة التطبيقات الحساسة إلى الاتصالات غير المشفرة.
ما هو السياق الآمن — قاعدة المتصفح التي تحتفظ بواجهات برمجة تطبيقات معينة لأصول HTTPS وللمضيف المحلي
يمكن اعتراض الصفحة الموجودة فوق HTTP بواسطة مهاجم الشبكة؛ إن تعريض واجهات برمجة التطبيقات المشفرة لمثل هذه الصفحة من شأنه أن يتيح للمهاجم إنشاء معرفات باستخدام API المخترق. يقوم HTTPS بتشفير الصفحة وجميع اتصالات API بحيث لا يتمكن أي مهاجم على الشبكة من اعتراض التعليمات البرمجية أو تعديلها. يتم التعامل مع المضيف المحلي على أنه آمن بطبيعته لأنه موجود فقط على الجهاز المحلي ولا يمكن اعتراضه عبر الشبكة. أي أصل HTTP آخر (عنوان LAN، مجال عام بدون HTTPS، وكيل عكسي يعيد التوجيه إلى HTTP) ليس آمنًا بحكم التعريف. يتم تقسيم تشفير الويب API إلى وظيفتين: crypto.randomUUID، يقتصر على السياقات الآمنة، وcrypto.getRandomValues، المتاحة في كل من السياقات الآمنة وغير الآمنة. كلاهما يستخدم نفس نظام التشغيل CSPRNG.
ما هي أجزاء Web Crypto الخاضعة للبوابات — crypto.randomUUID و crypto.subtle تتطلب سياقًا آمنًا بينما crypto.getRandomValues لا تتطلب ذلك
الفرق هو أن getRandomValues لا يخفي حقيقة أنك تستخدم التشفير؛ يجب أن تطلب الصفحة التي تستخدمها بشكل صريح وحدات بايت عشوائية. تعد وظيفة RandUUID بمثابة وسيلة راحة تفرض أيضًا سياقًا آمنًا. إذا كان تطبيقك يحتاج إلى إنشاء معرفات UUID على صفحة غير آمنة، فيجب عليك استخدام getRandomValues وتعيين الإصدار والبتات المتغيرة يدويًا. RFC 9562 يحدد عمليات البت: اضبط البايت 6 على (byte6 & 0x0f) | 0x40 للإصدار 4، والبايت 8 إلى (byte8 & 0x3f) | 0x80 للمتغير RFC. تقوم مكتبة ToolAcre بهذا بالضبط كإجراء احتياطي عندما لا يكون RandUUID متاحًا. إعادة إنتاج الفشل: اعرض صفحة بسيطة من أصل HTTP عادي لا يتم التعامل معه على أنه جدير بالثقة. تحقق مما إذا كان RandUUID مكشوفًا، ثم قارن getRandomValues، التي يسمح بها مرجع Web Crypto في سياقات غير آمنة.
إنشاء الإصدار 4 UUID من getRandomValues - الإجراء الاحتياطي للإخفاء والتنسيق الذي يبقيك على CSPRNG عندما يكون RandomUUID مفقودًا
نفس الكود الموجود في الملف الذي تم تقديمه عبر HTTPS يمكن أن يكشف عن عشوائيUUID. إذا كانت تقارير الإنتاج "randomUUID ليست وظيفة"، فافحص أولاً ما إذا كان الأصل سياقًا آمنًا، ثم تحقق من دعم المتصفح وما إذا كان برنامج نصي آخر قد حل محل كائن التشفير. قد يكون العلاج HTTPS أو تطبيق getRandomValues الذي يقوم بتعيين البتات UUID بشكل صريح. إن polyfill Math.random ليس بديلاً احتياطيًا مكافئًا: فهو يعيد إنتاج الشكل أثناء إسقاط عقد مصدر التشفير. الاختبارات التي تؤكد الشرطات وأرقام الإصدار فقط ستفقد هذا الاستبدال، لذا قم بمراجعة مسار المصدر بالإضافة إلى السلسلة الناتجة.
مثال عملي - إعادة إنتاج الفشل على http:// Origin وتأكيد الإصلاح
لكن المعرف أصبح الآن قابلاً للتنبؤ به. يمكن للمهاجم الذي يلتقط بعض UUIDs من نظامك التنبؤ بالمعرف التالي. إذا تعامل أحد التطبيقات عن طريق الخطأ مع هذا المعرف باعتباره بيانات اعتماد لحامله، فإن القدرة على التنبؤ تصبح بمثابة فشل في الترخيص وليس عيبًا تجميليًا. تتمثل الإستراتيجية الصحيحة في ترقية الخادم إلى HTTPS (الخطوة الصحيحة دائمًا لأي صفحة بها مصادقة أو بيانات حساسة) أو استخدام getRandomValues مع عمليات البت الصريحة (والتي تتطلب المزيد من التعليمات البرمجية ولكنها سليمة من الناحية التشفيرية). يتم فرض السياق الآمن بواسطة المتصفح؛ لا يمكنك التغلب عليها باستخدام متغيرات التكوين أو البيئة. تم نشر المولد ToolAcre عبر HTTPS، لذا فإن crypto.randomUUID متاح. عندما تقوم بإنشاء UUID في الأداة، فإنها تستخدم إما RandUUID (إذا نجح فحص السياق الآمن) أو getRandomValues مع عمليات البت (إذا كنت تستخدم HTTP عاديًا، على الرغم من أن هذا أمر نادر).
لماذا لا يجب عليك استخدام Math.random — الاختصار المغري وتكلفة الأمان التي يحملها
ولا يعود أي من المسارين إلى Math.random. إذا كنت تقوم بإنشاء منشئ UUID الخاص بك وتستهدف أصولًا غير آمنة، فاستخدم getRandomValues وقم بإجراء عمليات البت بنفسك. اختبر على كل من HTTPS والمضيف المحلي للتأكد من عمل RandUUID، ثم اختبر على http:// Origin للتأكد من صحة الإجراء الاحتياطي getRandomValues. يساعدك فهم قيود السياق الآمن على تصميم إستراتيجيات النشر. إذا كان يجب تشغيل تطبيقك على LAN خاص بدون HTTPS (البنية الأساسية القديمة والأنظمة المضمنة)، فإن الإجراء الاحتياطي getRandomValues هو طريقك للأمام. إذا كان لديك الخيار، فقم بالترقية إلى HTTPS في كل مكان؛ إنه مجاني مع Let's Encrypt، ويعود الاستثمار في الأمان عبر التطبيق بأكمله. التطوير على المضيف المحلي ليس له أي قيود، لذا اختبر مولد UUID الخاص بك على المضيف المحلي وعلى HTTPS قبل النشر إلى الإنتاج. يجب أن يكون الإنتاج دائمًا HTTPS.
ما لا يغطيه هذا — أوقات تشغيل الخادم مثل Node.js وDeno، والتي تعرض API بدون قاعدة سياق آمن
التقييد ليس خطأ أو إزعاجا؛ إنها ميزة أمنية تمنع وقوع الحوادث وتجبرك على التفكير في التشفير. النمط الأوسع هو أن واجهات برمجة التطبيقات لتشفير الويب تكون مُحاطة بسياق آمن. crypto.getRandomValues، تشفير. دقيق. تشفير، تشفير. دقيق. createKey، وجميع العمليات الحساسة الأخرى تتطلب HTTPS أو مضيفًا محليًا. لا يوجد استثناء، ولا تجاوز، ولا توجد طريقة لتعطيل الشيك. تؤدي صفحة واحدة غير آمنة إلى انتهاك الضمانات الأمنية للمستخدمين. حتى إذا كنت حريصًا على استخدام واجهات برمجة التطبيقات المشفرة فقط على صفحات معينة، فقد يؤدي خطأ (أو تبعية تتضمن مولد UUID) إلى تسرب عملية إنشاء العشوائية إلى صفحة غير مشفرة. يفرض المولد ToolAcre هذا على مستوى الكود: إذا لم يكن RandUUID متاحًا (سياق غير آمن)، فإنه يستخدم getRandomValues، وهو متاح ولكنه ينبه أي مراجع للتعليمات البرمجية بحدوث شيء غير عادي.
الخلاصة: أصلح الأصل، وليس المولد — يتم تقديم ToolAcre عبر HTTPS، بحيث يعمل المولد الخاص به في سياق آمن حسب التصميم
والأفضل من ذلك، أنه يرفض إنشاء معرف إذا كان السياق الآمن غير متاح حقًا (في البيئات التي لا يتوفر فيها getRandomValues أيضًا، وهو أمر نادر ولكنه ممكن في الأنظمة القديمة أو المدمجة). يعد ترحيل نظام موجود إلى HTTPS لدعم واجهات برمجة تطبيقات التشفير الآمنة مشروعًا شائعًا. ابدأ بالأصل حيث يتم إنشاء UUIDs (خادم المصادقة الخاص بك، API الخلفية، أو خدمة التطبيق الرئيسية). احصل على شهادة TLS (توفرها Let's Encrypt مجانًا). قم بتكوين خادم الويب الخاص بك لخدمة HTTPS افتراضيًا وإعادة توجيه HTTP الطلبات إلى HTTPS. اختبره باستخدام متصفحات متعددة وعملاء API للتأكد من أن كل شيء يعمل. ثم قم بمراجعة التعليمات البرمجية الخاصة بك بحثًا عن أي واجهات برمجة تطبيقات تشفير متبقية قد يتم استدعاؤها على الصفحات غير المشفرة وإصلاحها. يفترض المولد ToolAcre أن HTTPS; إذا كنت تستخدمه، فأنت بالفعل جزء من الطريق إلى هناك.