9 نصائح أمنية لحماية موقعك الخاص من الإختراق

نصيحة للمحترفين لتحسين أمان موقعك الخاص بك وتجنب اختراقه وقرصنته.

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

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

1- حافظ على تحديث نظام الموقع

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

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

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

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

2- احترس من حقن SQL

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

أنظر لهذا الاستعلام:

"SELECT * FROM table WHERE column = '" + parameter + "';"

إذا غير المهاجم معامل عنوان URL لتمرير “أو” 1 “=” 1 ، فسيؤدي ذلك إلى ظهور الاستعلام على النحو التالي:

"SELECT * FROM table WHERE column = '' OR '1'='1';"

نظرًا لأن “1” تساوي “1” ، فسيسمح للمهاجم بإضافة استعلام إضافي إلى نهاية عبارة SQL التي سيتم تنفيذها أيضًا.

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

$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value');
$stmt->execute(array('value' => $parameter));

3- الحماية ضد هجمات XSS

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

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

المفتاح هنا هو التركيز على كيف يمكن لمحتواك الذي أنشأه المستخدم أن يفلت من الحدود التي تتوقعها وأن يفسرها المتصفح على أنه شيء آخر غير ما قصدته. هذا مشابه للدفاع ضد حقن SQL. عند إنشاء HTML ديناميكيًا ، استخدم الوظائف التي تُجري التغييرات التي تبحث عنها بشكل صريح (على سبيل المثال استخدام element.setAttribute و element.textContent ، والتي سيتم تخطيها تلقائيًا بواسطة المتصفح ، بدلاً من ضبط element.innerHTML باليد) ، أو استخدام الوظائف في أداة templating الخاصة بك والتي تقوم تلقائيًا بالهروب المناسب ، بدلاً من تسلسل السلاسل أو تعيين محتوى HTML خام.

هناك أداة قوية أخرى في صندوق أدوات XSS defender وهي سياسة أمان المحتوى (CSP). CSP عبارة عن رأس يمكن أن يعرضه الخادم والذي يخبر المستعرض بتحديد كيفية تنفيذ جافا سكريبت في الصفحة وما هو تنفيذها ، على سبيل المثال عدم السماح بتشغيل أي نصوص برمجية غير مستضافة على نطاقك ، أو عدم السماح بـ JavaScript أو تعطيل eval (). موزيلا لديها دليل ممتاز مع بعض الأمثلة التكوينات. يؤدي ذلك إلى صعوبة عمل البرامج النصية للمهاجمين ، حتى لو استطاعوا إدخالها في صفحتك.

4- احذر من رسائل الخطأ

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

5- التحقق من صحة على كلا الجانبين

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

6- التحقق من كلمات السر الخاصة بك

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

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

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

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

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

7- تجنب تحميل الملفات

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

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

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

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

deny from all
    <Files ~ "^\w+\.(gif|jpe?g|png)$">
    order deny,allow
    allow from all
    </Files>

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

<img src="/imageDelivery.php?id=1234" />
     
<?php
      // imageDelivery.php
     
      // Fetch image filename from database based on $_GET["id"]
      ...
     
      // Deliver image to browser
       Header('Content-Type: image/gif');
      readfile('images/'.$fileName);  
     
?>

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

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

إذا كنت تسمح بتحميل الملفات من الإنترنت ، فاستخدم طرق النقل الآمنة فقط إلى خادمك مثل SFTP أو SSH.

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

أخيرًا ، لا تنس تقييد الوصول الفعلي إلى الخادم الخاص بك.

8- استخدم HTTPS

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

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

هذا لم يعد صعبًا أو مكلفًا كما كان من قبل. يتيح Let’s Encrypt شهادات مجانية ومؤتمتة بالكامل ، وستحتاج إلى تمكين HTTPS ، وهناك أدوات مجتمع متاحة متاحة لمجموعة واسعة من المنصات والأطر المشتركة لإعداد هذا الأمر لك تلقائيًا.

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

هل تستخدم HTTPS بالفعل في كل مكان؟ انتقل أبعد من ذلك وانظر في إعداد HTTP Strict Transport Security (HSTS) ، وهو رأس سهل يمكنك إضافته إلى ردود خادمك لعدم السماح بـ HTTP غير الآمن للمجال بالكامل.

الحصول على أدوات أمن الموقع

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

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

9- بعض الأدوات المجانية التي تستحق النظر في

Netsparker (إصدار مجتمع مجاني وإصدار تجريبي متاح). جيد لاختبار حقن SQL و XSS
OpenVAS تدعي أنها أكثر ماسحات الأمان مفتوحة المصدر تقدمًا. جيد لاختبار الثغرات المعروفة ، حيث يقوم حاليًا بمسح أكثر من 25000. ولكن قد يكون من الصعب الإعداد ويتطلب تثبيت خادم OpenVAS والذي يعمل فقط على * nix. OpenVAS هي شوكة لشركة Nessus قبل أن تصبح منتجًا تجاريًا مغلق المصدر.

SecurityHeaders.io (فحص مجاني على الإنترنت). أداة للإبلاغ بسرعة عن رؤوس الأمان المذكورة أعلاه (مثل CSP و HSTS) التي قام المجال بتمكينها وتهيئتها بشكل صحيح.

Xenotix XSS Exploit Framework هي أداة من OWASP (مشروع أمان تطبيق الويب المفتوح) تتضمن مجموعة كبيرة من أمثلة هجمات XSS ، والتي يمكنك تشغيلها لتأكيد بسرعة ما إذا كانت مدخلات موقعك عرضة للتأثر في Chrome و Firefox و IE.

نتائج الاختبارات الآلية يمكن أن تكون شاقة ، لأنها تقدم مجموعة كبيرة من المشكلات المحتملة. الشيء المهم هو التركيز على القضايا الحرجة أولاً.

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

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

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

Leave a Reply

error: Content is protected !!