معهد ماساتشوستس للتكنولوجيا. دورة محاضرة # 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المحاضرة 10: "الإعدام الرمزي"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 11: "أور / لغة برمجة الويب"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 12:
الجزء 1 من أمان الشبكة /
الجزء 2 /
الجزء 3المحاضرة 13: "بروتوكولات الشبكة"
الجزء 1 /
الجزء 2 /
الجزء 3محاضرة 14: "SSL و HTTPS"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 15: "البرامج الطبية"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 16: "هجمات القناة الجانبية"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 17: "مصادقة المستخدم"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 18: "تصفح الإنترنت الخاص"
الجزء 1 /
الجزء 2 /
الجزء 3محاضرة 19: "شبكات مجهولة"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 20: "أمن الهاتف المحمول"
الجزء 1 /
الجزء 2 /
الجزء 3 الطالب: الآن في العديد من التطبيقات لا توجد طريقة لإزالة الأذونات.
البروفيسور: نعم ، في الإصدار الجديد من Android هذا ليس كذلك ، هناك ببساطة أوصاف إذن. لكن يمكنك استخدام مدير أذونات Android ، أو مدير أذونات Android ، والذي يسمح لك بمشاهدة قائمة بجميع الأذونات لكل تطبيق وحذف تلك التي تراها غير ضرورية على وجه التحديد. لكنني لا أعرف كيف يحظى هذا الشيء بشعبية كبيرة بين المستخدمين.
الطالب: إذا كانت التسميات لا تتوافق مع الأذونات التي يتطلبها التطبيق ، فهل يؤدي ذلك إلى خطأ خطير أو هل يستمر كل شيء في العمل بشكل جيد؟
الأستاذ: أعتقد أن ذلك يعتمد على ما يحاول التطبيق القيام به وما تسمح به التسمية. على سبيل المثال ، إذا كان أحد التطبيقات سيقوم بإرسال نية وكان إرسال هذه النية يتطلب تسمية معينة من نوع DIALPERM ، فإنه يتحول أولاً إلى شاشة الرابط ، والتي تقول: "لسوء الحظ ، لا يوجد لدى النظام تطبيق جاهز لاستلام رسالتك." واستجابة لهذا التطبيق ، فإنه يأخذ بعض الخطوات المعقولة.
خلاف ذلك ، على سبيل المثال ، عند الوصول إلى الشبكة. إذا لم يكن لديك إمكانية الوصول إلى الشبكة ، وستقوم بفتح المقبس أو إعطاء الأمر للاتصال بعنوان IP ، فسوف يرد لك kernel بالرسالة EPERM ، "العملية غير مسموح بها" ، أي أنه لا يمكنك القيام بذلك. ومن يعرف ماذا سيفعل التطبيق في هذه الحالة؟ من الممكن أن يؤدي إلى استثناء مؤشر فارغ أو بطريقة أو بأخرى القيام بشيء من هذا القبيل.
هناك حجة واحدة ضد ذلك وهي أن تطبيقات Android ، على الأقل في البداية ، لم تتوقع فشل بعض مكالماتها ، لأنهم قيل لهم أن البيان واضح أو لا شيء ، أي أن المستخدم يوافق تثبيت التطبيق أم لا. لذا قام مطورو التطبيق بكتابة الكود بشكل صحيح ، والذي يتعطل أو يفعل شيئًا غير متوقع إذا تم رفض الوصول إليه. ربما عن طريق حرمان تطبيق أذونات الوصول التي يحتاجها ، فإنك بذلك تثير فشل تشغيله.
افترض أن لديك تطبيقًا يحتاج إلى الوصول إلى الكاميرا. وإذا سحبت وصوله إلى اليمين ، فسيظهر قالب الصورة ببساطة على شاشة الهاتف الذكي ، أو ربما يتعطل التطبيق. هذا ليس جيد جدا ربما ، سيكون من الممكن إنشاء نظام أكثر تعقيدًا ، وفي حالة الحرمان من الوصول إلى الكاميرا ، ستعرض ببساطة شاشة سوداء طوال الوقت. لا يقوم Android بهذا ، ولكن يمكنك تخيل مواقف بديلة يمكن أن يحدث فيها هذا.
لذلك ، درسنا من أين تأتي هذه السطور في تسميات تطبيق Android. لكن من الذي يحدد هذه الخطوط ، من أين يحصلون على المعنى؟ يمكنك سرد جميع أنواع الخطوط في ملف البيان ، ولكن كيف يمكنك تحديد أي الخطوط مهمة ، من أين تأتي خطوط INTERNET أو FRIENDVIEW؟ من يعطيهم معنى في النظام؟
أراك ليس لديك أفكار. أعتقد أن أيا من هذه الخطوط يجب أن يكون شيئا سحريا أو محددا سلفا. كل هذه الخطوط تقريبًا عبارة عن اتفاقيات أساسًا بين تطبيقين ، عندما يكون أحد التطبيقات جاهزًا لتوفير شيء ما تحت حماية بعض خطوط التسمية ، ويريد التطبيق الآخر طلب إذن للتحدث مع التطبيق الذي يوفره هذا المكون.
لذلك ، عادة ما يتم تعريف هذه التسميات بواسطة تطبيق يوفر بعض الخدمات. إذا كان لديك إذن DIALPERM ، فيجب تحديده في التطبيق ، والذي يحدد ما يعنيه طلب رقم هاتف. على ما يبدو ، فإن تطبيق إجراء المكالمات على هاتفك هو ما يحدد هذا الخط ويقول إنه ، نعم ، يوجد شيء DIALPERM هذا ، وسيتم حماية مكوناتي به. بعد ذلك ، ستتمكن التطبيقات الأخرى التي ترغب في التفاعل مع تطبيق الاتصال من طلب إذن DIALPERM هذا.
بالطبع ، هناك بعض الأشياء المضمنة ، مثل إذن لاستخدام الإنترنت ، وكاميرا ، وهلم جرا. ولكن يمكنك اعتبارها بمثابة تطبيقات مصدر لوقت تشغيل Android ، وهي المسؤولة عن توفير الوصول إلى هذا المورد وتحديد الخط الذي يحمي هذا المورد.
ماذا يعني هذا؟ ما الأشياء الأخرى المرتبطة بالتسمية في Android ، إلى جانب حقيقة أن التطبيق يتم استخدامه عندما يحتاج إلى طلب إذن؟ اتضح أن هناك العديد من الأشياء المرتبطة بالتسمية. بالإضافة إلى السلسلة ، تحتوي التسمية على العديد من الخصائص المثيرة للاهتمام. على وجه الخصوص ، في Android هناك 3 أنواع من العلامات. الأول هو أذونات عادية ، والثاني هو أذونات غير آمنة ، والثالث أذونات موقعة.
يتيح التطبيق الذي يحدد هذا الإذن أولاً وقبل كل شيء الفرصة لتحديد النوع وكافة الحقول الأخرى للتسمية ، والتي سنتحدث عنها في الثانية. إذن ما هي أنواع العلامات هذه؟ لماذا تحتاج علامات Android إلى أنواع؟
الطالب: هل هم بمثابة تحذير للمستخدم؟
أستاذ: بالضبط. ثم لماذا لا تجعل جميع العلامات من نوع غير آمن؟ ما هي دلالات هذه الأنواع؟ ببساطة ، يتم استخدام ملصق "خطير" للسماح للتطبيق الذي يمكن أن يفسد شيئًا ما. يحذر المستخدمين عند تثبيت التطبيق عندما يطلب التطبيق الوصول إلى إذن غير آمن. في الوقت نفسه ، يجب على المستخدم إلقاء نظرة على هذه الرسالة والقول: "نعم ، أنا مستعد لإعطاء إذن غير آمن لهذا التطبيق الجديد." إذا طلبت التطبيقات تسمية من النوع المعتاد ، فلن يتلقى المستخدم رسالة حول الحاجة إلى منح إذن لهذا الإجراء. ما معنى الأذونات العادية في حالة تلقي جميع التطبيقات لها؟ هل هناك سبب لماذا يجب علينا استخدام تسميات الكتابة العادية؟
أحد الأمثلة على الدقة النموذجية في Android هو إعداد خلفيات على الشاشة. إذا كان لديك تطبيق سيقوم بتثبيت خلفية الشاشة ، فيمكنني ، بصفتي مطور التطبيق ، الإشارة في البيان الخاص بي إلى أنني أريد فقط تثبيت خلفية الشاشة لك. وإذا نقرت فوق تثبيت ، فلن يحدث شيء مثير للاهتمام ، لأنك لا تحتاج إلى منح هذا التطبيق أي أذونات.
الطالب: ولكن هذه الأذونات تتطلب عادة تأكيد منك ، أليس كذلك؟ إذا كان التطبيق يريد تغيير خلفية سطح المكتب ، فسيسألك النظام عما إذا كنت تريد تغيير خلفية الشاشة.
أستاذ: لا.
الطالب: لا؟
البروفيسور: لا ، سيؤدي فقط إلى تغيير الخلفية لأنه مجرد الوصول إلى استدعاء API. إذا كان لدي هذا الإذن ، فأنا فقط أجري مكالمة API.
الطالب: ربما يريد مطور التطبيق التأكد من عدم قيام المستخدمين بذلك عن طريق الصدفة؟
الأستاذ: نعم ، أعتقد أن هذا أحد الأسباب التي قد تحتاج إلى هذه الأذونات ، هو الرغبة في مساعدة المطور على تجنب الأخطاء. إذا كنت قلقًا من أن التطبيق الخاص بك قد يفعل شيئًا عن طريق الخطأ أو قد يكون هناك أخطاء في ذلك يمكن استخدامها ، فإن وجود مجموعة من الأذونات التي قد تتلقاها أو لا تتلقى سيؤدي إلى تقليل احتمالية إساءة استخدام التطبيق الخاص بك. لذلك إذا كان لديك تطبيق غير ضار لا يحتاج إلى تثبيت أي خلفية ، فلن تحتاج إلى طلب أي إذن ، لأنه الأفضل للمستخدم الذي تم تثبيته على هاتفه. إلى حد ما ، هذا هو نوع من الامتياز.
شيء آخر هو أن وجود علامات من النوع المعتاد يسمح لك بإجراء نوع من التدقيق ، سواء من جانب المطور أو من جانب المستخدم. إذا غير هاتفك خلفية الشاشة على الشاشة كل ثانية ، فيمكنك الدخول ورؤية التطبيق الذي لديه إذن بذلك. حتى إذا لم توافق على منح هذا الإذن ، فلا يزال بإمكانك الذهاب والتحقق من التطبيق الذي يشارك حاليًا في تغيير خلفية الشاشة.
وبالتالي ، يبدو أن هذه الأذونات العامة تدبير أمان جيد ، أو ، إلى حد كبير ، فرصة جيدة لتدقيق نشاط التطبيق. عادةً لا يتم استخدام هذا النوع من العلامات للأشياء المهمة حقًا ، مثل العمل مع البيانات أو الوصول إلى الخدمات التي تكلف مالًا.
النوع الثالث من التسمية هو إذن التوقيع. خاصية مثيرة للاهتمام في Android هي القدرة على توفير الوصول فقط إلى التطبيقات التي تم توقيعها بنفس التوقيع الرقمي كتطبيق يُعلن فيه حق الوصول. تصف مقالة المحاضرة مثالًا مع FRIENDVIEW. إذا كانت مشاهدة الأصدقاء قد حددت الإذن باستخدام هذا النوع من العلامات ، فستتمكن التطبيقات التي تم التوقيع عليها باستخدام مفتاح المطور نفسه من الحصول على نفس الإذن. ما هي الفائدة من هذا الشيء؟ لماذا ليس فقط وضع علامة عليها غير آمنة؟ لماذا نحتاج إلى نوع ثالث من الملصقات؟
الطالب: هل يسهل للمطور إدارة تطبيقاته؟
أستاذ: نعم. قد يكون لدى هذا المطور واجهات برمجة تطبيقات داخلية يريد عزلها عن تأثيرات برامج الجهات الخارجية ، ولكنه يريد في الوقت نفسه تجميع تطبيقاته معًا للتفاعل المثمر. من الناحية الافتراضية ، يمكن لمبدعي Facebook كتابة العديد من التطبيقات. يمكن أن يكون لديهم تطبيق واحد يقوم بتحميل المحتوى مسبقًا من خوادم Facebook ، ويخلط تطبيق آخر هذا المحتوى ، ويتتبع ثالث موقعك ويتفاعل كل هذه المكونات مع بعضها البعض. لمثل هذه الحالة ، يمكنهم استخدام تصريح موقع.
أحد الأسباب وراء عدم رغبتك في تعيين هذا التطبيق على أنه غير آمن هو ما يلي. إذا كنت تعرف حقًا من يمكنه الحصول على هذا الإذن ، فأنت لا تريد أن يتدخل المستخدم. نظرًا لأنه يمكن خداع المستخدم دائمًا عن طريق فرض إذن لمنح تطبيق ضار ، فمن الأفضل ألا يتدخل مطلقًا في توفير الامتيازات الداخلية لبعض التطبيقات. لذلك ، من الأفضل استخدام الأذونات الموقعة.
تحتوي التسميات أيضًا على وصف أذونات المستخدم. هذا وصف لما يستلزمه هذا الإذن. يظهر هذا الوصف عندما يُطلب منك تثبيت تطبيق جديد.
وبالتالي ، سوف ينظر وقت تشغيل Android إلى جميع سطور العلامات في بيان التطبيق الذي ستقوم بتثبيته ، ويعرض المستخدم مع وصف جميع هذه الخطوط المميزة ، على سبيل المثال: "ستمنح هذا التطبيق امتياز الاتصال ، أو السماح بإرسال الرسائل القصيرة نيابة عنك" و هكذا
سؤال مثير للاهتمام: ماذا يحدث إذا غير تطبيق ضار التسمية لبعض التطبيقات الأخرى؟ بعد كل شيء ، هذه العلامات هي مجرد سلاسل حرة الشكل. ماذا يحدث إذا كنت تطبيقًا ضارًا يقول: "أوه ، لدي هذا القرار الجديد الكبير! يطلق عليه DIALPERM. " لا يوجد لديه تسمية غير آمنة ، ووصفها لا يعطي أي شيء. هل هذا خطير؟
الطالب: ربما لن يكون قادرًا على التأثير على بنية اسم نطاق التطبيق.
الأستاذ: نعم ، هذا ممكن ، لكن لسوء الحظ ، هذا ليس إلزاميًا. عادةً ، يجب أن تحتوي جميع سلاسل الأذونات على أسماء نطاق على غرار Java ، ولكن لا توجد علاقة صارمة بين التسميات التي يحددها التطبيق واسم التطبيق الخاص بنمط Java. لا يوجد أي شيء يجبر اسم التطبيق على غرار Java على أن يرتبط بشيء ما ، لذلك لا تتاح لنا الفرصة لمعرفة ما إذا كان مفتاح المطور العام الذي يوقع على تطبيق معين يطابق شيئًا ما على com.google.som أو edu. mit.something.
هناك عيب واحد في Android ، أو على الأقل كان موجودًا عندما بحثت حديثًا في هذا السؤال. لذلك ، عند تعريف الملصقات ، يتم تقديم مبدأ "من جاء أولاً". وهذا هو ، عند تثبيت التطبيق ، فإنه يحدد تسمية معينة ، ويمكنك أن تقرر ما هو نوع التسمية وما هو وصفها. بالنسبة إلى أذونات النظام ، قد لا تكون هذه مشكلة كبيرة ، لأن أذونات النظام أو التطبيقات المضمنة ، مثل طالب الاتصال ، يتم تعريفها في البداية. لكن التطبيقات التي تم تثبيتها لاحقًا لا يمكنها تجاوز الأذونات ، لأن هذا يرجع إلى الإطار.
المشكلة هي أنه إذا قمت بتثبيت تطبيق ضار لأول مرة ، ثم تطبيق مهم ، فمن المحتمل أن يشوه التطبيق الضار التسميات المستخدمة لاحقًا من قِبل التطبيق حسن النية. تصف مقالة المحاضرة الحالة التي يجبر فيها المهاجم المستخدم على تثبيت تطبيق ضار يقوم بتغيير نوع التسمية لتطبيق FRIENDVIEW إلى نوع عادي مع سطر وصف مثل "لا يوجد شيء مثير للاهتمام على الإطلاق." في وقت لاحق ، عند تثبيت تطبيق FRIENDVIEW ، لم يعد بإمكانه تجاوز هذا التصنيف ، لأنه تم تعريفه بالفعل ، والآن لن يتمكن المستخدم من منع التطبيقات الأخرى من استخدام إذن مشاهدة الأصدقاء.
الطالب: ربما يمكن للنظام أن يحذر من محاولات تغيير القرار؟
الأستاذ: من حيث المبدأ ، فإن الإطار قادر على ذلك ، لكن عندما حاولت القيام بذلك ، لم تصدر أي رسائل. إذا قمت بتثبيت تطبيق يعرف تسمية تم تعريفها بالفعل ، فإن النظام لا يفعل شيئًا ، فهو يتجاهل ببساطة تعريف الملصق الجديد ويستخدم التعريف القديم. ربما تكون هذه هي المشكلة ، بسبب أي شيء يمكن أن يحدث خطأ. على الأقل ، يجب أن يقول النظام: "أنا أرفض تثبيت هذا التطبيق لأنه يحتوي على تعريف تسمية موجود بالفعل."
الطالب: ... وينتمي إلى تطبيق آخر.
أستاذ: نعم ، وربما ينتمي إلى مفتاح آخر. ثم على الأقل هناك فرصة لإصلاح كل شيء. لم أتبع هذه المشكلة ، ربما تم إصلاحها بالفعل. في أي حال ، هذه مشكلة مثيرة للاهتمام ، عندما يتعين عليك حقًا تتبع هذه الأسماء ومعرفة من يملك هذا الاسم ، والحصول على الحق في ارتكاب مثل هذه الإجراءات أمر مهم للغاية حقًا.
تتعلق مشكلة أخرى مثيرة للاهتمام في Android بمستقبل البث ، أو مستقبل رسائل البث. يخلق القدرة على تلقي الرسائل من التطبيقات الأخرى والرد عليها ، وتنفيذ شيء مثل إرسال الرسائل بين التطبيقات. أولاً يجب أن أصف كيف تتفاعل هذه الرسائل مع المتلقي. تُستخدم مستقبلات البث في تطبيق واحد ، وهو قادر على الإعلان عن بعض الأحداث لأي تطبيق آخر في النظام.
كما نعلم ، عادة ما يتم توجيه النوايا إلى مكون معين ، على سبيل المثال ، عارض صور JPEG. ولكن حول أحداث مثل تحميل النظام أو "أصدقائي في مكان قريب" ، يمكنك الإعلان عن كل تطبيق يتعلق به. هذا هو ما البث المتلقي ل.
هناك شيئان يثيران قلقك. أولاً ، مصادقة مصدر الرسالة ، أي أنك تريد معرفة من أرسل هذه الرسالة وما إذا كان بإمكانك الوثوق بها. ثانياً ، أنت تريد التحكم في من يتم توجيه هذه الرسالة إلى ومن يمكنه استلامها.
يبدو لي أن مطوري Android لم يطبقوا هذه الأشياء بشكل صحيح. في أي حال ، في الإصدار الأولي من Android ، عند إرسال رسالة بث إلى جميع المكونات الأخرى للنظام ، قد تدعم هذه التطبيقات أو لا تدعم هذه الرسالة. لذلك ، إذا كان لديك تطبيق Friends Viewer ، فسوف يدعم هذه الرسائل باستخدام المكونات المناسبة ، مثل الإجراء أو التاريخ / MIME ، في عامل تصفية النوايا. لكن معظم التطبيقات يمكنها دائمًا دعم جميع أحداث البث في النظام ، ويمكنك أن ترى كل ما يحدث على الهاتف ، أو كل شيء يتم بثه.
وبالتالي ، أضاف إطار Android حجة إضافية للتطبيقات للإشارة إلى من يمكنه رؤية رسالة البث.
, , – , , . , , , , .
, , , , , , . Android, , , , .
, ? , « » , . , ? ?
: ? ?
: , . App 1 RM, , , App 2, , . , App 1 , ? Android ?
, . , , . , . ? , « »?
: , , ?
: . , — . , , « ».
Broadcast receiver, , , . , , , Label.
. Android , . « », . , . , , , .
RPC , RPC-, , . , .
: ?
: , , .
: , …
: , . – . . : « ».
: ?
: .
: , ?
: , , . . , , , . , — . , : « , », , , Dangerous Description.
, : „ , ». , , , , . , Android , .
, , Android. , , . , «», « ». , , .
, , . , , , , , . , Java. , , , , .
Android . - , , , , . «» , RPC . , .
, , . , Android , 5 6 . , , , - «». , , .
, Android , , Apple . , Apple iPhone , .
«», «», , , , , , , . , . , , Android, . , - .
, Android .
.
, . ? ? ,
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 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD بسرعة 1 جيجابت في الثانية 100 TV من 249 دولارًا في هولندا والولايات المتحدة الأمريكية! اقرأ عن كيفية بناء البنية التحتية فئة باستخدام خوادم V4 R730xd E5-2650d تكلف 9000 يورو عن بنس واحد؟