معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 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المحاضرة 9: "أمان تطبيق الويب"
الجزء 1 /
الجزء 2 /
الجزء 3 الجمهور: ما الذي يمنع المهاجم من العثور على مفتاح؟ أين يقع هذا المفتاح السري؟
البروفيسور: نعم هذا سؤال جيد. في معظم الحالات ، لا يكون عميل AWS متصفحًا ، ولكن بعض الأجهزة الافتراضية تعمل في السحابة. وهكذا ، ترى فقط التواصل بين الأجهزة الافتراضية. يمكنك أيضًا أن تتخيل أنه يمكن للمستخدمين تقديم هذه الروابط بطريقة أو بأخرى أو تضمينها بطريقة ما في HTML. إذا كان لديك شيء مثل ذلك المعروض على اللوح داخل شفرة مصدر HTML أو JavaScript ، فسيكون لديك الرمز لإنشاء مثل هذا الطلب. لذلك ، إذا قدمت لك أحد هذه الأشياء ، يمكنك تقديم طلب نيابة عني.
الجمهور: هل من الممكن استخدام MAC للعملاء العاديين؟
البروفيسور: عادي - هل تقصد المتصفحات؟
الجمهور: للمستخدمين العاديين.
البروفيسور: الحقيقة هي أن السؤال عن المكان الذي يعيش فيه المفتاح هو أمر بالغ الأهمية. لأنه إذا كان من الممكن سرقة المفتاح بسهولة مثل ملفات تعريف الارتباط ، فلن نفوز بأي شيء. لذلك ، في كثير من الحالات ، يتم تخزين كل هذه الأشياء في مكان ما في السحابة وتعمل على تبادل البيانات بين الأجهزة الافتراضية ويتم نقلها من خادم إلى خادم أيضًا في السحابة. وبالتالي ، يقوم مطور التطبيق بإطلاق VM ، والذي يستخدم الاستعانة بمصادر خارجية لمجموعة من الأشياء المخزنة في AWS.
الجمهور: هل توجد مشكلة تأخير في الشبكة هنا ، بحيث يمكن للمهاجم إرسال نفس الطلب مباشرة بعد المستخدم والحصول أيضًا على حق الوصول؟
البروفيسور: نعم ، يكفي أن نقول أن عدة أشخاص دافعوا عن أطروحات حول موضوع أمن الطوابع الزمنية. لكنك محق تمامًا ، لأننا أخذنا في الاعتبار مثالًا فظًا إلى حد ما.
تخيل أنه هنا ، في مثال String To Sign هذا ، على سطر DATE ، سنحصل على القيمة "Monday، June 4". ثم ، إذا تمكن المهاجم بطريقة ما من الوصول إلى كل هذا ، فسيتمكن من تكرار طلب المستخدم. والحقيقة هي أن AWS تسمح لك باستخدام تاريخ انتهاء صلاحية هذه الأشياء. وبالتالي ، هناك شيء واحد يمكنك القيام به هو إضافة حقل Expires (انتهاء الصلاحية) هنا ، وسوف نفترض أنه تم تحديد تاريخ انتهاء الصلاحية.
ثم يمكنني إعطاء هذا الرابط لمجموعة من الأشخاص المختلفين ، وسيتحقق الخادم مما إذا كانت طلباتهم قد انتهت صلاحيتها.
الجمهور: حتى إذا كان تاريخ انتهاء الصلاحية هو 200 مللي ثانية فقط ، ولكن المهاجم يراقب الشبكة ، فسيتمكن من الإرسال فقط في حالة وجود عدة نسخ من الطلب بدلاً من نسخة واحدة.
البروفيسور: صحيح تمامًا أنه إذا هاجم المهاجم الشبكة ورأى كيف تنتقل هذه الأشياء عن طريق الأسلاك ، وهناك مساحة كافية للمناورة في تاريخ انتهاء الصلاحية ، فيمكنه بالتأكيد القيام بهذا الهجوم.
لذلك كانت هذه نظرة عامة على كيفية عمل ملفات تعريف الارتباط عديمة الجنسية. ويثير هذا سؤالًا مثيرًا للاهتمام: ماذا يعني تسجيل الخروج باستخدام ملفات تعريف الارتباط من هذا النوع؟ الجواب هو أنك لن تخرج حقًا. أعني ، لديك هذا المفتاح وكلما أردت إرسال طلب ، فأنت ترسله فقط. لكن الخادم يمكن أن يلغي مفتاحك.
افترض أن الخادم أبطل المفتاح. ولكن يمكنك إنشاء أحد هذه الأشياء GET ، وعندما ترسل رسالة إلى الخادم ، ستقول: "نعم ، أعرف معرف المستخدم الخاص بك بالفعل ، تم إبطال المفتاح ، لذلك لن أفي بطلبك". ومع ذلك ، هناك فروق دقيقة ، وإذا تحدثنا عن أشياء مثل SSL ، فإن تمكين الشخص أسهل بكثير من تذكرها.
على هذا النحو ، هناك العديد من الأشياء الأخرى التي يمكنك استخدامها إذا كنت ترغب في تجنب ملفات تعريف الارتباط التقليدية لتنفيذ المصادقة. واحد منهم هو استخدام DOM - التخزين ، والذي يحتوي على معلومات حول المصادقة من جانب العميل. يمكنك استخدام مستودع DOM لتخزين بعض حالات الجلسة التي يتم وضعها عادةً داخل ملفات تعريف الارتباط.
إذا كنت تتذكر من المحاضرة الأخيرة ، فإن مستودع DOM هو واجهة رئيسية للقيم التي يوفرها المتصفح لكل مصدر ، أي أن المتصفح يأخذها من هناك ويدرجها في سلسلة.
الشيء الجيد هو أن DOM ليس لديه مثل هذه القواعد الغبية فيما يتعلق بنفس السياسات من نفس الأصل. لذا ، إذا كانت هذه ملفات تعريف ارتباط عادية ، يمكنك القيام بكل هذه الحيل الفرعية وما شابه. يرتبط مستودع DOM بشكل صارم بمصدر واحد ، لذا لا يمكنك توسيع أي نطاق فرعي. لذلك ، تستخدم أطر مثل Meteor هذا التخزين.
ولكن لاحظ أنه إذا كنت تريد حفظ معلومات المصادقة في مستودع DOM ، فستحتاج إلى كتابة شفرة JavaScript بنفسك لنقل هذه المعلومات إلى الخادم وتشفيرها وما إلى ذلك. إليك ما عليك القيام به في هذه الحالة.
يمكن للمرء استخدام الشهادات من جانب العميل ، على سبيل المثال ، تنسيق x.509 ، الذي يحتوي على معلومات حول المالك ، ومفتاح عام ، ومعلومات حول مرجع مصدق وتوقيع رقمي إلكتروني. الشيء الجيد في هذه الشهادات هو أن جافا سكريبت لا تحتوي على واجهة صريحة للوصول إلى هذه الأشياء. لذلك ، على عكس ملفات تعريف الارتباط ، حيث يوجد دائمًا "سباق تسلح" للعثور على أخطاء السياسة من نفس المصدر ، لا تحتوي الشهادات على واجهة جافا سكريبت صريحة لهذا الغرض. لذلك هذا جيد جدا من الناحية الأمنية.
إحدى المشاكل التي ذكرتها بإيجاز والتي سنناقشها بالتفصيل في المحاضرات اللاحقة هي إلغاء الشهادات. إذا غادر مستخدم مؤسستك ، كيف يمكنك أخذ شهادة منه؟ هذا معقد للغاية.
بالإضافة إلى ذلك ، هذه الأشياء ليست مريحة للغاية للاستخدام ، لأنه لا أحد يريد تثبيت مجموعة من الشهادات لكل موقع تزوره. لذلك ، لا تحظى شهادات المصادقة بشعبية كبيرة ، باستثناء الشركات أو المنظمات المسؤولة عن الأمن ذات المسؤولية الكبيرة. بهذا نختتم مناقشتنا لملفات تعريف الارتباط.
الآن دعونا نتحدث عن ثغرات البروتوكول في حزمة الويب. أحد أنواع الهجمات المثيرة للاهتمام هو استخدام الأخطاء في مكونات المتصفح ، على سبيل المثال ، عند تحليل عناوين URL. فكيف يمكن أن يسبب تحليل عنوان URL مشكلة لنا؟
لنفترض أن لدينا عنوان URL من النوع الذي يتم فيه تضمين أحرف غريبة في النهاية لسبب ما:
example.com : 80 @ foo.com.
السؤال هو ، ما هو أصل عنوان URL هذا؟ كان الفلاش يعتقد أن اسم المضيف هو example.com. ولكن عندما يحلل المتصفح العنوان ، سيعتقد أن أصل المضيف في هذه الحالة هو foo.com.
هذا أمر سيئ للغاية ، لأنه عندما يكون لدينا كيانين مختلفين مرتبكين حول أصل أصل نفس المورد ، فإنه محفوف بالمشاكل غير السارة.
على سبيل المثال ، قد يكون رمز الفلاش ضارًا ويقوم بتنزيل بعض المواد من example.com. إذا تم دمج برمجية إكسبلويت في الصفحة باستخدام موقع foo.com ، فيمكنه أيضًا القيام ببعض األشياء الشريرة هناك. ثم يأخذ بعض التعليمات البرمجية من example.com ويديرها بسلطات موقع foo.com. العديد من قواعد التحليل المعقدة مثل هذه تجعل الحياة صعبة للغاية. يحدث كل الوقت.
لقد درسنا للتو تطهير المحتوى ، وفكرته الرئيسية هي أنه غالبًا ما يكون أفضل كثيرًا عندما تكون هناك قواعد تحليل أبسط لهذا النوع من الأشياء. ومع ذلك ، يصعب القيام بذلك بأثر رجعي ، لأن HTML موجود بالفعل.
الآن دعونا نتحدث عن ثغرات الأمان المفضلة لدي - الملفات ذات الامتداد .jar ، وهي أرشيف ZIP مع جزء من برنامج Java. تصبح ملفات JAR للمتصفح هدف الهجوم ، وبشكل رئيسي تطبيقات Java. حوالي عام 2007 ، أوضح موقع ممتاز يسمى lifehacker.com كيفية تضمين الملفات المضغوطة داخل الصور. ليس من الواضح من الذي تحاول إخفاءه من خلال القيام بذلك ، لكن lifehacker.com يتأكد من أنه يمكنك القيام بذلك.
يستخدمون بشكل رئيسي حقيقة أنه إذا نظرت إلى تنسيقات الصور ، مثل ملفات GIF ، فعندئذ كقاعدة ، يعمل المحلل اللغوي من الأعلى إلى الأسفل. أولاً ، يجد المعلومات في الرأس ، ثم ينظر إلى البتات المتبقية الموجودة في الأسفل.
كما اتضح ، تعمل البرامج التي تتعامل عادةً مع ملفات ZIP من الأسفل إلى الأعلى ، أي عكس اتجاه تحليل الصورة. أولاً ، يجدون المعلومات في تذييل الملف ويفككون ما بداخل الأرشيف. وبالتالي ، إذا قمت بوضع ملف صورة يحتوي على أرشيف ZIP ، فسوف يجتاز جميع عمليات التحقق ، حتى فحص فليكر ، مثل أي صورة أخرى ، وسيظهر كصورة في متصفحك.
ولكن فقط ستعرف الحقيقة الخفية. فقط ستدرك أنه إذا أخذت هذا الملف ، يمكنك فك ضغطه واستخدام المعلومات الواردة فيه. يبدو وكأنه خدعة رخيصة ، لكن المتسللين لا ينامون أبدًا ، فهم يريدون باستمرار تدمير حياتنا. فكيف يطبقون هذه الفكرة؟
يفهمون أن ملفات JAR مشتقة من تنسيق .zip. هذا يعني أنه يمكنك إنشاء رسم متحرك بتنسيق GIF أو صورة ثابتة تحتوي على ملف JAR ، أي رمز JavaScript قابل للتنفيذ ، في الأسفل.
في وقت لاحق ، أطلق الناس على طريقة الهجوم هذه GIFAR ، ونصف GIF ، ونصف JAR ، وكلا النصفين شريران. كانت رائعة. عندما اكتشف الناس هذه الفرصة لأول مرة ، وجدوا أنها مذهلة ، لكنهم لم يفهموا على الإطلاق كيفية استخدامها. ولكن كما اتضح ، يمكن القيام بالأشياء التالية على أساسها.
فكيف يمكنك القيام بذلك؟ أنت فقط تستخدم CAD. خذ .gif ، خذ .jar ، استخدم أرشيف الاستخراج الذاتي - بوم ، و GIFAR هاجمك!
لذا ، بمجرد حصولك على هذا ، ماذا يمكنك أن تفعل؟ هناك بعض المواقع الحساسة التي تسمح للمستخدمين بتوفير البيانات ، ولكن ليس أنواع البيانات التعسفية. لذا قد لا يسمح لك Flickr أو شيء من هذا القبيل بإرسال ActiveX تعسفي أو أي HTML تعسفي آخر. ولكن سيسمح لك بإرسال الصور. لذا يمكنك بناء أحد هذه الأشياء وإرسالها إلى أحد هذه المواقع السرية التي تسمح لك بإرسال الصور. ما الذي عليك فعله للقيام بهجوم ناجح في هذه الحالة؟
أولاً ، أرسل هذه الصورة "المحشوة" إلى أحد هذه المواقع. ثانيًا ، استخدم طريقة هجوم البرمجة النصية عبر الموقع XSS ، باستخدام نقاط الضعف الموجودة. للقيام بذلك ، تحتاج إلى إدراج التطبيق الصغير ، والكتابة في JavaScript مثل هذا التعبير:
يستغل هذا الكود ثغرة البرمجة النصية عبر المواقع ، وبالتالي سيتم إطلاقه في محتوى الموقع. سوف ينجح GIFAR في التحقق من الأصل ، لأنه يأتي من موقع له مصدر أصل مشترك ، على الرغم من حقيقة أن هذا الرمز تم إدراجه بواسطة مهاجم.
لذا ، يحصل المهاجم الآن على فرصة لتشغيل برنامج Java هذا في سياق موقع الضحية مع جميع أذونات المنشأ. وسيتم تحديد أحد هذه الأشياء بشكل صحيح كصورة GIF. ولكن هناك رمز مخفي هنا. اسمحوا لي أن أذكرك أنه في البداية يقوم المتصفح بتفريغ الملفات المؤرشفة ، لذلك ، أولاً وقبل كل شيء ، سيتم تشغيل جزء JAR ، وتجاهل الجزء العلوي من GIF. لذلك هذا أمر مدهش في الواقع.
هناك بعض الطرق البسيطة لإصلاح ذلك. على سبيل المثال ، يمكنك استخدام محمل التطبيق الصغير ، الذي يفهم أنه لا يجب أن يكون هناك أي القمامة العشوائية. في كثير من الحالات ، يتم استخدام معلومات البيانات الوصفية التي توضح طول هذا المورد. في هذه الحالة ، سيبدأ اللودر ، كما هو متوقع ، من الأعلى ، ويحلل طوله ، ويرى أن التطبيق الصغير ينتهي في الأعلى ، ويتوقف. لا يهتم بالجزء السفلي ، فمن الممكن أنه حتى 0. في حالتنا ، لن يساعد هذا اللودر ، حيث سيبدأ في معالجة الطلب من الجزء السفلي المؤرشف ، ويتوقف أمام الجزء العلوي ، متجاهلاً ذلك.
ما يعجبني في هذا هو أنه يوضح حقًا مدى اتساع مجموعة برامج الإنترنت. باستخدام هذين التنسيقين فقط ، GIF و JAR ، يمكنك إنشاء هجوم سيء حقًا.
يمكنك أن تفعل الشيء نفسه مع ملفات PDF. يمكنك وضع ملف PDF بدلاً من ملف GIF واستدعاء هذا الهجوم بشيء من مخاطر PDFAR. لكن في النهاية ، اكتشف الناس هذه المشكلة ، وتم القضاء على نقاط الضعف من هذا النوع الآن.
الجمهور: ما الذي يمكنك فعله بهذا النوع من الهجمات ، والذي لا يمكن إجراؤه بهجوم البرمجة النصية عبر المواقع XSS العادي؟
البروفيسور: هذا سؤال جيد. لذا ، ما هو جيد في هذا هو أن Java غالبًا ما تكون أداة أقوى من JavaScript العادية ، لأنها تستخدم قواعد مختلفة قليلاً ، وسياسة الأصل نفسها ، وما شابه. ولكنك على حق في أنه إذا كان بإمكانك تشغيل برمجة نصية عبر المواقع ، فإن تشغيل JavaScript بنفسك قد يكون مدمرًا للغاية. لكن الميزة الرئيسية لهذه الطريقة هي أن تقنية الهجوم هذه تعمل داخل التطبيق الصغير ويمكنها القيام بما لا يمكنها القيام به مع كود البرنامج النصي الخبيث العادي.
لذا ، كما قلت ، هذا هو هجومي المفضل في كل الأوقات ، ويرجع ذلك أساسًا إلى أنه جعل أمن الكمبيوتر المرموق يفكر الناس في كلمة مثل GIFAR.
شيء آخر مثير للاهتمام هو استخدام الهجمات على أساس الوقت. عادة لا يفكر الناس في الوقت كمورد ، والذي يمكن أن يكون ناقلات للهجمات. ولكن كما أشرت قبل بضع دقائق ، يمكن أن يكون ذلك الوقت في الواقع وسيلة لإدخال ثغرة في النظام.
الهجوم المحدد الذي سأتحدث عنه معك هو هجوم القناة السرية. فكرة هذا الهجوم هي أن المهاجم يجد طريقة لتبادل المعلومات بين تطبيقين ، وعملية التبادل هذه غير مصرح بها. يستخدم المهاجم بطريقة أو بأخرى جزءًا من النظام لنقل أجزاء من المعلومات بين موارد مختلفة.
مثال جيد على شيء من هذا القبيل هو هجوم CSS شم. ما هذا الهجوم؟
افترض أن المهاجم لديه موقع ويب يمكن للمستخدم زيارته. إن زيارة المستخدم لموقع ويب أمر بسيط للغاية. يمكنك إنشاء إعلان أو إرسال بريد إلكتروني للتصيد الاحتيالي.
وبالتالي ، يمتلك المهاجم موقع ويب يزوره المستخدم. وهدف المهاجم هو معرفة المواقع الأخرى التي زارها المستخدم. قد يرغب المهاجم في معرفة ذلك لعدة أسباب. ربما يكون مهتمًا بطلبات بحث المستخدم ، أو أنه يحاول معرفة مكان عمل هذا الشخص ، أو ربما يريد أن يعرف ما إذا كان هذا الشخص يزور بعض المواقع "المخزية" وما إلى ذلك.
كيف سيفعل المهاجم هذا إذا كان الشيء الوحيد الذي يسيطر عليه هو موقع ويب يريد إقناع المستخدم بزيارته؟ هناك طريقة ممكنة لاستخدام ألوان الارتباط. كما تعلم ، إذا اتبعت رابطًا مرة واحدة ، في المرة التالية التي يظهر فيها في متصفحك بلون مختلف ، مما يشير إلى أنك قمت بالفعل بالانتقال إلى هذا الرابط. هذه في الواقع ثغرة أمنية.
لأن هذا يعني أنه على موقعك ، يمكن للمهاجم إنشاء قائمة ضخمة من عناوين URL المحتملة التي يمكنك زيارتها ، ثم استخدام JavaScript لمعرفة اللون الذي حصلت عليه عناوين URL هذه. URL , , . .
, URL-. , , . , , URL- , ? , . , , URL — cnn.com, Facebook.com . , . , .
, , , : «, , !», .
Covert channel attack? , JavaScript . JavaScript , , . , . , , JavaScript , . , , ? , .
, , — . – , .
, , . , , .
, — , , , , , . , , , , . ?
, . . , .
, Google Map Tiles. , «» Google Map, , , , . .
? , . , , , . , .
, , , JavaScript . , , DNS.
: , , DNS , . , , -, , -. , , DNS . , , DNS , .
: JavaScript .
: , !
: , , , , ?
: , . , — - , , , - URL. , API– , .
: - , , ?
:أنت على حق تماما. أعتقد أن واجهة برمجة تطبيقات مشاركة الشاشة فكرة سيئة. لكني لست رئيس العالم ، ماذا يمكنني أن أفعل؟ بطريقة أو بأخرى ، تعمل الهجمات المستندة إلى DNS حتى إذا فشل التخزين المؤقت.إذن ماذا يحدث إذا استخدمنا فقط عناوين IP المصدر لجميع مضيفينا؟ نحن لا نخزن أي شيء! وننتقل إلى متصفح محدث لا يوفر ألوان الارتباط لجافا سكريبت. لذلك كل شيء على ما يرام لدينا. لكنني هنا لأقول أنك لا تبلي بلاء حسنا! لأنه في الواقع ، يمكن للمهاجم الاستفادة من قدرة الهجوم التقديم.الفكرة الرئيسية هنا هي تقديم عنوان URL الذي قمت بزيارته سابقًا بشكل أسرع.
<iframe>, , , , , , , , <iframe>. <iframe> , , <iframe> . , origin, .
وبالتالي ، لم يعد بإمكان المهاجم لمس أي شيء ويخلص إلى أنه كان قادرًا على تحديد الموقع الذي زرته من قبل.
نراكم في المحاضرة القادمة!
النسخة الكاملة من الدورة متاحة
هنا .
شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية به لأصدقائك ،
خصم 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 يورو مقابل سنت واحد؟