سجل التغيير: مشروع OWASP لأفضل 10

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

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

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

المشكلات التي تمت إزالتها من قائمة OWASP العشرة الأوائل

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

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

تزوير عبر الموقع

تزوير الطلب عبر المواقع (CSRF) هو أحد "الخاسرين" في التكرار الأخير للمشروع. لقد اختفى لأن الكثير من أطر عمل الويب الحديثة تتضمن آليات دفاع CSRF. وبالتالي تقل احتمالية تعريض تطبيقاتك للتهديد بسرعة.

بغض النظر عن خروج CSRF من القائمة ، لا يزال من الجيد تحديث ذاكرتنا. دعونا نتأكد من أنه لا يعود أقوى من أي وقت مضى.

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

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

أحد أشهر الأمثلة هو خداع المستخدم لتحويل الأموال من حسابه إلى الحساب الذي يتحكم فيه المهاجم. يقوم المستخدم بتسجيل الدخول إلى نظام مصرفي إلكتروني للتحقق من رصيد حسابه. بعد ذلك ، يزورون منتدى عبر الإنترنت للتحقق من تقييمات الهاتف المحمول الجديد. مهاجم ، يصطاد بالديناميت ، ينشر مراجعة تتضمن صورة بها ارتباط تشعبي يبدو معطلاً. بدلاً من الارتباط التشعبي الحقيقي ، يستخدم المهاجم ارتباطًا تشعبيًا يستخدمه النظام المصرفي الإلكتروني داخليًا لتحويل الأموال من الحساب A إلى الحساب B: https://payments.dummybank.com?receiver=attacker&amount=100 . يجعل النظام المصرفي المستخدم المعتمد هو المرسل والقيمة من معلمة "المتلقي" هي متلقي الأموال. بالطبع ، يحدد المهاجم حسابه الخارجي باعتباره المتلقي.

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

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

عند تصميم أنظمتك ، ضع في اعتبارك ما يلي:

• لا تستخدم طلبات HTTP GET لتضمين الإجراءات التي تعدل أحد الموارد. يجب عليك فقط استخدام هذه الطلبات لاسترداد المعلومات. تذكر أن القاعدة الأساسية هي جعل طلبات GET غير فعالة.
• هل ، عند نقل البيانات داخليًا باستخدام طلبات HTTP POST ، تميل إلى إرسال البيانات بتنسيق JSON أو XML أو أي تنسيق آخر غير ترميز المعلمات كسلسلة استعلام. يقلل استخدام تنسيق بيانات غير تافه من خطر قيام شخص ما بإنشاء نموذج HTML مزيف والذي سيرسل البيانات إلى خدمتك.
• تأكد من إنشاء وإدراج رمز مميز فريد وغير متوقع في نماذج HTML الخاصة بك. يجب أيضًا أن تكون هذه الرموز المميزة فريدة لكل طلب. سيؤدي التحقق من وجود هذه الرموز وصحتها إلى تقليل مخاطر حدوث التهديدات. لمعرفة الرمز المميز واستخدامه في طلباتهم المزيفة ، سيحتاج المهاجمون إلى الوصول إلى نظامك وأخذ رمز مميز مباشرة من هناك. نظرًا لأن الرموز المميزة تستخدم مرة واحدة فقط ، فلا يمكنهم إعادة استخدامها في التعليمات البرمجية الضارة.

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

ضع في اعتبارك أن CSRF لم تختف ، فهي ليست شائعة كما كانت من قبل.

عمليات إعادة التوجيه وإعادة التوجيه غير الصالحة

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

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

على سبيل المثال ، غالبًا ما تنفذ تطبيقات الويب تسجيل الدخول مع دعم عمليات إعادة التوجيه إلى آخر صفحة تمت زيارتها. لتتمكن من القيام بذلك بسهولة ، قد تبدو سمة الإجراء لنموذج HTML مثل http://myapp.example.com/signin؟url=http://myapp.example.com/puppies . أنت معجب كبير بالجراء ، لذلك من المنطقي تثبيت ملحق متصفح يستبدل المواقع المفضلة بالصور المصغرة لكلابك المفضلة. لسوء الحظ ، إنه عالم يأكل الكلاب. قرر مؤلف ملحق المتصفح الاستفادة من حبك غير المشروط وتقديم "ميزة" إضافية. في كل مرة تزور فيها موقع المعجبين بالجراء المفضل لديك ، فإنه يستبدل معلمة "url" في سمة الإجراء الخاصة بالنموذج برابط إلى موقعهم الخاص. نظرًا لأن الموقع يبدو متشابهًا تمامًا ، فعندما تقدم تفاصيل بطاقة الائتمان الخاصة بك لشراء بطاقات لعب جرو ، فأنت في الواقع تمول مهاجمًا ضارًا ، وليس هوايتك.

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

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

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

القضايا المدمجة

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

كسر التحكم في الوصول

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

مراجع الكائن المباشر

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

يوضح التطبيق الذي يقوم بتعيين عنوان URL لنموذج حذف ملف التعريف http://myapp.example.com/users/15/delete أن هناك 14 مستخدمًا آخر على الأقل داخل التطبيق. إن معرفة كيفية الوصول إلى شكل حذف المستخدمين الآخرين ليس علم الصواريخ في هذه الحالة.

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

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

التحكم في الوصول على مستوى الوظيفة مفقود

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

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

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

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

مشكلات جديدة في قائمة العشرة الأوائل OWASP

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

كيانات XML الخارجية

يقدم معيار XML فكرة غير معروفة تسمى الكيان الخارجي ، والتي تعد جزءًا من تعريف نوع بيانات المستند (DTD). يسمح لمؤلفي المستندات بتحديد روابط إلى كيانات خارجية يمكن الرجوع إليها بعد ذلك وتضمينها في المستند الرئيسي. مثال بسيط للغاية هو:

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

أثناء التحليل ، مرجع &bar; يتم استبداله بالمحتوى من الكيان المحدد ، وبالتالي ينتج عنه <foo>baz</foo> .

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

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

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

تتمثل إحدى "السمات" المزعجة بشكل خاص في هذه الثغرة الأمنية في إمكانية تنفيذ هجوم رفض الخدمة بسهولة. تتمثل إحدى الطرق السهلة للقيام بذلك في سرد ​​محتويات ملف لا نهاية له مثل /dev/random . الطريقة الأخرى هي إنشاء سلسلة من الكيانات ، كل منها يشير إلى الكيانات السابقة عدة مرات. هذا يحول المرجع النهائي إلى جذر لشجرة يحتمل أن تكون واسعة جدًا وعميقة يمكن أن يؤدي تحليلها إلى استنفاد ذاكرة النظام. يُعرف هذا الهجوم باسم Billion Laughs. كما هو موضح في ويكيبيديا ، يتم تحديد سلسلة من الكيانات الوهمية ، مما يوفر فرصة للمهاجم لتضمين مليار لول في المستند النهائي.

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

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

إلغاء التسلسل غير الآمن

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

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

إذا وجد مستخدم فضولي ملف تعريف ارتباط على أجهزته ، فيمكنه رؤية شيء مثل هذا:

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

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

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

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

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

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

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

بمجرد أن يحتاج الكائن إلى إلغاء تسلسله (unpickled) ، يتم استدعاء list الوظائف باستخدام وسيطة واحدة فقط. list الوظائف عبارة عن مُنشئ قائمة في Python ، وتنتج الوظيفة itertools.count لانهائيًا للقيم ، بدءًا من المعلمة التي تم تمريرها. يمكن أن يؤدي تحويل أداة التكرار اللانهائية إلى قائمة محدودة إلى عواقب وخيمة على أداء النظام واستقراره.

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

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

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

التسجيل والمراقبة غير كافيين

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

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

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

لبذل قصارى جهدك لحماية نفسك من مثل هذه الهجمات ، قم بالخطوات التالية:

• سجل جميع حالات الفشل والتحذيرات التي تحدث في التطبيق ، سواء كانت استثناءات تم إلقاؤها في الكود أو في التحكم في الوصول والتحقق من الصحة وأخطاء معالجة البيانات. يجب تكرار جميع المعلومات المخزنة واستمرارها لفترة كافية بحيث يكون الفحص والتحليل بأثر رجعي ممكنًا.
• من المهم تحديد التنسيق وطبقة الثبات. من السهل تحقيق وجود ملف ضخم بتنسيق نص تعسفي ؛ معالجته في وقت لاحق ليس كذلك. اختر خيار التخزين الذي يجعل من السهل تخزين البيانات وقراءتها والتنسيق الذي يسمح بالتسلسل السهل والسريع (de). يؤدي تخزين JSON في قاعدة بيانات لتمكين الوصول السريع إلى تسهيل الاستخدام. حافظ على قاعدة البيانات صغيرة عن طريق نسخها احتياطيًا بانتظام.
• إذا كنت تتعامل مع بيانات مهمة وقيمة ، فاحتفظ بسلسلة من الإجراءات التي يمكن اتباعها لتدقيق الحالة النهائية. تطبيق آلية لمنع العبث بالبيانات.
• اجعل أنظمة الخلفية تحلل السجلات وتنبهك في حالة ظهور شيء ما. عمليات التحقق - التي هي بسيطة مثل الاختبار إذا حاول المستخدم بشكل متكرر الوصول إلى جزء محمي من التطبيق - تساعد. لا تفرط في تحميل النظام بفحوصات وهمية. يجب تشغيل أنظمة المراقبة كخدمات منفصلة ويجب ألا تؤثر على أداء النظام الرئيسي.

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

الخطوات التالية

من المهم أن تكون على دراية بالتهديدات ونقاط الضعف المحتملة في تطبيقات الويب. بل إن الأمر الأكثر أهمية هو البدء في التعرف عليها في تطبيقاتك وتطبيق التصحيحات لإزالتها.

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

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

تستفيد مشاريع تطبيقات الويب الجديدة والحالية ، خاصة تلك التي تتبع مبادئ Agile ، من التخطيط المنظم للجهود المبذولة لتأمين تطبيقاتها. يكون التخطيط لاختبارات OWASP ASVS أسهل إذا قررت استخدام OWASP Security Knowledge Framework. إنه تطبيق لإدارة سباقات السرعة الموجهة نحو اختبار الأمان ، ويأتي مع مجموعة من الأمثلة حول كيفية حل مشكلات الأمان الشائعة ، وقوائم تحقق سهلة المتابعة تستند إلى OWASP ASVS.

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

أثناء تطوير التطبيق ، تأكد مما يلي:

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

خاتمة

على الرغم من أنه ، كما يوحي الاسم ، فإن مشروع OWASP Top Ten يسرد فقط عشرة ثغرات أمنية ، هناك الآلاف من الفخاخ والأبواب الخلفية المحتملة التي تهدد تطبيقاتك ، والأهم من ذلك ، المستخدمين وبياناتهم. تأكد من أن تكون على اطلاع وتحديث معرفتك باستمرار لأن التغييرات والتحسينات التكنولوجية لها جوانب إيجابية وسلبية.

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