قررنا تكرار العمل البحثي الواسع النطاق لعام 2015 وتحليل أمن موارد الويب للبنوك الرائدة في العالم. منذ ذلك الحين ، أصبحت الخدمات المصرفية عبر الإنترنت ليست أكثر انتشارًا فحسب ، بل أصبحت أكثر انتشارًا. في الواقع ، إنه سريع ومريح ، لكن كم هو آمن؟ هل تتبع البنوك أفضل الممارسات؟
مثل آخر مرة ، في عملية البحث ، أرسلنا استعلامات HTTP و DNS عادية دون التدخل في البنوك. أي ، يتم جمع جميع البيانات كما يمكن للمستخدم العادي القيام به من خلال زيارة مورد. للتحليل ، اخترنا 200 بنك روسي و 400 بنك أجنبي. تحت قص مقتطفات من الدراسة. يمكن الحصول على النص الكامل على موقعنا.
هذه المرة قمنا بتوسيع مجال البحث بإضافة موارد عبر الإنترنت للمصارف الأجنبية إلى النطاق. هذا يسمح لك بمقارنة الموقف بأمان الويب في روسيا وبلدان العالم الأخرى.
بالنظر إلى المستقبل ، نأسف لملاحظة أن الطرق التقليدية لزيادة مستوى الأمان تتجاهلها البنوك في أغلب الأحيان ، رغم أنها لا تتطلب موارد مالية وتقنية عالمية. إن تفويت الفرص أمر تطوعي ، لكن الأمر مختلف تمامًا عن استخدامها بشكل غير صحيح. على سبيل المثال ، في حالة سياسة أمان المحتوى ، يكون لخمس الموارد التي تم النظر فيها إعدادات ، وكل واحد منهم تقريباً لديه أخطاء في التكوين. كجزء من الدراسة ، حاولنا التفكير بالتفصيل في كيفية التعامل مع هذا النوع من الإعدادات بشكل صحيح ، وما هي الأخطاء التي تحدث في أغلب الأحيان.
غرض البحث
الهدف الرئيسي من هذه الدراسة هو تقييم مستوى أمان الموارد المصرفية المتاحة للجمهور: الموقع الرسمي و RBS ، وفقًا لأفضل الممارسات لإعداد موارد الويب. لقد اخترنا عددًا من النقاط ، والتي يمكن التحقق من امتثالها ، باستثناء أي ضرر فني ودون تدخل في عمل البنك. من المهم أن نلاحظ أن جميع المعلومات التي نجمعها متاحة للجمهور ، ومعالجة هذه البيانات لا تتطلب مهارات متعمقة: إذا كنت ترغب في ذلك ، يمكن لأي مستخدم مهتم الوصول إلى هذه النتائج.
موضوع الدراسة
للاختبار ، اتخذنا البنوك TOP-200 في روسيا. يمكن العثور على القائمة الكاملة على: http://www.banki.ru/banks/ratings/ (البيانات الحالية اعتبارًا من مارس 2019).
اخترنا أيضًا 20 مصرفًا من 30 دولة أخرى (قائمة)النمسا
روسيا البيضاء
بلجيكا
بلغاريا
البوسنة والهرسك
البرازيل
المملكة المتحدة
هنغاريا
ألمانيا
الدنمارك
إسرائيل
أيرلندا
إسبانيا
إيطاليا
كندا
الصين
ليختنشتاين
لوكسمبورغ
مالطا
هولندا
النرويج
الأمارات العربية المتحدة
بولندا
البرتغال
الولايات المتحدة الأمريكية
فنلندا
فرنسا
سويسرا
السويد
اليابان
الخطوة الأولى حددنا جميع المواقع الرسمية وموارد الإنترنت في المكتب الإقليمي للأفراد والكيانات القانونية. ثم ، بالنسبة لكل بنك ، تم إجراء الشيكات باستخدام عدة طلبات قياسية باستخدام بروتوكولات HTTP / HTTPS / DNS ، على غرار الطلبات المعتادة من عملاء البنوك. قائمة مجمعة:
- إعدادات SSL - توفر فرصة لتنفيذ واحدة من الهجمات العديدة المرتبطة بـ SSL ؛
- إعدادات DNS - تتيح لك الحصول على معلومات حول نطاقات الشركة الفرعية.
ما يلي هو وصف ونتائج بعض الشيكات. نولي اهتمامًا خاصًا للقسم المخصص لسياسة أمان المحتوى: حيث حاولنا إبراز الأخطاء الرئيسية ونعلم كيف يمكن تجنبها. وصف كامل ونتائج جميع الشيكات في الدراسة .
تجريب
SSL / TLS
إحدى أهم النقاط هي التحقق من إعدادات SSL / TLS ، مثل اليوم ، تعد بروتوكولات التشفير هذه الطريقة الأكثر شيوعًا لتوفير تبادل آمن للبيانات عبر الإنترنت. التهديد المحتمل الرئيسي هو استخدام هجمات اعتراض حركة المرور.
تم اختيار الشيكات التالية:
تصنيف
يحتوي SSL / TLS على عدد كبير من الإعدادات والميزات التي تؤثر ، بدرجة أو بأخرى ، على أمان كل من الاتصال نفسه والمشاركين فيه ككل. لإجراء تقييم شامل لهذا الإعداد ، استخدمنا الوظيفة التي توفرها Qualys (www.ssllabs.com). يسمح على أساس العديد من المعلمات بإنشاء تصنيف عام من A إلى F ، حيث "A +" هي أفضل نتيجة يمكن تحقيقها من حيث الأمان. عدد قليل جدا من الشركات ، حتى أكبر شركات الإنترنت ، لديها. وفقا لذلك ، "F" هو أسوأ نتيجة. يمكن الحصول عليها إذا تعرض الخادم لأي ثغرة أمنية حرجة ، ويدعم البروتوكولات القديمة ولديه مشاكل أخرى. مثل التصنيف "A +" ، فإن أسوأ نتيجة نادرة ، وترتبط بشكل رئيسي بالموظفين غير المحترفين.
يتم عرض النسبة المئوية للتصنيفات الموجودة أسفل "A" على البطاقة. كلما ارتفعت هذه النسبة ، زاد الوضع سوءًا مع أمان الويب في البلد.
رؤوس HTTP
تتيح لك الرؤوس في استجابة خادم الويب تحديد سلوك المستعرض في مواقف معينة. يساعد وجودهم على تجنب بعض الهجمات أو تعقيد سلوكهم ، بينما لا يتطلب إضافة رأس أي إجراءات أو إعدادات معقدة. ومع ذلك ، تتميز بعض الإعدادات ، على سبيل المثال ، CSP ، بالعديد من الخيارات ، التي يمكن أن يؤدي الاستخدام غير الصحيح لها إلى إنشاء وهم للأمان أو حتى إتلاف بعض وظائف الموقع. استعرضنا العناوين التالية:
إذا كانت العناوين العشرة الأولى "إيجابية" بطبيعتها ، وكان من المستحسن (بشكل صحيح!) استخدامها ، فعندئذٍ "الثلاثة" تخبر المهاجم عن التقنيات المستخدمة. بطبيعة الحال ، ينبغي التخلص من هذه العناوين.
تصنيف
يتيح لك المزيج الصحيح من رؤوس HTTP ضمان أمان الموقع ، بينما لا يعد إعدادها أمرًا صعبًا على الإطلاق. لقد جمعنا بيانات حول استخدام رؤوس HTTP وقمنا بناءً عليها بتجميع تصنيف أمان لموارد الويب.
من أجل الامتثال للمعايير التالية ، قمنا بمنح أو تسجيل نقاط:
قم بالتقييم من "D" إلى "A +" ، حيث "A +" هي أفضل نتيجة يمكن تحقيقها من حيث الأمان. لكن النتيجة الأسوأ كانت نادرة للغاية ، مثل الأفضل.
توزيع التصنيف
يتم عرض النسبة المئوية للتصنيفات الموجودة أسفل "A" على البطاقة. كلما ارتفعت هذه النسبة ، زاد الوضع سوءًا مع أمان الويب في البلد.
سياسة أمان المحتوى
تعد "سياسة حماية المحتوى" أو CSP واحدة من الطرق الرئيسية لتقليل المخاطر المرتبطة باستغلال هجمات XSS. تتيح هذه الأداة لمسؤول الموقع تحديد موارد الويب المسموح باستخدامها على الصفحات - الخطوط والأنماط والصور والبرامج النصية JS و SWF وما إلى ذلك. تعرف على المتصفحات التي تدعم CSP هنا .
بفضل CSP ، يمكنك منع المتصفح تمامًا من التحميل ، على سبيل المثال ، كائنات فلاش ، أو ضبط القائمة البيضاء للنطاقات - في هذه الحالة ، سيعرض المستعرض فقط صناديق الثروة السيادية الموجودة على المجال المسموح به. الميزة الأخرى التي توفرها سياسة CSP هي القدرة على التعرف بسرعة على مظهر XSS الجديد في اتساع مورد متحكم فيه. باستخدام خيار "report-uri" ، يرسل متصفح المهاجم أو المستخدم الضار تقريرًا إلى عنوان URL المحدد بمجرد تشغيل CSP.
من بين الأخطاء الرئيسية المتعلقة بسياسة CSP ، يمكن التمييز بين الفئات التالية:
- التكوين غير صحيح
- التوجيهات المفقودة (script-src | object-src | default-src | base-uri)
- خيارات زائدة عن الحاجة (غير آمنة في السطر | غير آمنة في eval | https: | data: | *)
- نقاط ضعف المضيفين والقائمة البيضاء
- القدرة على تحميل ملفات JS التعسفية
- وظائف الاستدعاء ( "رد")
- الأدوات النصية في محركات القالب الزاوي وما شابه ذلك
- هجمات خالية من JS ("بدون سيناريو")
- التسرب من خلال العلامات غير المغلقة
- تطبيق أشكال التصيد
يمكن العثور على معلومات أكثر تفصيلاً ، وأمثلة محددة من الأخطاء وطرق تجنبها في النص الكامل للدراسة .
الهدف الرئيسي لـ CSP هو تقليل احتمالية استغلال هجمات XSS ، ولكن ، كما أظهرت الأبحاث ، قليلون هم الذين تمكنوا من تكوين هذه السياسة بشكل صحيح: 3٪ فقط يستخدمون CSP.
يوضح الرسم البياني الأخطاء الأكثر شيوعًا في مواقع CSP التي تمت مراجعتها.
صارم النقل و الأمن
تسمح لك سياسة أمان HSTS (أمان النقل الصارم HTTP) بتأسيس اتصال آمن بدلاً من استخدام بروتوكول HTTP. للقيام بذلك ، استخدم رأس Strict-Transport-Security ، والذي يفرض على المستعرض فرض استخدام HTTPS. هذا يمنع بعض هجمات MITM ، على وجه الخصوص ، الهجمات بدرجة أقل من الحماية وسرقة ملفات تعريف الارتباط. مبدأ الآلية كما يلي: في المرة الأولى التي تزور فيها موقعًا ما باستخدام بروتوكول HTTP (S) ، يتلقى المستعرض رأس Strict-Transport-Security ويتذكر أنه عند محاولة الاتصال بهذا الموقع مرة أخرى ، فإنك تحتاج فقط إلى استخدام HTTPS.
سيمنع هذا سيناريو يقوم فيه المهاجم ، الذي يعترض طلبات HTTP ، بإعادة توجيه المستخدم إلى صفحة النسخ للحصول على بياناته.
نسبة البنوك التي تستخدم رأس HTTP Strict-Transport-Security
تعيين ملف تعريف الارتباط
بعد تلقي طلب HTTP ، يمكن أن يرسل الخادم رأس Set-Cookie مع الاستجابة.
يتم إرسال ملفات تعريف الارتباط ذات العلامة الآمنة إلى الخادم فقط إذا تم تنفيذ الطلب عبر SSL و HTTPS. ومع ذلك ، لا ينبغي أبدًا نقل البيانات الهامة أو تخزينها في ملف تعريف ارتباط ، نظرًا لأن آليتها ضعيفة للغاية ، ولا توفر علامة الحماية إجراءات تشفير أو أمان إضافية. لا يمكن الوصول إلى ملفات تعريف الارتباط التي تحمل علامة HTTPonly من JavaScript من خلال خصائص Document.cookie API ، مما يساعد على تجنب سرقة ملف تعريف الارتباط من العميل في حالة حدوث هجوم XSS. يجب تعيين هذه العلامة لملفات تعريف الارتباط التي لا تحتاج إلى الوصول إليها عبر JavaScript. على وجه الخصوص ، إذا تم استخدام ملفات تعريف الارتباط فقط لدعم الجلسة ، فعندئذٍ في JavaScript لا تكون هناك حاجة إليها ويمكنك استخدام علامة HTTPOnly. بدون علامتي HTTPOnly و Secure في رأس استجابة HTTP ، يمكنك سرقة أو معالجة جلسة تطبيق ويب وملفات تعريف الارتباط.
لا يتم العثور على أعلام آمنة و HTTPonly في هذا العنوان أكثر من أي موقع ويب رسمي للبنك في البوسنة والهرسك واليابان والصين والبرازيل وبلغاريا ولوكسمبورغ وفنلندا وإسرائيل وفرنسا وبريطانيا العظمى وإسبانيا.
بين DBO المادية. الأشخاص - الصين وإيرلندا وإسرائيل واليابان.
بين RBS ل jur. الأشخاص - البوسنة والهرسك والبرازيل والصين.
بين البنوك الروسية ، والإحصاءات هي كما يلي:
الموقع الرسمي للبنك - 42 ٪.
RBS المادية. الأشخاص - 37 ٪ ؛
RBS القانونية الأشخاص - 67 ٪.
يخبرك هذا الرأس بالبرنامج الذي يعمل عليه خادم الويب ، وقد يكون له المعنى التالي ، على سبيل المثال:
Server:Apache/2.4.12 (Unix) mod_wsgi/3.5 Python/2.7.5 OpenSSL/1.0.1l
الكشف عن هذه المعلومات لا يشكل تهديدا مباشرا ، ولكن يمكن أن تقلل من وقت الهجوم. بدلاً من التحقق من وجود ثغرة أمنية معينة ، يمكنك على الفور البدء في البحث عن بيانات على إصدار محدد من البرنامج. على سبيل المثال ، خلال الدراسة ، تم العثور على البيانات التالية:
أظهرت الدراسة أن 64 ٪ من مواقع البنوك تبلغ عن إصدار خادم ، في حين أن 24 ٪ من هذه الخوادم معرضة للخطر.
استنتاج
بعد أن تلقينا فكرة عامة عن أمان موارد البنك على الإنترنت ، توصلنا إلى الاستنتاج الرئيسي: العديد من البنوك تهمل حتى النصائح الأكثر شيوعًا وسهولة التنفيذ لتحسين أمان مواردها على الويب.
تسمح الثغرات والأخطاء التي اكتشفناها للمهاجمين بتنفيذ الهجمات على الموارد دون إنفاق الكثير من الجهد. لكن عواقب هذه الهجمات خطيرة للغاية: الخسائر النقدية للعملاء ، والخسائر المالية والسمعة للبنك ، بما في ذلك على المدى الطويل. قليلون يثقون في أموالهم إلى بنك تشوهت سمعته بسبب الحوادث الأمنية.
بالطبع ، باتباع الممارسة المعتادة المتمثلة في زيادة مستوى الأمان - البحث وإغلاق الثغرات الأمنية - يؤتي ثماره ويقلل المخاطر. ومع ذلك ، ينسى معظم مطوري تطبيقات الويب المصرفية أبسط التوصيات والأساليب التي يمكن أن تقلل إلى حد كبير من خطر أو تعقيد استغلال الثغرات الأمنية (مثل ، على سبيل المثال ، الاختباء من رؤوس الخوادم بمعلومات حول البرنامج المستخدم أو تثبيت CSP). إن فوائد استخدام هذه التقنيات غير مرئية على الفور ، ولكنها قد لا تكون واضحة على الإطلاق: بعد مواجهتها ، لن يتمكن المهاجم من تنفيذ هجوم ، وستظل أفعاله بعيدة عن نظر المسؤولين عن الأمن.
بعد فحص موارد الويب للبنوك الروسية من زوايا مختلفة ، اكتشفنا أن الثغرات الأمنية المعروفة والمشاكل الأمنية ما زالت موجودة فيها. هذا يسمح للمهاجمين بالاعتماد على التنفيذ الناجح للهجمات على هذه المؤسسات المالية. وكلما زادت المشكلات ، زادت مخاطر البنوك المالية ومخاطر السمعة.
الوضع في العالم ككل لا يختلف بشكل خاص. من بين التخلف الواضح فيما يتعلق بالأمن ، يمكن تحديد الموارد المصرفية عبر الإنترنت في البلدان التالية: الصين ، اليابان ، البرازيل ، إسرائيل ، إسبانيا. ومن المفارقات ، في معظم الحالات ، تولي البنوك الأجنبية اهتمامًا أكبر بأمان صفحاتها الرئيسية أكثر من اهتمامها بالنظام المصرفي. تجدر الإشارة إلى أن حصة تحليل البنوك الأجنبية في الدراسة ليست واسعة النطاق ، بل هي تعريف.