دورة معهد ماساتشوستس للتكنولوجيا "أمن أنظمة الكمبيوتر". المحاضرة 8: نموذج أمن الشبكات ، الجزء 2

معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 6.858. "أمن أنظمة الكمبيوتر." نيكولاي زيلدوفيتش ، جيمس ميكنز. 2014 سنة

أمان أنظمة الكمبيوتر هي دورة حول تطوير وتنفيذ أنظمة الكمبيوتر الآمنة. تغطي المحاضرات نماذج التهديد ، والهجمات التي تهدد الأمن ، وتقنيات الأمان بناءً على العمل العلمي الحديث. تشمل الموضوعات أمان نظام التشغيل (OS) ، والميزات ، وإدارة تدفق المعلومات ، وأمان اللغة ، وبروتوكولات الشبكة ، وأمان الأجهزة ، وأمان تطبيقات الويب.

المحاضرة 1: "مقدمة: نماذج التهديد" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 2: "السيطرة على هجمات القراصنة" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 3: "تجاوزات العازلة: المآثر والحماية" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 4: "فصل الامتيازات" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 5: "من أين تأتي أنظمة الأمن؟" الجزء 1 / الجزء 2
المحاضرة 6: "الفرص" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 7: "وضع حماية العميل الأصلي" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 8: "نموذج أمن الشبكات" الجزء 1 / الجزء 2 / الجزء 3

فماذا يحدث إذا لم يقم المتصفح بمعالجة الكائن بشكل صحيح ولم يتمكن من تحديد نوعه؟ في هذه الحالة ، قد يكون لديك مشاكل أمنية. واحد منهم يسمى هجوم MIME.

من المحتمل أنك على دراية بـ MIME - هذا هو نوع من الرؤوس غير المشفرة مثل text / html و image.jpeg وما إلى ذلك. لذا ، استخدمت الإصدارات القديمة من متصفح IE هذا لأنهم اعتقدوا أنه سيساعد المستخدم. ولكن في بعض الأحيان يحدث أن تقوم خوادم الويب بتعيين الامتداد الخطأ لملف الكائن.

يمكن لخادم الويب الذي تمت تهيئته بشكل غير صحيح إرفاق اللاحقة .html بما يحتوي عليه بالفعل .jpeg ، أو العكس ، على سبيل المثال ، إنشاء foo.jpg بدلاً من foo.html.



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

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



لكن الحقيقة هي أن IE يمكنها أولاً "شم" هذه الصورة ، أول 256 بايت. ويمكن للمهاجم وضع كود HTML وجافا سكريبت عمدًا هناك. ثم اتضح أن موقع الضحية سيجلب ما يعتبره صورة ، وسوف يقوم IE بتنفيذ تعليمات برمجية ضارة في سياق الصفحة المضمنة.

هذا نوع من المثال عن مدى تعقيد المتصفحات وكيف يمكن أن تؤدي إضافة النية الحسنة جدًا إلى حدوث أخطاء أمنية دقيقة للغاية. لذلك دعونا نلقي نظرة فاحصة على كيفية حماية المتصفح للموارد المختلفة.

دعونا نلقي نظرة على الإطارات وكائنات النافذة (الكائنات التي تحتوي على نافذة تحتوي على مستند DOM). تمثل الإطارات عوالم JavaScript المستقلة التي تحدثنا عنها هنا. أعني ، جافا سكريبت هي نسخة من عقدة DOM ، كما هو موضح في صورة شجرة DOM.

بهذه الطريقة ، سيكون الإطار موجودًا ككائن عقدة DOM في مكان ما في هذا التسلسل الهرمي المرئي لـ JavaScript.

في JavaScript ، يعد كائن النافذة اسمًا مستعارًا لمساحة الاسم العامة. تبدو فكرة غبية. بمعنى ، إذا وجدت اسم المتغير العام x ، فستتمكن أيضًا من الوصول إليه من خلال نافذة الاسم x.

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

على سبيل المثال ، قد يبدأ إطار مثل هذا: .xyzcom ، هنا يمكنك تجاهل النظام والبروتوكول لمدة ثانية.

في هذه الحالة ، يمكننا أن نفترض أن مصدر أصل (document.domain) هو اللاحقة yzcom. وبالمثل ، فإن مصدر المنشأ لهذه الوثيقة هو التعبير z.com. هذا ممكن لأن z.com لاحقة yzcom.



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

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

الجمهور: اتضح أنه من الممكن عمل مثل هذه الانقسامات في أي وقت أو عند نقطة النهاية؟ على سبيل المثال ، هل يمكن تغيير xyzcom إلى z.com الخاص بك؟

البروفيسور: لا ، هذا ينطبق فقط على كل نقطة.



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

البروفيسور: نعم هذا صعب ، لذا فهناك عدة إجابات على هذا السؤال. أولاً ، كان الناس قلقين للغاية من احتمال وقوع هجوم باستخدام .com. لذلك ، أرادوا جعل لغة التلاعب بالمجال سهلة الفهم. وبالتالي ، لم يسمحوا بإفساد الإعدادات.

في ثانية سأتحدث عن شيء واحد يسمح لك بفعل ما تتحدث عنه ، ولكن فقط فيما يتعلق بلاحقات النطاق. في الوقت الحالي ، أود أن أشير إلى أن واجهة Post Message تسمح للنطاقات بالتواصل مع بعضها البعض إذا وافقوا على ذلك. لذا في الممارسة العملية ، يستخدم الأشخاص Post Message لتنفيذ الاتصال عبر النطاقات إذا لم يتمكنوا من إنشاء نفس المصدر الأصلي باستخدام الحيل الموضحة أعلاه. بهذه الطريقة ، يمكن للمتصفحات تقييد النطاقات وفقًا لواحق المجال المصدر هذه. وهنا أيضًا هناك فارق بسيط صغير مثير للاهتمام - فهم المتصفحات متى يمكن كتابة (document.domain) ومتى لا يمكن ذلك.

هناك سبب لذلك ، والذي سننظر فيه خلال ثانية. وبالتالي ، يمكن لإطارين الوصول إلى بعضهما البعض إذا تحقق شرط واحد على الأقل من الشرطين التاليين:

• كلتا مجموعتي الإطارات (document.domain) لها نفس القيمة ؛
• لا يمكن تغيير أي من هذه الإطارات (document.domain) ، على الرغم من أن قيمة هذا المستند في كلا الإطارين هي نفسها.

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

تخيل أن لديك نطاق xyzcom يحاول مهاجمة نطاق yzcom لأن المجال الأول يحتوي على خطأ أو ضار. سيحاول تقصير نطاق yzcom لإلقاء نظرة .com ، ثم يبدأ في "المعالجة الكيميائية" بحالة جافا سكريبت ، أو ملفات تعريف الارتباط ، أو أشياء أخرى.



لذا ، تعني هاتان القاعدتان أنه إذا لم ترغب yzcom في السماح لأي شخص بالتفاعل معها ، فلن تغير القيمة (document.domain). لذلك عندما يريد إطار xyzcom تقصيره ، سيقول المتصفح: "نعم ، تريد تقصيره ، ولكن ليس لديك الحق في القيام بذلك!" هناك مصادفة للقيم ، لكن مجال yzcom لم يشر إلى رغبته في المشاركة في هذا. هل هذا واضح؟ في هذه الحالة ، يمكن ملاحظة أن الإطارات تعمل في الغالب مع سياسة المنشأ نفسها.

يمكننا الآن رؤية كيفية معالجة عقدة DOM الخاصة بنا. إنه بسيط للغاية. عادةً ما تحصل عُقد DOM على أصل من الإطار المحيط. في حالة ملفات تعريف الارتباط ، يكون هذا أكثر تعقيدًا إلى حد ما. ملفات تعريف الارتباط لها مجال ولها طريقتها الخاصة. على سبيل المثال ، يمكنك أن تتخيل أنه يمكن ربط ملف تعريف الارتباط بالمعلومات التالية ، على سبيل المثال * .mit.edu / 6.858. في هذه الحالة ، يحتوي ملف تعريف الارتباط على * .mit.edu / domain ومسار 6.858.



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

ولكن في هذه الحالة ، لدينا عنوان مسار محدد. لذا ، من وضع ملفات تعريف الارتباط هذه ، سيحصل على فرصة لرؤية كيف يبدو المجال والمسار. ويمكن تعيين هذه القيم على جانب الخادم وعلى جانب العميل. على جانب العميل ، سيكون لديك كائن JavaScript يسمى document.cookie. هذا هو التنسيق المستخدم للإشارة إلى جميع المسارات إلى كائنات متشابهة.

هناك علامة أمان العلم الآمن التي يمكنك تعيينها على ملف تعريف ارتباط للإشارة إلى أنه ملف HTTPS. في هذه الحالة ، يجب ألا يكون لمحتوى HTTP حق الوصول إلى ملف تعريف الارتباط هذا. هذه هي الفكرة الرئيسية لملفات تعريف الارتباط.

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

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

البروفيسور: نعم ، الإطارات يمكنها القيام بذلك. ولكن ذلك يعتمد على كيفية تعيين document.domain ونطاق ملف تعريف الارتباط والمسار. لذا ، يمكن للإطارات الوصول إلى ملفات تعريف الارتباط الخاصة ببعضها البعض ، ومن ثم ينشأ السؤال: هل يمكن أن تكون هناك مشكلة إذا سمحنا للإطارات التعسفية بكتابة ملفات تعريف الارتباط التعسفية للناس؟ يكفي أن نقول أنها ستكون سيئة. السبب في أن هذا سيئ لأن ملفات تعريف الارتباط هذه تسمح للعميل من التطبيق بتخزين بيانات المستخدم.

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

وبالتالي ، تعد ملفات تعريف الارتباط موردًا مهمًا جدًا للحماية. والعديد من هجمات أمن الشبكة مصممة لسرقتها واستخدامها لإلحاق الأذى.
هناك سؤال آخر مثير للاهتمام يتعلق بملفات تعريف الارتباط. افترض أن لديك موقع foo.co.uk. ماذا لو كان موقع باسم المضيف هذا قادرًا على تعيين ملفات تعريف الارتباط لـ co.uk؟



هناك دقة هنا تتعلق بالقواعد التي ناقشناها سابقًا ، لأن الموقع الأول يجب أن يكون قادرًا على تقصير نطاقه وتعيين ملفات تعريف الارتباط للموقع الثاني ، يبدو كل شيء قانونيًا هنا. ولكن من وجهة نظر إنسانية ، فإننا ننظر إليها بريبة ، لأننا نفهم أن co.uk هو مجال ذري واحد. ومع ذلك ، هذا يعادل .com. يمكننا القول أن البريطانيين أخطأوا بأنه يجب أن يكون لديهم نقطة هنا. لكن هذا ليس خطأهم. من وجهة نظر أخلاقية ، هذا مجال واحد لا يمكن كسره. لذلك ، يجب أن يكون لدينا بعض البنية التحتية الخاصة من أجل تعيين ملفات تعريف الارتباط للعمل بشكل صحيح.

لدى Mozilla موقع ويب يسمى publicsuffix.org يحتوي على قوائم قواعد لكيفية تقصير ملفات تعريف الارتباط والأصل والنطاقات ، مع الأخذ في الاعتبار أنه قد تكون هناك نقاط في بعض الأشياء ، بينما في الواقع يجب اعتبارها ذرية واحدة الجامع.

لذلك عندما يكتشف متصفحك كيف يجب أن يتعامل مع ملفات تعريف الارتباط المختلفة ، فسيتعين عليه التحقق من هذا الجانب من المشكلة. أو تأكد بطريقة ما من أن foo.co.uk لا يمكنه تقصير المجال إلى co.uk. لذلك هناك قضية حساسة للغاية هنا.

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

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

ضع في اعتبارك كيفية معالجة استجابات HTTP XML من خلال نفس سياسة المصدر الأصلي. افتراضيًا ، لا يمكن لجافا سكريبت إنشاء واحدة منها إلا إذا تم إنشاؤها على خادمها الأصلي. ومع ذلك ، هناك واجهة جديدة تسمى Cross Origin Request أو CORS.

لذلك ، هذا هو نفس الأصل ، ما لم يكن الخادم قد قام بتمكين هذه الأداة CORS. بشكل أساسي ، تتم إضافة رأس استجابة HTTP جديد يسمى Access-Control-Allow-Origin.



لنفترض أن جافا سكريبت من foo.com تريد تقديم طلب HTTP XML إلى bar.com. كما هو موضح في القواعد ، يحدث هنا عبر الأصل. وإذا كان خادم bar.com يريد السماح بذلك ، فسيرجع رد HTTP الخاص به بعنوان: "نعم ، دعني foo.com يرسل لي طلبات XML XML المشتركة هذه".

في الواقع ، يمكن لخادم bar.com الإجابة بـ "لا" ، أي أنه يمكنه رفض الطلب. في هذه الحالة ، لا يمكن للمتصفح إكمال طلب HTTP XML. لذلك هذا نوع من شيء جديد ، ظهر في الغالب بسبب التطبيقات المختلطة. هناك حاجة للتطبيقات من مطورين مختلفين ومجالات مختلفة ، بحيث يكون لديهم الفرصة لتبادل البيانات مع بعضهم البعض.



لذا بدلاً من foo.com ، قد تكون هناك علامات نجمية هنا إذا أراد شخص ما الحصول على بيانات مشتركة المصدر ، وما إلى ذلك. أعتقد أن هذا بسيط للغاية. هناك مجموعة من الموارد الأخرى التي يمكن أن ننظر إليها ، مثل الصور. بفضل Access-Control-Allow-Origin ، يمكن للإطار تحميل الصور من أي مصدر يريده. لكنه لا يستطيع التحقق من أجزاء هذه الصورة ، لأنه يعتقد أنه مع سياسات مصادر المنشأ المختلفة ، ليس من الجيد التحقق من محتويات ملفات بعضهم البعض.

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

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

جافا سكريبت هي مثالي المفضل لكيفية محاولة سياسة المنشأ نفسها دعم أي نوع من التسلسل الذكي. الفكرة هنا هي أنه إذا قمت بجلب جافا سكريبت ، فهذا مسموح به. يمكنك تمكين تنفيذ JavaScript خارجي في سياق صفحتك الخاصة ، ولكن لا يمكنك إلقاء نظرة على شفرة المصدر.



لذلك ، إذا كان لديك مصدر علامة برنامج نصي يساوي شيئًا خارج نطاقك ، فعندما يتم تنفيذ هذا المصدر ، يمكنك بدء الوظائف فيه. ولكن لن تتمكن من عرض كود مصدر JavaScript فيه.

كل هذا يبدو جيدًا جدًا ، ولكنه يحتوي على مجموعة من "الثقوب". على سبيل المثال ، تعد JavaScript لغة برمجة ديناميكية. والوظائف هي كائنات من الدرجة الأولى. وبالتالي ، بالنسبة لأي وظيفة f ، يمكنك ببساطة استخدام الوظيفة f.tostring () ، وسيمنحك هذا رمز المصدر للدالة f. والناس يفعلون ذلك طوال الوقت ، يقومون بإعادة الكتابة الديناميكية وما شابه ذلك.



وبالتالي ، على الرغم من أن سياسات الأصل لا تسمح لك بعرض محتويات علامة البرنامج النصي مباشرة ، يمكنك ببساطة القيام بالعملية المحددة والحصول على شفرة المصدر.

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

الجمهور: لنفترض أن السبب وراء ذلك هو منع المستخدم من استلام جافا سكريبت ، لأنه يمكن أيضًا إرسال ملفات تعريف الارتباط. أي أن المستخدم سيكون قادرًا على تكييف جافا سكريبت الناتج مع احتياجاته.

الأستاذ: نعم إنه كذلك.

الجمهور: لذلك إذا طلبت من خادمك القيام بذلك ، فلن يتمكن من تزويدك بملفات تعريف ارتباط مخصصة.

البروفيسور: هذا صحيح ، على الرغم من أنه من الناحية العملية ، لا يُقصد من المستخدم إعادة صياغة شفرة المصدر "الأولية". لكنك محق في أن هذا سيمنع بعض الهجمات.

, , JavaScript, . , - , -, , . , , , . , , .

, . - - , - HTML JavaScript. , , . .

, JavaScript, , . Java, .



, HTML5 , , , , Java. , .

, HTTP, cookie. , URL, ?



, URL- bank.com. , - . , URL, , , $500 . , .

— , origin, bank.com - , , cookie . : «, , , $500 attacker! , ».
. , , , , . . , , , , - . , , CSRF.

, URL. , c .

, - . – , , :

<form action = “/transfer.cdi”…> 

وداخل هذا النموذج ، سيكون لدينا بيانات الإدخال ، والتي تستخدم عادة لإدخال النص ، وضغطات المفاتيح ، ونقرات الماوس ، وما شابه. في الواقع ، يمكننا جعل هذا الإدخال مخفيًا بحيث لا يظهر في صفحة المستخدم: نوع الإدخال = "مخفي" ، وأعطه اسم السمة = "csrf" وقيمة القيمة العشوائية = "a72f ...". سيتم إنشاء هذا النموذج على الخادم.



وبالتالي ، عندما ينتقل المستخدم إلى هذه الصفحة ، من جانب الخادم ، يولد الخادم قيمة العشوائية هذه = "a72f ..." ويدمجها في HTML الذي يستلمه المستخدم. لذلك ، عندما يملأ المستخدم هذا النموذج ، فإن عنوان URL الخاص بالنموذج:

bank.com/xfer؟amount=500&to=attacker

يتم استكماله برمز عشوائي:

 http://bank.com/xfer?amount=500&to=attacker/&csrf=a72f... 

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

58:00 دقيقة

استمرار:

دورة معهد ماساتشوستس للتكنولوجيا "أمن أنظمة الكمبيوتر". المحاضرة 8: نموذج أمن الشبكات ، الجزء 3


النسخة الكاملة من الدورة متاحة هنا .

شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية به لأصدقائك ، خصم 30 ٪ لمستخدمي Habr على نظير فريد من خوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2650 v4 (6 نوى) 10GB DDR4 240GB SSD 1Gbps من 20 $ أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجابايت DDR4).

VPS (KVM) E5-2650 v4 (6 نوى) 10GB DDR4 240GB SSD 1Gbps حتى ديسمبر مجانًا عند الدفع لمدة ستة أشهر ، يمكنك الطلب هنا .

ديل R730xd أرخص مرتين؟ فقط لدينا 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV من 249 دولارًا في هولندا والولايات المتحدة! اقرأ عن كيفية بناء مبنى البنية التحتية الطبقة باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟