منذ حوالي عام، أطلقنا في DataLine للبحث وتحليل نقاط الضعف في تطبيقات تكنولوجيا المعلومات. تعتمد الخدمة على حل Qualys السحابي الذي يتم تشغيله . على مدار عام من العمل مع الحل، أجرينا 291 عملية فحص لمواقع مختلفة وقمنا بتجميع الإحصائيات حول نقاط الضعف الشائعة في تطبيقات الويب.
سأوضح لك في المقالة أدناه بالضبط ما هي الثغرات الموجودة في أمان موقع الويب المخفية وراء مستويات مختلفة من الأهمية. دعونا نرى ما هي نقاط الضعف التي وجدها الماسح الضوئي في كثير من الأحيان، ولماذا قد تحدث، وكيف تحمي نفسك.
تقوم Qualys بتقسيم جميع نقاط الضعف في تطبيقات الويب إلى ثلاثة مستويات من الأهمية: منخفضة ومتوسطة وعالية. إذا نظرت إلى التوزيع حسب "الشدة"، فيبدو أن كل شيء ليس سيئًا للغاية. هناك عدد قليل من الثغرات الأمنية ذات المستوى العالي من الأهمية، ومعظمها جميعها غير حرجة:
لكن غير حرج لا يعني أنه غير ضار. يمكن أن تسبب أيضًا أضرارًا جسيمة.
أهم نقاط الضعف "غير الحرجة".
- نقاط ضعف المحتوى المختلط.
معيار أمان موقع الويب هو نقل البيانات بين العميل والخادم عبر بروتوكول HTTPS، الذي يدعم التشفير ويحمي المعلومات من الاعتراض.
تستخدم بعض المواقع محتوى مختلط: يتم نقل بعض البيانات عبر بروتوكول HTTP غير الآمن. هذه هي الطريقة التي يتم بها نقلها في أغلب الأحيان المحتوى السلبي – المعلومات التي تؤثر فقط على عرض الموقع: الصور، أنماط CSS. لكن في بعض الأحيان هذه هي الطريقة التي ينتقل بها المحتوى النشط: البرامج النصية التي تتحكم في سلوك الموقع. في هذه الحالة، باستخدام برنامج خاص، يمكنك تحليل المعلومات ذات المحتوى النشط القادم من الخادم، وتعديل استجاباتك بسرعة وجعل الآلة تعمل بطريقة لم تكن مقصودة من قبل منشئيها.
تحذر الإصدارات الأحدث من المتصفحات المستخدمين من أن المواقع ذات المحتوى المختلط غير آمنة وتحظر المحتوى. يتلقى مطورو مواقع الويب أيضًا تحذيرات المتصفح في وحدة التحكم. على سبيل المثال، هكذا يبدو الأمر :
ما هو خطير: يستخدم المهاجمون بروتوكولًا غير آمن لاعتراض معلومات المستخدم واستبدال البرامج النصية وإرسال الطلبات إلى الموقع نيابة عنه. وحتى لو لم يقوم زائر الموقع بإدخال البيانات فهذا لا يحميه منها التصيد – الحصول على معلومات سرية باستخدام طرق احتيالية. على سبيل المثال، باستخدام برنامج نصي، يمكنك إعادة توجيه المستخدم إلى موقع غير آمن يتنكر على أنه موقع مألوف للمستخدم. وفي بعض الحالات، يبدو الموقع الخبيث أفضل من الموقع الأصلي، ويمكن للمستخدم ملء النموذج بنفسه وتقديم بيانات سرية.ما يجب أن يتذكره مطور الويب: حتى لو قام مسؤول الموقع بتثبيت وتكوين شهادة SSL/TLS، فقد تنشأ ثغرة أمنية بسبب خطأ بشري. على سبيل المثال، إذا لم تضع رابطًا نسبيًا في إحدى الصفحات، بل رابطًا مطلقًا من http، بالإضافة إلى ذلك، لم تقم بإعداد عمليات إعادة التوجيه من http إلى https.
يمكنك اكتشاف المحتوى المختلط على موقع ما باستخدام متصفح: ابحث في الكود المصدري للصفحة، واقرأ الإشعارات في وحدة تحكم المطور. ومع ذلك، سيتعين على المطور العبث بالكود لفترة طويلة ومضجر. يمكنك تسريع العملية باستخدام أدوات التحليل الآلي، على سبيل المثال: ، برنامج Lighthouse مجاني أو برنامج مدفوع Screaming Frog SEO Spider.
أيضًا، قد تنشأ الثغرة الأمنية بسبب مشاكل في الكود القديم - وهو الكود الذي تم توريثه. على سبيل المثال، إذا تم إنشاء بعض الصفحات باستخدام قالب قديم، والذي لا يأخذ في الاعتبار انتقال المواقع إلى https.
- ملفات تعريف الارتباط التي لا تحتوي على علامتي "HTTPOnly" و"آمن".
تحمي السمة "HTTPOnly" ملفات تعريف الارتباط من المعالجة بواسطة البرامج النصية التي يستخدمها المهاجمون لسرقة بيانات المستخدم. لا تسمح العلامة "الآمنة" بإرسال ملفات تعريف الارتباط بنص واضح. لن يُسمح بالاتصال إلا إذا تم استخدام بروتوكول HTTPS الآمن لإرسال ملفات تعريف الارتباط.
تم تحديد كلتا السمتين في خصائص ملف تعريف الارتباط:
Set-Cookie: Secure; HttpOnlyما هو خطير: إذا لم يحدد مطور الموقع هذه السمات، فيمكن للمهاجم اعتراض معلومات المستخدم من ملف تعريف الارتباط واستغلالها. إذا تم استخدام ملفات تعريف الارتباط للمصادقة والترخيص، فسيكون قادرًا على اختطاف جلسة المستخدم وتنفيذ الإجراءات على الموقع نيابة عنه.
ما يجب أن يتذكره مطور الويب: كقاعدة عامة، في الأطر الشائعة، يتم تعيين هذه السمات تلقائيًا. ولكن لا يزال عليك التحقق من تكوين خادم الويب وتعيين العلامة: Set-Cookie HttpOnly; يؤمن.
في هذه الحالة، ستجعل السمة "HTTPOnly" ملفات تعريف الارتباط غير مرئية لجافا سكريبت الخاص بك.
- نقاط الضعف القائمة على المسار.
يقوم الماسح الضوئي بالإبلاغ عن مثل هذه الثغرة الأمنية إذا عثر على ملف يمكن الوصول إليه بشكل عام أو دليل موقع ويب يحتوي على معلومات قد تكون سرية. على سبيل المثال، يكتشف ملفات تكوين النظام الفردية أو الوصول إلى نظام الملفات بأكمله. هذا الموقف ممكن إذا تم تعيين حقوق الوصول بشكل غير صحيح على الموقع.
ما هو خطير: إذا "توقف" نظام الملفات، فيمكن للمهاجم الدخول إلى واجهة نظام التشغيل ومحاولة العثور على مجلدات تحتوي على كلمات مرور إذا كانت مخزنة بنص واضح (لا تفعل ذلك!). أو يمكنك سرقة تجزئات كلمة المرور وفرض كلمة المرور بشكل غاشم، ومحاولة أيضًا رفع الامتيازات في النظام والتعمق في البنية التحتية.
ما يجب أن يتذكره مطور الويب: لا تنس حقوق الوصول وقم بتكوين النظام الأساسي وخادم الويب وتطبيق الويب بحيث يكون من المستحيل "الهروب" من دليل الويب.
- نماذج لإدخال البيانات الحساسة مع تمكين الملء التلقائي.
إذا كان المستخدم يملأ النماذج على مواقع الويب بشكل متكرر، فسيقوم متصفحه بتخزين هذه المعلومات باستخدام ميزة الملء التلقائي.
قد تشتمل النماذج الموجودة على مواقع الويب على حقول تحتوي على معلومات حساسة، مثل كلمات المرور أو أرقام بطاقات الائتمان. بالنسبة لهذه الحقول، فإن الأمر يستحق تعطيل وظيفة الملء التلقائي للنموذج على الموقع نفسه.
ما هو خطير: إذا قام متصفح المستخدم بتخزين معلومات حساسة، فيمكن للمهاجم اعتراضها لاحقًا، على سبيل المثال من خلال التصيد الاحتيالي. في جوهر الأمر، يقوم مطور الويب الذي نسي هذا الفارق الدقيق بإعداد مستخدميه.
ما يجب أن يتذكره مطور الويب: في هذه الحالة، لدينا صراع كلاسيكي: الراحة مقابل الأمان. إذا كان مطور الويب يفكر في تجربة المستخدم، فيمكنه اختيار الإكمال التلقائي بوعي. على سبيل المثال، إذا كان من المهم اتباعه – توصيات بشأن إمكانية الوصول إلى المحتوى للمستخدمين ذوي الإعاقة.
بالنسبة لمعظم المتصفحات، يمكنك تعطيل الإكمال التلقائي باستخدام سمة autocompete="off"، على سبيل المثال:
<body> <form action="/ar/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>لكنها لن تعمل مع Chrome. يتم التحايل على ذلك باستخدام جافا سكريبت، ويمكن العثور على نسخة مختلفة من الوصفة .
- لم يتم تعيين رأس X-Frame-Options في رمز الموقع.
يؤثر هذا الرأس على علامات الإطار أو iframe أو التضمين أو الكائن. بمساعدتها، يمكنك حظر تضمين موقعك داخل الإطار تمامًا. للقيام بذلك، تحتاج إلى تحديد قيمة خيارات الإطار X: رفض. أو يمكنك تحديد X-Frame-Options: Sameorigin، ثم سيكون التضمين في iframe متاحًا فقط في المجال الخاص بك.
ما هو خطير: يمكن استخدام عدم وجود مثل هذا الرأس على المواقع الضارة ل Clickjacking. في هذا الهجوم، يقوم المهاجم بإنشاء إطار شفاف أعلى الأزرار ويخدع المستخدم. على سبيل المثال: يقوم المحتالون بتأطير صفحات الشبكات الاجتماعية على موقع ويب. يعتقد المستخدم أنه ينقر على زر في هذا الموقع. وبدلاً من ذلك، يتم اعتراض النقرة وإرسال طلب المستخدم إلى الشبكة الاجتماعية حيث توجد جلسة نشطة. هذه هي الطريقة التي يرسل بها المهاجمون رسائل غير مرغوب فيها نيابة عن المستخدم أو يكسبون المشتركين والإعجابات.
إذا لم تقم بتعطيل هذه الميزة، فيمكن للمهاجم وضع زر التطبيق الخاص بك على موقع ضار. قد يكون مهتمًا ببرنامج الإحالة الخاص بك أو بالمستخدمين لديك.
ما يجب أن يتذكره مطور الويب: قد تحدث الثغرة الأمنية في حالة تعيين X-Frame-Options بقيمة متعارضة على خادم الويب أو موازن التحميل. في هذه الحالة، سيقوم الخادم والموازن ببساطة بإعادة كتابة الرأس، نظرًا لأن لهما أولوية أعلى مقارنة بكود الواجهة الخلفية.
سوف تتداخل قيمتي الرفض ونفس الأصل لرأس X-Frame-Options مع تشغيل عارض الويب Yandex. للسماح باستخدام إطارات iframe لعارض الويب، يلزمك كتابة قاعدة منفصلة في الإعدادات. على سبيل المثال، بالنسبة لـ nginx، يمكنك تكوينه على النحو التالي:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - ثغرات PRSSI (استيراد ورقة الأنماط النسبية للمسار).
هذه ثغرة أمنية في تصميم الموقع. يحدث ذلك إذا تم استخدام الروابط النسبية مثل href="/ar/somefolder/styles.css/" للوصول إلى ملفات الأنماط. سيستفيد المهاجم من هذا إذا وجد طريقة لإعادة توجيه المستخدم إلى صفحة ضارة. ستقوم الصفحة بإدراج رابط نسبي في عنوان url الخاص بها ومحاكاة استدعاء الأنماط. سوف تحصل على طلب مثل badsite.ru/…/somefolder/styles.css/، والذي يمكنه تنفيذ إجراءات ضارة تحت ستار أحد الأنماط.
ما هو خطير: يمكن للمحتال استغلال هذه الثغرة الأمنية إذا وجد ثغرة أمنية أخرى. ونتيجة لذلك، من الممكن سرقة بيانات المستخدم من ملفات تعريف الارتباط أو الرموز المميزة.
ما يجب أن يتذكره مطور الويب: اضبط رأس X-Content-Type-Options على: nosniff. في هذه الحالة، سيتحقق المتصفح من نوع محتوى الأنماط. إذا كان النوع غير text/css، فسيقوم المتصفح بحظر الطلب.
نقاط الضعف الحرجة
- يتم إرسال صفحة بها حقل كلمة مرور من الخادم عبر قناة غير آمنة (يتم تقديم نموذج HTML الذي يحتوي على حقل (حقول) كلمة المرور عبر HTTP).
تكون الاستجابة من الخادم عبر قناة غير مشفرة عرضة لهجمات "الرجل في المنتصف". يمكن للمهاجم اعتراض حركة المرور وربط نفسه بين العميل والخادم أثناء انتقال الصفحة من الخادم إلى العميل.
ما هو خطير: سيتمكن المحتال من استبدال الصفحة وإرسال نموذج للمستخدم للحصول على بيانات سرية، والتي ستذهب إلى خادم المهاجم.
ما يجب أن يتذكره مطور الويب: ترسل بعض المواقع للمستخدمين رمزًا لمرة واحدة عبر البريد الإلكتروني/الهاتف بدلاً من كلمة المرور. في هذه الحالة، الثغرة الأمنية ليست حرجة للغاية، لكن الآلية ستعقد حياة المستخدمين.
- إرسال نموذج يتضمن تسجيل الدخول وكلمة المرور عبر قناة غير آمنة (لم يتم إرسال نموذج تسجيل الدخول عبر HTTPS).
في هذه الحالة، يتم إرسال نموذج يتضمن تسجيل الدخول وكلمة المرور من المستخدم إلى الخادم عبر قناة غير مشفرة.
ما هو خطير: على عكس الحالة السابقة، فهذه ثغرة أمنية حرجة بالفعل. من الأسهل اعتراض البيانات الحساسة لأنك لا تحتاج حتى إلى كتابة تعليمات برمجية للقيام بذلك.
- استخدام مكتبات JavaScript ذات نقاط الضعف المعروفة.
أثناء الفحص، كانت المكتبة الأكثر استخدامًا هي jQuery مع عدد كبير من الإصدارات. يحتوي كل إصدار على ثغرة أمنية معروفة واحدة على الأقل أو أكثر. يمكن أن يكون التأثير مختلفًا جدًا اعتمادًا على طبيعة الثغرة الأمنية.
ما هو خطير: هناك عمليات استغلال لنقاط الضعف المعروفة، على سبيل المثال:
ما يجب أن يتذكره مطور الويب: العودة بانتظام إلى الدورة: البحث عن الثغرات الأمنية المعروفة - الإصلاح - التحقق. إذا كنت تستخدم المكتبات القديمة عمدًا، على سبيل المثال لدعم المتصفحات القديمة أو لتوفير المال، فابحث عن فرصة لإصلاح ثغرة أمنية معروفة. - البرمجة النصية عبر المواقع (XSS).
البرمجة النصية عبر المواقع (XSS)، أو البرمجة النصية عبر المواقع، هي هجوم على تطبيق ويب يؤدي إلى إدخال برامج ضارة إلى قاعدة البيانات. إذا وجدت Qualys مثل هذه الثغرة الأمنية، فهذا يعني أن المهاجم المحتمل يمكنه أو قام بالفعل بإدخال نص js الخاص به في رمز الموقع لتنفيذ إجراءات ضارة.XSS المخزنة والأكثر خطورة، حيث يتم تضمين البرنامج النصي على الخادم ويتم تنفيذه في كل مرة يتم فيها فتح الصفحة التي تمت مهاجمتها في المتصفح.
XSS المنعكس أسهل في التنفيذ نظرًا لأنه يمكن إدخال برنامج نصي ضار في طلب HTTP. سيتلقى التطبيق طلب HTTP، ولن يتحقق من صحة البيانات، وسيحزمها ويرسلها على الفور. إذا اعترض أحد المهاجمين حركة المرور وأدخل برنامجًا نصيًا مثل
<script>/*+что+то+плохое+*/</script>ثم سيتم إرسال طلب ضار نيابة عن العميل.
من الأمثلة الصارخة على XSS: أدوات js sniffers التي تحاكي صفحات إدخال رمز التحقق من البطاقة (CVC) وتاريخ انتهاء صلاحية البطاقة وما إلى ذلك.
ما يجب أن يتذكره مطور الويب: في رأس Content-Security-Policy، استخدم سمة script-src لإجبار متصفح العميل على تنزيل التعليمات البرمجية وتنفيذها من مصدر موثوق به فقط. على سبيل المثال، يقوم script-src 'self' بإدراج كافة البرامج النصية من موقعنا فقط في القائمة البيضاء.
أفضل ممارسة هي التعليمات البرمجية المضمنة: السماح فقط لجافا سكريبت المضمن باستخدام القيمة المضمنة غير الآمنة. تسمح هذه القيمة باستخدام js/css المضمّن، ولكنها لا تمنع تضمين ملفات js. بالاشتراك مع script-src 'self'، نقوم بتعطيل تنفيذ البرامج النصية الخارجية.تأكد من تسجيل كل شيء باستخدام report-uri وإلقاء نظرة على محاولات تنفيذه في الموقع.
- حقن SQL.
وتشير الثغرة الأمنية إلى إمكانية إدخال تعليمات برمجية SQL في موقع ويب يمكنه الوصول إلى قاعدة بيانات الموقع مباشرة. يكون إدخال SQL ممكنًا إذا لم يتم فحص البيانات الواردة من المستخدم: لم يتم التحقق من صحتها ويتم استخدامها على الفور في الاستعلام. على سبيل المثال، يحدث هذا إذا لم يتحقق النموذج الموجود على موقع الويب مما إذا كان الإدخال يتطابق مع نوع البيانات.ما هو خطير: إذا قام أحد المهاجمين بإدخال استعلام SQL في هذا النموذج، فيمكنه تعطيل قاعدة البيانات أو الكشف عن معلومات سرية.
ما يجب أن يتذكره مطور الويب: لا تثق بما يأتي من المتصفح. أنت بحاجة إلى حماية نفسك من جانب العميل والخادم.
من جانب العميل، اكتب التحقق من صحة الحقل باستخدام JavaScript.
تساعد الوظائف المضمنة في الأطر الشائعة أيضًا على الهروب من الشخصيات المشبوهة على الخادم. يوصى أيضًا باستخدام استعلامات قاعدة البيانات ذات المعلمات على الخادم.
تحديد المكان الدقيق الذي يحدث فيه التفاعل مع قاعدة البيانات على تطبيق الويب.
يحدث التفاعل عندما نتلقى أي معلومات: طلب بمعرف (تغيير المعرف)، أو إنشاء مستخدم جديد، أو تعليق جديد، أو إدخالات جديدة في قاعدة البيانات. هذا هو المكان الذي يمكن أن يحدث فيه حقن SQL. حتى لو قمنا بحذف سجل من قاعدة البيانات، فمن الممكن حقن SQL.
توصيات عامة
لا تعيد اختراع العجلة - استخدم أطر العمل التي أثبتت جدواها. وكقاعدة عامة، تكون الأطر الشائعة أكثر أمانًا. لـ .NET - ASP.NET MVC وASP.NET Core، لـ Python - Django أو Flask، لـ Ruby - Ruby on Rails، لـ PHP - Symfony، Laravel، Yii، لـ JavaScript - Node.JS-Express.js، لـ Java - الربيع MVC.
اتبع تحديثات البائع وقم بالتحديث بانتظام. سوف يعثرون على ثغرة أمنية، ثم يكتبون برنامج إكسبلويت، ويجعلونه متاحًا للعامة، وسيحدث كل شيء مرة أخرى. اشترك في التحديثات للإصدارات الثابتة من بائع البرنامج.
تحقق من الأذونات. من ناحية الخادم، تعامل دائمًا مع التعليمات البرمجية الخاصة بك كما لو أنها، من الحرف الأول إلى الحرف الأخير، كتبها عدوك الأكثر كراهية، والذي يريد اختراق موقعك، وانتهاك سلامة بياناتك. علاوة على ذلك، هذا صحيح في بعض الأحيان.
استخدم النسخ ومواقع الاختبار ثم استخدمها للإنتاج. سيساعد ذلك، أولا، على تجنب الأخطاء والأخطاء في بيئة إنتاجية: البيئة الإنتاجية تجلب المال، والبيئة الإنتاجية البسيطة أمر بالغ الأهمية. عند إضافة أي مشكلة أو إصلاحها أو إغلاقها، فإن الأمر يستحق العمل في بيئة اختبار، ثم التحقق من الوظائف ونقاط الضعف الموجودة، ثم التخطيط للعمل مع بيئة الإنتاج.
قم بحماية تطبيق الويب الخاص بك باستخدام ودمج التقارير من أداة فحص الثغرات الأمنية معها. على سبيل المثال، يستخدم DataLine Qualys وFortiWeb كمجموعة من الخدمات.
المصدر: www.habr.com