معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 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 الجمهور: لماذا يتم دائمًا تضمين رمز عشوائي في عنوان URL ، وليس في نص الطلب؟
البروفيسور: يتم استخدام HTTPS بهذه الطريقة ، ولكن لا يوجد سبب وجيه لعدم تضمين متغيرات عشوائية في نص الطلب. الأمر فقط أن هناك بعض أشكال الميراث التي تعمل بهذه الطريقة من خلال عنوان URL. ولكن من الناحية العملية ، يمكنك وضع هذه المعلومات في مكان آخر في طلب HTTPS ، باستثناء الرأس.
ومع ذلك ، لاحظ أن نقل هذه المعلومات ببساطة إلى نص الطلب من المحتمل أن يكون غير آمن إذا كان هناك شيء يمكن للمهاجم تخمينه. ثم لا يزال بإمكان المهاجم استدعاء عناوين URL التي يحتاجها بطريقة أو بأخرى. على سبيل المثال ، عندما أقوم بتقديم طلب HTTP XML ، ثم وضع صراحةً بعض المحتوى في النص الذي يمكن للمهاجم تخمينه.
إذا قمت ببساطة بتعيين الإطار في عنوان URL ، فيمكن للمهاجم التحكم فيه. ولكن إذا كنت تستخدم طلب XML HTTP ويمكن للمهاجم إنشاء أحدهم ، فإن واجهة HTTP XML تسمح لك بتعيين نص الطلب. يقتصر طلب HTTP XML على نفس المصدر. ومع ذلك ، إذا تمكن المهاجم من فعل شيء مثل:
<script> var x = “ntrusted”; </script>
ثم سيتمكن من تنفيذ طلب HTTP XML ، والذي سيتم تنفيذه بتفويض من الصفحة المضمنة.
كل هذا يتوقف على ما يمكن للمهاجم الوصول إليه. إذا كان بإمكانها إجبار الصفحة على تنفيذ برنامج نصي غير محدد ، كما هو موضح أعلاه ، فيمكنها استخدام خاصية JavaScript تسمى HTML الداخلي والحصول على كل محتوى HTML للصفحة. إذا كان بإمكان المهاجم أو لا يمكنه إنشاء طلب AJAX ، فهذا شيء ، إذا كان يستطيع أو لا يستطيع رؤية رمز HTML الصحيح ، فهذا شيء آخر ، وما إلى ذلك. باختصار ، هذا الرمز المميز بشكل عشوائي قادر على منع هجمات CSRF.
هناك شيء آخر تحتاج إلى الانتباه إليه هو عناوين الشبكة. وهي تتعلق بجزء محادثتنا الذي قال من لم يتمكن المهاجم من التواصل من خلال طلب HTTP XML.
فيما يتعلق بعناوين الشبكة ، يمكن للإطار إرسال طلبات HTTP و HTTPS إلى (المضيف + المنفذ) المطابق لأصله. لاحظ أن أمان نفس السياسة من نفس المصدر يرتبط ارتباطًا وثيقًا بأمان بنية DNS الأساسية ، لأن جميع السياسات من هذا النوع تستند إلى ما يطلق عليه.
لذا إذا كان بإمكانك التحكم في ما يسمونه ، فيمكنك القيام ببعض الهجمات الخبيثة ، على سبيل المثال ، هجوم إعادة ربط DNS. الغرض من هذا الهجوم هو إطلاق جافا سكريبت يسيطر عليه المهاجم مع السلطة (أو نيابة عن) موقع الضحية ، دعنا نطلق عليه الضحية.com. في هذه الحالة ، يستخدم المهاجم قواعد سياسة المصدر نفسها وسيبدأ بطريقة ما في إطلاق الرمز الذي كتبه بإذن من موقع آخر.
يتم ذلك على النحو التالي. أولاً ، يسجل المهاجم اسم نطاق ، كما يقول attacker.com. الأمر بسيط للغاية ، فقط ادفع بضعة دولارات - وأثناء التنقل ، لديك اسم نطاق خاص بك. يجب أن يقوم المهاجم أيضًا بتكوين خادم DNS للاستجابة للطلبات الواردة باسم الكائنات الموجودة في attacker.com.
الشيء الثاني الذي يجب أن يحدث هو أنه يجب على المستخدم زيارة attacker.com. على وجه الخصوص ، يجب عليه زيارة بعض المواقع التي تعتمد على اسم المجال هذا. لا يوجد شيء صعب في هذا الجزء من الهجوم أيضًا.
تحقق مما إذا كان يمكنك إنشاء حملة إعلانية ، على سبيل المثال ، تقديم جهاز iPad مجاني. الكل يريد جهاز iPad مجانيًا ، على الرغم من أنني لا أعرف أي شخص فاز بجهاز iPad مجاني. لذا ، النقر على مثل هذه الرسالة في بريد إلكتروني تصيد ، وأنت بالفعل على موقع المهاجم. لا شيء خاص ، هذا الجزء ليس معقدًا.
فماذا سيحدث بعد ذلك؟ سيبدأ المستعرض في إنشاء استعلامات DNS لموقع الويب الهجومية لموقع الويب لأن الصفحة التي قمت بزيارتها تحتوي على كائنات ترتبط بالكائنات الموجودة على موقع هجوم الويب. لكن المتصفح سيقول: "لم يسبق لي أن رأيت هذا النطاق من قبل ، لذا دعني أرسل طلب نظام أسماء النطاقات للحصول على إذن للاتصال بالهجوم"!
ويجيب خادم DNS للمهاجم على هذا الطلب ، لكن استجابته تحتوي على عمر TTL قصير جدًا ، مما يمنع الاستجابة مؤقتًا. لذلك ، سيعتقد المتصفح أنه صالح فقط لفترة قصيرة جدًا من الوقت قبل أن يحتاج إلى الخروج وتأكيد ذلك ، مما يعني في الواقع حظر التخزين المؤقت.
اتضح أنه بمجرد أن ينتقل المستخدم إلى مجال القراصنة ، يقوم خادم DNS الخاص بالمهاجم أولاً بإرجاع عنوان IP الحقيقي لخادم الويب الذي زود المستخدم برمز ضار. يصل هذا الرمز من جانب العميل إلى attacker.com لأن سياسة المنشأ تسمح بمثل هذه الطلبات. يتلقى المستخدم استجابة ، والآن يعمل موقع الويب الضار على جانب العميل.
في هذه الأثناء ، سيقوم المهاجم بتكوين خادم DNS ، الذي يسيطر عليه ، لربط اسم attacker.com وعنوان IP الخاص بالضحية. هذا يعني أنه إذا طلب متصفح المستخدم تحليل اسم المجال لشيء ما داخل attacker.com ، فسيحصل بالفعل على نوع ما من العنوان الداخلي Vict.com.
لماذا يمكن لمهاجم DNS القيام بذلك؟ نظرًا لأن المخترق يعدها لهذا الأمر ، ولا يحتاج خادم نظام أسماء النطاقات الدخيل إلى التشاور لإعادة الاتصال بـ Vict.com.
علاوة على ذلك ، إذا كان موقعنا يريد الحصول على كائن جديد من خلال ، على سبيل المثال ، AJAX ، فسوف يعتبر أن طلب AJAX هذا يذهب إلى attacker.com في مكان ما بالخارج ، ولكن في الواقع هذا الطلب من AJAX يدخل إلى Vict.com. هذا أمر سيئ ، لأن لدينا الآن هذا الرمز على الجانب الذي توجد فيه صفحة الويب الهجومية لموقع الويب ، والتي تمكن بالفعل من الوصول إلى البيانات من Vict.com ذات مصدر أصل مختلف.
ببساطة ، عندما يتم تنفيذ برنامج نصي في متصفح الضحية بسبب تقادم استجابة DNS السابقة ، يتم إجراء استعلام DNS جديد لهذا المجال ، والذي ، بسبب حظر التخزين المؤقت ، يتم إرساله إلى خادم DNS للمهاجم. يجيب بأنّ موقع الهجوم على الإنترنت يبدو الآن أنه يحتوي على عنوان IP جديد لموقع ويب آخر ، وينتقل الطلب إلى خادم آخر. وبعد ذلك ، لإرجاع المعلومات التي تم جمعها بواسطة الشفرة ، يقدم المهاجم عنوان IP الصحيح الخاص به في أحد استعلامات DNS التالية.
الجمهور: ألن يكون من الحكمة القيام بهجوم على عكس ذلك ، من موقع Vict.com للحصول على جميع ملفات تعريف الارتباط الخاصة بالمهاجم وما شابه؟
الأستاذ: نعم ، هذا الخيار سيعمل أيضًا. سيسمح لك ذلك بفعل أشياء جيدة مثل فحص المنفذ. أعني ، سيعمل نهجك بشكل صحيح. لأنه يمكنك ، خطوة بخطوة ، إعادة تعيين attacker.com باستمرار لأسماء أجهزة الكمبيوتر المختلفة والمنافذ المختلفة داخل شبكة Vict.com. بعبارة أخرى ، ستعتقد صفحة الويب الهجومية دائمًا أنها تذهب إلى attacker.com وتتلقى طلبًا من AJAX من هناك.
في الواقع ، في كل مرة يعيد فيها خادم DNS الاتصال بـ attacker.com ، يرسل الطلبات إلى بعض عناوين IP الأخرى داخل شبكة Vict.com. وبهذه الطريقة ، يمكنه ببساطة "التنقل" عبر عناوين IP واحدًا تلو الآخر ومعرفة ما إذا كان شخص ما يستجيب لهذه الطلبات.
الجمهور: لكن المستخدم الذي تهاجمه ليس لديه بالضرورة وصول داخلي إلى شبكة Vict.com.
البروفيسور: كقاعدة عامة ، هذا الهجوم هو أن هناك بعض قواعد جدار الحماية التي يمكن أن تمنع الموقع الخارجي attacker.com من عرض عناوين IP داخل شبكة Vict.com. ومع ذلك ، إذا كنت داخل شبكة شركة مثل corp.net خلف جدار حماية الشركة ، فغالبًا ما يكون لأجهزة الكمبيوتر القدرة على الاتصال بأجهزة خارج شبكتها.
الجمهور: هل تعمل طريقة الهجوم هذه عبر HTTPS؟
البروفيسور: هذا سؤال شيق! الحقيقة هي أن HTTPS يستخدم المفاتيح. إذا كنت تستخدم HTTPS ، فعند إرسال طلب AJAX ، لن يكون لدى آلة الضحية مفاتيح HTTPS للمهاجم ، وسيظهر التحقق من التشفير على Vict.com عدم تطابق المفتاح. لذلك ، أعتقد أن HTTPS يستبعد إمكانية هذا النوع من الهجوم.
الجمهور: ماذا لو كانت الضحية تستخدم HTTPS فقط؟
البروفيسور: أعتقد أن هذا سيوقف المهاجم.
الجمهور: لماذا يرد المهاجم بشكل أساسي على حاسوب الضحية بعنوان IP الخاص به؟
البروفيسور: لأنه يجب على المهاجم تشغيل رمزه بطريقة ما على آلة الضحية قبل أن يتمكن من اتخاذ مزيد من الإجراءات للعثور على شيء داخل شبكة الضحية. ولكن ، دعونا لا نضيع الوقت ، إذا كانت لديك أسئلة حول إعادة تعيين DNS ، تعال إلي بعد المحاضرة.
فكيف يمكنك إصلاح هذا؟ تتمثل إحدى طرق إصلاح هذه الثغرة في تعديل محلل عميل DNS بحيث لا يُسمح أبدًا لأسماء المضيف الخارجي بالوصول إلى عناوين IP الداخلية.
من الغباء نوعًا ما أن يتمكن شخص خارج شبكتك من إنشاء نظام أسماء نطاقات مرتبط بشيء داخل شبكتك. هذا هو أبسط حل.
يمكنك أن تتخيل أن المتصفح يمكنه القيام بشيء يسمى "تثبيت DNS" أو تثبيت DNS. ونتيجة لذلك ، إذا تلقى المتصفح سجل DNS محلول ، فسيعتبر دائمًا هذا السجل صالحًا ، على سبيل المثال ، للتفاعل في غضون 30 دقيقة ، بغض النظر عن TTL التي يعينها المهاجم ، وبهذه الطريقة يمكنه مقاومة الهجوم.
هذا الحل معقد بعض الشيء ، لأن هناك مواقع تستخدم عن قصد نظام DNS الديناميكي لأشياء مثل موازنة تحميل الخادم وما شابه. وبالتالي ، فإن الحل الأول مع تثبيت DNS هو الخيار الأفضل.
والآن سنلقي نظرة على ما تحميه سياسة المصدر نفسها. ماذا عن البكسل؟ كيف تحمي سياسة المنشأ البكسل؟
كما اتضح ، فإن وحدات البكسل ليس لها أصل. وبالتالي ، يحصل كل إطار على مربع محيط صغير خاص به ، بشكل أساسي مجرد مربع ، ويمكن أن يرسم الإطار في أي مكان داخل تلك المنطقة.
هذه مشكلة في الواقع لأنها تعني أن الإطار الرئيسي يمكن أن يرسم فوق الإطار الفرعي. وهذا بدوره يمكن أن يؤدي إلى هجمات خبيثة للغاية.
لنفترض أن مهاجمًا أنشأ صفحة تقول "انقر هنا للفوز بجهاز iPad". نفس الحيلة القياسية. هذا هو الإطار الرئيسي.
ويمكن لهذا الإطار الرئيسي إنشاء إطار فرعي ، وهو في الواقع إطار الزر "أعجبني" على موقع Facebook. وبالتالي ، يسمح لك Facebook بتشغيل هذه القطعة الصغيرة من كود Facebook التي يمكنك وضعها على صفحتك.
أنت تعلم أنه إذا نقر المستخدم على "أعجبني" ، فهذا يعني أنه سيذهب إلى Facebook ويقول: "مرحبًا ، أنا أحب هذه الصفحة بالذات"! لذلك ، لدينا الآن هذا الإطار الفرعي للزر Like.
الآن ، يمكن للمهاجم تراكب هذا الإطار في منطقة الشاشة التي يجب على المستخدم النقر عليها للحصول على جهاز iPad مجاني ، وكذلك جعل هذا الإطار غير مرئي ، يسمح CSS بذلك.
إذن ماذا سيحدث؟ كما سبق أن قمنا بتثبيته ، يريد الجميع الحصول على iPad مجاني. سينتقل المستخدم إلى هذا الموقع من خلال النقر على هذه المنطقة من الشاشة ، مع التأكد من أنه ينقر بالضبط على ما سيقدمه له iPad المجاني. ولكن في الواقع ، ينقر على زر الإعجاب غير المرئي. انها مثل طبقات فوق المؤشر C.
هذا يعني أنه الآن ، ربما ينتهي المستخدم في ملف شخصي على Facebook ، حيث يلاحظ أنه كان معجبًا بـ attacker.com. كما تعلم ، لن يتذكر حتى كيف حدث ذلك. لذلك هذا هو في الواقع ما يسمى بهجوم النقر فوق النقر - دعم هجوم النقر. بنفس الطريقة ، يمكنك فعل الكثير من الأشياء السيئة - سرقة كلمات المرور ، الحصول على البيانات الشخصية ، باختصار ، هذا جنون. أؤكد - هذا ممكن بسبب حقيقة أن الإطار الرئيسي قادر على رسم أي شيء داخل هذا الصندوق المحيط.
لذا ، فإن الإطار الرئيسي هو ما تراه على الصفحة ، والدعوة للحصول على جهاز لوحي مجاني ، والإطار الفرعي هو زر الإعجاب ، والذي يتم فرضه بشفافية على الإطار الرئيسي.
هناك العديد من الحلول لهذه المشكلة. الأول هو استخدام كود خرق الإطار. بهذه الطريقة ، يمكنك استخدام تعبيرات JavaScript لمعرفة ما إذا كان شخص ما قد قام بتضمين الإطار الخاص به في الإطار الخاص بك. على سبيل المثال ، أحد هذه الاختبارات هو مقارنة النموذج التالي: if (self! = Top).
هنا ، يشير البيان الذاتي إلى الجزء العلوي من الإطار العلوي ، والذي يتم مقارنته بالتسلسل الهرمي للإطار بأكمله. لذلك ، إذا قمت بهذا الاختبار ووجدت أن الذات لا تساوي الجزء العلوي من الإطار الرئيسي ، فستفهم أن لديك إطارًا فرعيًا. في هذه الحالة ، يمكنك رفض تنزيله.
يحدث هذا إذا حاولت إنشاء إطار ، على سبيل المثال ، لموقع CNN.com. إذا نظرت إلى شفرة المصدر لـ JavaScript ، يمكنك أن ترى أنها تقوم بهذا الاختبار لأن CNN.com لا تريد أن يستخدم أشخاص آخرون محتواها. لذلك ، يحتل هذا الإطار دائمًا أعلى منصب. لذلك ، هذا هو أحد الحلول التي يمكن استخدامها هنا.
الحل الثاني هو أن يرسل خادم الويب رأس HTTP يسمى خيارات x-Frame في الاستجابة. لذلك ، عندما يعرض خادم الويب ردًا ، يمكنه تعيين هذا العنوان ، والذي سيقول: "مرحبًا ، المتصفح ، لا تسمح لأي شخص بوضع المحتوى الخاص بي داخل الإطار!". يسمح هذا الحل للمتصفح بتنفيذ إجراءات التنفيذ.
لذا فهي بسيطة للغاية. ولكن لا تزال هناك مجموعة من الهجمات المجنونة الأخرى التي يمكنك تنظيمها.
كما ذكرت سابقًا ، حقيقة أننا نعيش الآن على الإنترنت الدولية تخلق مشاكل باستخدام اسم المجال أو المضيف.
لنفترض أن لدينا الحرف C. ولكن بأي لغة؟ من أي أبجدية هذه الرسالة من اللاتينية ASCII أم أنها C باللغة السيريلية؟ يسمح لك هذا بتنظيم الهجمات التي تستخدم تفسيرًا مختلفًا واستخدام أحرف مختلفة ، ولكنها تبدو متشابهة. على سبيل المثال ، سيقوم المهاجم بتسجيل اسم نطاق cats.com. وسيذهب المستخدمون إلى هذا النطاق ، معتقدين أنهم سيزورون موقع "cats.com" ، ولكن في الواقع سيصلون إلى موقع المهاجم "sats.com" ، لأن الحرف الأول هنا ليس لاتينيًا ، ولكن السيريلية.
يمكن للمهاجم تسجيل نطاق fcebook.com ، ولكن الناس غير مهتمين ، فسيأخذونه كـ facebook.com ويذهبون إليه. لذا إذا كنت تتحكم في Facebook.com ، فستحصل على الكثير من الزيارات من الأشخاص الذين يعتقدون أنهم سجلوا الدخول إلى Facebook.
هناك مجموعة مختلفة من الهجمات الغريبة التي يمكنك إطلاقها من خلال نظام تسجيل اسم النطاق الذي يصعب الدفاع عنه ، لأنه كيف يمكنك منع المستخدمين من ارتكاب الأخطاء الإملائية؟ أو كيف يشير المتصفح للمستخدم: "مرحبًا ، هذا هو السيريلي وليس اللاتيني"!؟
إذا قام المتصفح بتحذير المستخدم في كل مرة يتم فيها تشغيل الخطوط السيريلية ، فسوف يغضب الأشخاص الذين يستخدمون السيريلية بالفعل كخطهم الأصلي. لذلك ليس من الواضح تمامًا كيف يمكن حل هذه المشكلات من وجهة نظر فنية ، ولهذا السبب تنشأ مشاكل أمنية حساسة للغاية هنا.
شيء آخر مثير للاهتمام هو الإضافات. كيف تتفاعل الإضافات مع سياسات المنشأ؟ غالبًا ما تكون المكونات الإضافية غير متوافقة مع باقي المتصفح فيما يتعلق بنفس المصدر الأصلي. على سبيل المثال ، إذا نظرت إلى مكون Java الإضافي ، فيفترض أن أسماء المضيف المختلفة التي لها نفس عنوان IP لها نفس الأصل.
في الواقع ، هذا انحراف كبير إلى حد ما عن التفسير القياسي للسياسات من نفس الأصل. هذا النهج يعني أنه إذا كان لديك شيء مثل xycom و zycom ويتم عرضهما على نفس عنوان IP ، فستفترض Java أن لديهم نفس المصدر الأصلي. يمكن أن يكون هذا مشكلة ، لأنه في الواقع يحتوي أحد المواقع على مصدر موثوق موثوق به ، والآخر لا. هناك العديد من الصعوبات الأخرى المرتبطة بالمكونات الإضافية ، والتي يمكنك اكتشافها من مصادر متاحة للجمهور على الإنترنت أو من ملاحظات المحاضرة.
آخر شيء أريد مناقشته هو هجوم مشاركة الشاشة أو هجوم مشاركة الشاشة.
يحدد HTML5 في الواقع واجهة برمجة تطبيقات جديدة يمكن لصفحة الويب من خلالها مشاركة جميع وحدات البت الخاصة بها للمشاركة مع متصفح أو خادم آخر. تبدو هذه فكرة رائعة حقًا ، لأنها تتيح للعديد من المستخدمين العمل في وقت واحد على نفس المستند. هذا رائع لأننا نعيش في المستقبل.
لكن أطرف شيء هو أنه عندما طوروا واجهة برمجة التطبيقات الجديدة هذه ، لم يفكروا في سياسة مصدر مشتركة على الإطلاق!
لنفترض أن لديك صفحة توجد بها عدة إطارات ، ولكل منها الحق في التقاط لقطة شاشة لشاشتك بأكملها. يمكنه التقاط لقطة شاشة لجميع الإطارات الموجودة على الشاشة وجميع المحتوى ، بغض النظر عن المصادر التي تأتي منها.
لذا ، في الواقع ، هذا عيب مدمر إلى حد ما في سياسة المصدر الأصلي نفسه ، لذا يجب أن تفكر في إصلاحه. على سبيل المثال ، إذا كان لدى شخص من الإطار الأيمن القدرة على التقاط لقطات شاشة ، فسيكون قادرًا على التقاط لقطة شاشة للإطار الصحيح فقط ، وليس الشاشة بأكملها ككل.
لماذا لم ينفذها مطورو المتصفح بهذه الطريقة؟ لأنهم يعانون من ضغوط تنافسية ويضطرون إلى تركيز جهودهم على تطوير المزيد من الوظائف الجديدة ، والميزات الجديدة ، بدلاً من الانتباه إلى تحسين الأشياء المطورة بالفعل.
كانت العديد من الأسئلة التي طرحها الطلاب على الإنترنت حول هذه المحاضرة هي: "لماذا لم يفعل المطورون ما يمكنهم فعله؟ أليس هذا واضحًا؟ " أو: "يبدو أن هذا المخطط بالذات مات. ألن يكون الآخر أفضل؟ " وهكذا دواليك.
سأخبرك بصدق - نعم ، هذا أمر مؤكد ، سيكون كل شيء تقريبًا أفضل إذا أخذ المطورون هذا الأمر بمسؤولية. لذلك أشعر بالخجل من أنني على صلة بذلك.
لكن الحقيقة هي أن هذا ما كان لدينا من قبل. إذا نظرت إلى جميع العناصر التي كانت موجودة من قبل ، فسترى أن متصفحات الويب تتطور ، وأصبح الناس أكثر اهتمامًا بالأمان. ولكن ليس في حالة مشاركة الشاشة ، حيث كان المطورون قلقين جدًا من القدرات المبتكرة للمتصفح لدرجة أنهم نسوا تمامًا إمكانية حدوث تسرب قليلاً.
لذلك ، أطلب منك دائمًا الانتباه إلى الأشياء التي ناقشناها اليوم. تخيل لو كنا سنبدأ من الصفر ، ودمرنا كل ما كان أمامنا ، وحاولنا التوصل إلى سياسة أمنية أفضل ، ما رأيك ، كم عدد المواقع التي ستعمل لدينا؟ لا أعتقد أن أكثر من 2٪. لذا من المحتمل أن يشكو المستخدمون عنا.
هناك خاصية أخرى مثيرة للاهتمام تتعلق بالأمن.
بمجرد إعطاء وظيفة للمستخدمين ، من الصعب جدًا استعادتها ، حتى إذا كان استخدامها غير آمن. لذلك ، ناقشنا اليوم العديد من الأشياء المتعلقة بسياسة المنشأ ، وسنستمر في الحديث عن ذلك في المحاضرة القادمة..
, . ? ? ,
30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps ,
.
Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?