الثقة في SDKs المحمول

أدت القصة الخلفية الأخيرة في مكتبة NPM الأكثر شيوعًا إلى التفكير في مدى ثقتنا في كود الطرف الثالث وكيف نستخدمه بجرأة في مشاريعنا (وبالتالي يحل محله المستخدمون بمنتجاتنا).

ولكن حتى قبل أشهر من "الرعد المدقع" ، تحدث فيليكس كراوس (المعروف لمطوري الأجهزة المحمولة باسم منشئ Fastlane) في مؤتمر Mobius 2018 Piter لدينا عن نفس الثقة: ثقة مطوري الأجهزة المحمولة بأدوات تطوير البرامج SDK من الأطراف الثالثة. إذا قمنا بتنزيل SDK الشهير من شركة معروفة ، هل كل شيء على ما يرام هناك ، أو هل يمكن أن يحدث خطأ أيضًا؟ أين هو ناقل الهجوم وماذا يجب أن نفكر في هذا الصدد؟

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

SDK الأمن

بعد معرفة أي من SDKs هي الأكثر شيوعًا في تطوير iOS اليوم ، قررت استكشاف مدى تعرضهم لهجمات الشبكة الأكثر شيوعًا. تبين أن 31٪ منهم كانوا ضحايا محتملين لهجمات بسيطة في الوسط ، مما يعني أن المتسلل يضخ شيفراته الضارة في SDK.

لكن بشكل عام ، هل يستحق الأمر أن تكون خائفًا؟ ما هو أسوأ ما يمكن أن يفعله مع SDK الخاص بك؟ هل هذا كل شيء خطير؟ يجب أن تفهم أن SDK المضمنة في حزمة التطبيق الخاص بك تعمل في نطاقها - أي أن SDK يمكنها الوصول إلى كل شيء يعمل عليه التطبيق الخاص بك. إذا كان المستخدم يسمح للتطبيق بالوصول إلى بيانات تحديد الموقع الجغرافي أو ، على سبيل المثال ، الصور ، فإن هذه البيانات تصبح متاحة أيضًا لـ SDK (لا يلزم وجود أذونات إضافية). البيانات الأخرى التي يمكن الوصول إليها من SDK: iCloud البيانات المشفرة ، الرموز المميزة API ، بالإضافة إلى جميع طرق عرض UIKit التي تحتوي على الكثير من المعلومات المختلفة. إذا قام أحد المتطفلين باعتراض SDK لديه حق الوصول إلى هذا النوع من البيانات ، فإن العواقب ، كما تعلمون ، قد تكون خطيرة للغاية. في الوقت نفسه ، سوف يتأثر جميع مستخدمي التطبيق في نفس الوقت.

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

الشبكة

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

كما تتذكر ، فإن الفرق الرئيسي بين بروتوكول HTTPS وبروتوكول HTTP هو تشفير البيانات أثناء الإرسال. يعني عدم وجود تشفير في HTTP ، إلى حد كبير ، أن أي مضيف موجود داخل الشبكة ، إذا رغبت في ذلك ، يمكنه الاستماع بحرية وتعديل أي حزم يتم إرسالها عبره ؛ في الوقت نفسه ، لا يمكن التحقق مما إذا كانت سلامة الحزمة قد تم انتهاكها أم لا. كل هذا صحيح بالنسبة لشبكات Wi-Fi العامة وشبكات Ethernet المحلية المحمية بكلمة مرور.

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

سابقا ، عملت كل شيء على النحو التالي. عند إدخال "google.com" في شريط العناوين دون تحديد بروتوكول ، أرسل المستعرض بشكل افتراضي طلبك عبر HTTP. ولكن نظرًا لأن خادم Google يفضل التواصل عبر HTTPS ، فاستجابًا له ، تلقيت رابطًا جديدًا (إعادة التوجيه) بالبادئة "https: //". فيما يلي شاشة من Charles Proxy (أداة مراقبة حركة مرور HTTP / HTTPS) توضح ذلك:



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

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

لن نفكر فيه بالتفصيل. الشيء الرئيسي الذي يجب فهمه: يتكون كل شيء من عدة طبقات مسؤولة عن أشياء مختلفة وفي نفس الوقت تتفاعل باستمرار مع بعضها البعض.

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



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



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

ومن المثير للاهتمام ، في الواقع ، تتمتع نفس الصلاحيات بمزودي خدمات الإنترنت وشبكات VPN. إنهم وسطاء في تفاعلك مع الإنترنت وبنفس الطريقة يشكلون تهديداً محتملاً لعملية خداع ARP.

لا يوجد شيء جديد في مقاربة الرجل المتوسط. ولكن كيف ينطبق كل هذا بالضبط على أجهزة SDK المحمولة؟

تفاصيل المحمول

CocoaPods هي أداة قياسية لإدارة التبعية تستخدم في تطوير iOS. يعتبر استخدام CocoaPods لكود مفتوح المصدر أمرًا آمنًا من الناحية العملية - يتم استضافته عادةً على GitHub ، وعادةً ما يتم الوصول إليه عبر HTTPS أو SSH. ومع ذلك ، تمكنت من العثور على ثغرة أمنية تستند إلى استخدام روابط HTTP.

الحقيقة هي أن CocoaPods يجعل من الممكن تثبيت SDK مع شفرة المصدر مغلقة ، وتحتاج فقط إلى تحديد URL. لا يوجد التحقق من أن حركة المرور سيتم تشفيرها ، والعديد من SDKs تقدم عنوان HTTP.

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

من المثير للاهتمام أكثر التفكير في كيفية تثبيت SDK غير الحسية وليس من CocoaPods. خذ على سبيل المثال ، منصة Localytics.



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

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



واحد منهم ينتمي لي. أي واحد من المطورين الحقيقيين ، وليس كذلك؟ محاولة لفهم.

تحقق الممارسة

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



أنا عهد المعتادة التوت بي لاعتراض. المدرجة في الشبكة المحلية ، وقال انه يمكن الاستماع إلى حركة المرور في ذلك. في الحزم التي تم اعتراضها ، كان عليه أولاً استبدال جميع روابط HTTPS بروابط HTTP ، ثم استبدال جميع ملفات. zip الخاصة بـ Localytics iOS بملف hack.zip. كل هذا تبين أنه بسيط وعملت مع اثارة ضجة.



ظهر ملف trollface.jpg في الأرشيف الناتج ، وظهر السطر "Modified by KrauseFx" في ملف Info.plist. كم كان مطلوبا لمثل هذا الهجوم؟ شرطين فقط:

1. تمكنوا من الوصول إلى شبكتك (تذكر أنه بالنسبة لموفري الإنترنت و VPN ليس هذا على الإطلاق). كم عدد سلاسل القهوة والفنادق التي نتواصل معها؟
2. بدء التنزيل غير مشفر.

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

أقترح النظر في موقع أمازون. AWS Mobile SDK هي SDK الشخصية الخاصة بهم ، والتي توفر للمطورين التفاعل مع الخدمة.



يبدو أن الرمز "الآمن" ، وهو موقع مشهور ، ينذر بشيء. ولكن للأسف - فقط للوهلة الأولى. يشار إلى رابط تنزيل SDK بدون بادئة على الإطلاق (لا https: // ولا http: //). وفي الوقت نفسه ، ينبغي أن يأخذ المستخدم إلى مضيف آخر. لذلك ، سوف ينتقل المستعرض من HTTPS إلى HTTP. كما ترون ، هنا تنزيل SDK غير مشفر! في الوقت الحالي ، تم إصلاح الثغرة الأمنية بالفعل من قبل مطوري Amazon ، ولكن كان لديها حقًا مكان.

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

سرقة بيانات Apple ID

الآن دعونا ننظر إلى مشكلة أخرى. يجب أن يكون مستخدمو IPhone على دراية بهذه النافذة المنبثقة بانتظام:



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

غالبًا ما يطلب iPhone بيانات مصادقة iCloud ، وبالنسبة للمستخدم ، يظل سبب الطلب عادةً غير واضح. المستخدمين معتادون عليها حتى أنهم يدخلون كلمة المرور تلقائيًا. مسألة من يسأل عن كلمة المرور - نظام التشغيل أو التطبيق - ببساطة لا تتبادر إلى الذهن.

إذا كنت تعتقد أنه من الصعب الحصول على عنوان البريد الإلكتروني المرتبط به معرف Apple ، فأنت تبالغ في ذلك: يمكن القيام بذلك من خلال دفتر جهات الاتصال ومن خلال حاويات iCloud (إذا كان لديك حق الوصول إلى تطبيق iCloud ، والذي يمكنك معرفة المزيد حوله من عيوب المستخدم لهذا التطبيق). والخيار الأبسط هو مطالبة المستخدم بإدخال بريده الإلكتروني شخصيًا: من الناحية النظرية ، لا ينبغي أن يفاجئه ذلك ، لأنه في نظام التشغيل iOS هناك نوع من النوافذ لا يطلب كلمة مرور فحسب ، بل وأيضاً بريدًا إلكترونيًا.

اعتقدت: "ماذا لو أخذت هذا الكود الخاص بنموذج الطلب الذي لدي ، وبمساعدة خداع SDK ، اخترق العديد من التطبيقات المختلفة معها لسرقة جميع كلمات مرور iCloud معهم؟" ما مدى صعوبة هذه المهمة؟



افترض أن لدينا جهاز Mac نظيف تمامًا ، بدون تثبيت أي VPN أو خادم وكيل ، ولكن على نفس الشبكة ، لدينا Raspberry Pi. على نظام Mac في Xcode ، لدينا مشروع مشروع iOS مفتوح يحتوي على الحد الأدنى المطلق من الكود - عرض خريطة بسيط للمنطقة ولا شيء أكثر من ذلك.

افتح الآن المتصفح ، انتقل إلى Amazon Web Services. ابحث عن صفحة AWS Mobile SDK واتبع رابط التنزيل. قم بفك الحزمة الثنائية التي تم تنزيلها واسحب كل الأطر إلى مشروعنا في Xcode. ثم نستورد المكتبات. لسنا ملزمين حتى بالاتصال بأي رمز - يكفي تنزيله. ألاحظ أنه خلال العملية برمتها لم يقدم Xcode أي تحذيرات.

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

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

ومرة أخرى ، كم استغرق منا تنفيذ الهجوم؟ كان من الضروري أن يكون جهاز الكمبيوتر الخاص بنا على الشبكة (وكان Raspberry Pi كافيًا). HTTP أو HTTPs - في هذه الحالة لا يهم ، لن يحفظ التشفير الموقف. لقد تم نقل جميع الأدوات البرمجية التي استخدمتها - أبسطها - من الوصول العام. في الوقت نفسه ، أنا مطور عادي ، دون الكثير من المعرفة والخبرة من الخارقة.

استحواذ الإدارة

قدم المثال السابق تعليمة برمجية ضارة في تطبيق iOS. ولكن ماذا لو استطعنا السيطرة على جهاز الكمبيوتر المطور بشكل عام؟ إن القدرة على تشغيل الشفرة على جهازك ، كما تعلمون ، تعطي قوة هائلة للقراصنة. سيكون قادرًا على تنشيط الوصول عن بُعد عبر SSH ، وتثبيت كلوغر ، إلخ. سيكون قادرًا على مراقبتك في أي وقت ، وتسجيل أفعالك ، واستخدام نظام الملفات. سيتمكن أيضًا من تثبيت شهادات طبقة المقابس الآمنة الجديدة واستخدامها لاعتراض جميع الطلبات التي تقدمها إلى الشبكة. باختصار ، لدى شخص ما الفرصة لتشغيل التعليمات البرمجية على جهاز الكمبيوتر الخاص بك - فأنت في وضع سيء للغاية.

فكرت ، "ما هو iOS SDK الذي يمكنني استخدامه لهذا؟" هناك خدمة توفر SDK مع الأمر curl ورابط HTTP مع الإخراج المعاد توجيهه إلى الأمر sh. وهذا هو ، سوف محطة تحميل وتشغيل البرنامج النصي قذيفة.



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



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

وخلال هذا الوقت ، تمكنت آلية هجوم بسيطة تتضمن رسالتي Raspberry Pi من العمل. يحتوي البرنامج النصي shell UpdateSDK المحمل بواسطة المستخدم على مجموعة صغيرة من التعليمات البرمجية الخاصة بي. والآن يُسمح لي بالوصول إلى جهاز الكمبيوتر الخاص بك عن بُعد عبر SSH ، كما أن لديك كلوغر مثبتًا.



على اليسار ترى محطة "your" ، وعلى اليمين يوجد جهاز Raspberry Pi ، والذي يعرض في الوقت الفعلي بالفعل كل ما تدخله على لوحة المفاتيح. بعد أن بدأت مع Raspberry Pi SSH ، قمت بتسجيل الدخول باستخدام تسجيل الدخول وكلمة المرور المسجلة للتو باستخدام keylogger ، وبهذه الطريقة أحصل على حق الوصول الكامل للتحكم في جهاز Mac ونظام الملفات الخاص به. وكذلك ، على الأرجح ، لدى شركة صاحب العمل حق الوصول إلى الكثير.

في الختام

ما مدى احتمال حدوث هذا لك؟ بعد كل شيء ، لا يزال المطورين يحاولون استخدام شبكة Wi-Fi آمنة ، وشراء VPN.

شخصياً ، اعتقدت أيضًا أنني كنت حذرًا حتى يومًا ما فتحت إعدادات جهاز Mac الخاص بي واكتشفت في تاريخ أكثر من 200 اتصال لشبكات Wi-Fi غير آمنة. كل هذا الصدد هو تهديد محتمل. وحتى باستخدام شبكة موثوق بها ، لا يمكنك التأكد من أمانك بنسبة 100٪ ، لأنه لا يمكنك معرفة ما إذا كان أي جهاز على هذه الشبكة قد تعرض للاختراق (كما رأينا للتو).

الهجمات على شبكات Wi-Fi غير الآمنة شائعة جدًا. يسهل الاحتفاظ بها في الأماكن العامة ، مثل الفنادق والمقاهي والمطارات والمؤتمرات بالمناسبة: تخيل متحدثًا يتحدث عن نوع من SDK ، وكما جرت العادة ، يحاول جزء من الجمهور تثبيته بالتوازي عن طريق الاتصال بشبكة Wi-Fi الموزعة هنا . وكما قلت ، من السهل جدًا إساءة استخدام حقوقك لمزود الشبكة.
بنفس الطريقة مع VPN - يمكنك فقط تسليم نفسك إلى الموفر. ومن الأفضل الوثوق به - مزود VPN أو شبكتك المحلية ومستخدميها؟ غير واضح.

في تشرين الثاني (نوفمبر) 2017 ، أجريت بحثي وتحليله لوجود نقاط الضعف المدرجة في أعلى 41 SDKs شيوعًا لـ iOS (دون احتساب SDKs من Google و Facebook ، وكلها محمية).



كما ترون ، 31.7 ٪ من SDKs لم يجتازوا الاختبارات. تمكنت من إبلاغ جميع الموردين تقريبًا بالمشاكل الحالية. من واحدة تلقيتها إجابة حرفيا على الفور ، تم حل المشكلة في غضون ثلاثة أيام. كان رد فعل خمسة فرق أيضًا ، لكنه قضى وقتًا أطول في المراجعة - حوالي شهر. سبعة لم يزعجوا الإجابة على تقريري على الإطلاق ولم يصحح أي شيء حتى يومنا هذا. اسمحوا لي أن أذكركم أن هذا لا يتعلق ببعض المشاريع غير المعروفة. جميعها من بين أكثر SDKs شهرة ولديها عشرات الآلاف من المستخدمين الذين يطورون تطبيقات iOS باستخدام هذه SDK ، والتي بدورها تستخدم من قبل ملايين مستخدمي iPhone.

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

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

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

إذا كنت قد أحببت هذا التقرير ، فاحرص على الانتباه: سيتم عقد الإصدار التالي من St. Petersburg Mobius يومي 22 و 23 مايو ، وستكون التذاكر معروضة للبيع بالفعل ، وستصبح أكثر تكلفة بشكل تدريجي.