محتويات الدورة
أمان الويب
الأساسي: عقود الثقة والهوية في الويب
المتوسط: دفاعات المتصفح وتفسير البيانات
المتقدم: الضمان وسلسلة البناء والتعافي

أمان الويب / الأساسي: عقود الثقة والهوية في الويب / الدرس 1

HTTP وحدود الثقة في الويب

تتبّع الطلب عبر المتصفح والنقل والتطبيق والبيانات قبل تحديد ما تثبته الإشارة الأمنية.

وقت القراءة التقريبي: 4 دقيقةتاريخ مراجعة المحتوى
في هذه الصفحة

أهداف الدرس

  • ميّز دلالات HTTP من إذن التطبيق.
  • صف الأصل والموقع والوسيط والسياق الموثوق.

اتبع مسار الطلب والرد كاملاً

يعبر طلب الويب عدة نقاط لاتخاذ القرار: يختار المتصفح وجهة، وتحمي طبقة النقل اتصالاً، وقد يوجه وسيط الطلب أو يخزنه، ثم يفسر التطبيق البيانات ويفرض سياسته. تختلف المعلومات والسلطة المتاحة عند كل نقطة. لا يثبت نجاح الاتصال جواز كشف سجل، ولا يثبت نجاح حالة HTTP إتمام مهمة الأعمال. استخدم بوابة قراءة خيالية لتسمية الفاعل والمورد والفعل والنتيجة المقصودة. يتيح هذا النموذج السؤال عن طبقة الإنفاذ المناسبة، بدلاً من وضع كل فحص في النموذج الذي يراه المستخدم.

طابق معنى الطريقة مع تغيير الحالة

يحدد RFC 9110 دلالات HTTP، ومنها الطرق الآمنة وعدم تكرار الأثر والتمثيلات ومعنى الحالات. تعني الطريقة الآمنة أن العميل لا يطلب تغيير الحالة وفق دلالتها، مع إمكان حدوث تسجيل جانبي بالخادم. ويخص عدم تكرار الأثر النتيجة المقصودة للطلبات المتطابقة المتكررة، لا تطابق بايتات الرد أو انعدام كل أثر جانبي. لا تضع فعلاً مدمراً خلف تنقل GET وتتوقع من المتصفح إصلاح التصميم. اختر الطريقة والرد بقصد، ثم افحص الإذن وأصالة الطلب بصورة مستقلة. تقرأ الدورة سجلات اصطناعية ولا ترسل حركة HTTP.

سجل ما يجب أن يتحققه التطبيق

يسمي المثال فعل تحرير مقترحاً، ويفصل أسئلة النقل والهوية والإذن وأصالة الطلب. هو سجل تخطيط، وليس مسار خادم أو إعداد أمان. يحصل التنفيذ الحقيقي على سياق الفاعل من حد المصادقة الموثوق، ويحمّل نطاق المورد من تخزين موثوق. تبقى قيم المتصفح ادعاءات حتى التحقق؛ فلا يصير معرّف المالك الذي يرسله المستخدم سلطة لمجرد صحة صيغته. وضح عقد الرد أيضاً، بحيث يترك الرفض الحالة المحمية دون تغيير ولا يكشف تفاصيل خاصة.

json سجل اصطناعي لحدود الطلب 
{
  "operation": "edit-reading-note",
  "method": "POST",
  "transportRequired": "authenticated-HTTPS",
  "subjectRequired": "validated-session",
  "permissionRequired": "assigned-note-editor",
  "requestAuthenticity": "reviewed-for-session-model",
  "rejectionEffect": "no-protected-mutation"
}

لا يضبط الملف مساراً ولا يحوي جلسة فعلية. يصرح بمتطلبات منفصلة ولا يدعي تنفيذ أي منها. يحتاج الوسيط الخاص بالمنصة وسلوك المتصفح الفعلي تحققاً معتمداً مستقلاً.

ميّز الأصل من الموقع والهوية

يتحدد الأصل بالبروتوكول والمضيف والمنفذ. أما الموقع فمفهوم متصفح مختلف، تستخدمه سياسات مثل SameSite، وقد يجمع أصولاً وفق قواعد موثقة. لا يحدد أي منهما شخصاً ولا يثبت إذنه. يطبّع المحلل المحلي موقعين HTTPS اصطناعيين ويقارن أصلهما دون الاتصال. وهو يشرح مفهوماً محدوداً لحدود المتصفح، لا متحقق URL كاملاً أو محرك صلاحيات. تختلف قواعد ملفات الارتباط وCORS والأصل الواحد؛ فلا تدمجها في افتراض أن كل عنوان داخلي أو مألوف موثوق.

javascript مقارنة أصل كاملة دون اتصال 
const first = new URL("https://portal.example.invalid/notes")
const second = new URL("https://portal.example.invalid:443/profile")
const other = new URL("https://media.example.invalid/notes")
if (first.origin !== second.origin || first.origin === other.origin) {
  throw new Error("ORIGIN_MODEL_MISMATCH")
}

يعمل بـ Node ومحلل محلي فقط ونطاقات أمثلة محجوزة. يطبع منفذ HTTPS الافتراضي المصرح به إلى الأصل نفسه، بخلاف المضيف الآخر. لا يحدث DNS أو طلب متصفح أو إنفاذ أمني.

راجع الحدود التي يضيفها الوسيط

قد تغير الوكلاء العكسية والمخابئ وموازنات الحمل البيانات الوصفية الواصلة للتطبيق والردود المعاد استخدامها. لا تثق برؤوس هوية أو عنوان عميل محولة إلا ضمن إعداد وكيل موثوق صريح؛ فالرأس الاعتباطي ليس حقيقة متحققة. يجب أن تمنع مفاتيح المخبأ وسياسة الرد تقديم الخاص بين المستخدمين. سجل افتراضات النشر الفعلية واختبرها معزولاً بتفويض؛ فالمحلل المحلي لا يثبت سلوك الوكيل. تربط المراجعة البروتوكول والمتصفح والسياسة وملكية البيانات، مع الإبقاء على مجهول الطبقات غير المختبرة.

الأخطاء الشائعة وإصلاحها

يُعامل HTTPS كإذن قراءة سجل

لماذا يحدث؟
اختلطت مصادقة النقل بتفويض التطبيق.
كيف تصلحه؟
افحص الفاعل والمورد والفعل بحد الخدمة الموثوق.
كيف تتجنب تكراره؟
راجع كل ادعاء أمني منفصلاً.

يغير تنقل GET حالة حساسة

لماذا يحدث؟
يخالف السلوك عقد الطريقة الآمنة.
كيف تصلحه؟
أعد تصميم العملية وفحوص إذنها وأصالتها المستقلة.
كيف تتجنب تكراره؟
اختبر التغيير بحسب الطريقة والمسار.

يصير رأس العميل هوية موثوقة

لماذا يحدث؟
لم يحدد حد ثقة الوكيل والتطبيق.
كيف تصلحه؟
استخدم قواعد التكامل والوكيل المعتمدة.
كيف تتجنب تكراره؟
وثق وافحص افتراضات الوسيط.

اختبر فهمك

1. يشترك رابطان في المضيف ويختلف البروتوكول. هل الأصل نفسه؟

اعرض الحل المشروح

لا؛ فالبروتوكول جزء من ثلاثية الأصل مع المضيف والمنفذ. قارن الأصول المطبعة وفق قواعد المتصفح، ثم قيّم الموقع وملفات الارتباط والتفويض كلّاً على حدة. لا يثبت تشابه شكل العنوان أن الموقعين يقدمان ادعاء الثقة نفسه.

2. يعيد الطلب 200 ويعدل ملاحظة مستخدم آخر. ما الفاشل؟

اعرض الحل المشروح

فشل عقد تفويض الأعمال ونطاق المورد رغم نجاح معالجة HTTP. تحقق من سياق الفاعل الموثوق وشروط الملكية، ومن ثبات الحالة في حالات الرفض. لا يستطيع رمز الحالة وحده إثبات هذه الخصائص أو صحة الشخص الذي عُدلت ملاحظته.

أهم ما تعلمته

  • البروتوكول والمتصفح والنقل والسياسة طبقات مختلفة.
  • الأصل والموقع ليسا هوية المستخدم.
  • تُثبت الثقة عند كل حد.

المراجع الرسمية