البحث في الموقع

تستغل هجمات حقن SQL البرمجة السيئة للشفرة الخاصّة بالبرمجيات. إنّها هجمات حيث يقوم المهاجمون بإرسال شفرة عبر واحدٍ من مربّعات الإدخال الموجودة على موقعك (أيّ مربّع)، عوضًا عن أن يرسل بياناتٍ عادية كنتَ تنوي استقبالها عبر مربّعات الإدخال تلك. تقوم تلك الشفرة المُدخلة بتنفيذ عمليات الاستعلام على قاعدة البيانات الخاصّة بموقعك بطريقةٍ لم تكن تتوقعها، أو تقوم بتحطيم تطبيق الويب الخاصّ بك وتقوم بتخريب خادومك السحابي. م السهل جدًا عمل هجمات حقن SQL ضدّ المواقع الغير مؤمّنة. وحراسة موقعك ضدّ هذه الهجمات قد يكون من أهمّ ما تقوم به منذ اليوم الأوّل. الخطوة الأولى: تعلم تمييز الشفرة المحتوية على ثغرات تأخذ هجمات SQL دومًا شكل سلسلة نصّية يتم إرسالها من طرف مستخدمٍ تتكون من قسمين. القسم الأول هو عبارة عن تخمين لكيفية تعطيل أمرٍ تحاول شفرتك المصدرية أن تقوم بتنفيذه بأمان; القسم الثاني هو الشفرة الخبيثة التي يريد المهاجم تنفيذها على خادومك. إليك مثالًا على سلسلة نصّية مصممة لاستغلال ثغرة ممكنة في الشفرة المصدرية لديك: x' AND user.email IS NULL; -- يبدو هذا كشيء قمتَ بكتابته بنفسك، وتلك هي النقطة. يأمل المستخدم المُخترِق أن تقوم بأخذ هذا السطر، وتقوم بتنفيذه بعملية استعلام SQL تبدو كالتالي: SELECT email, passwd FROM user WHERE email = 'x' AND user.email IS NULL; --'; لا يبدو أنّ هذا يقوم بالكثير حقًا، ولكن اعتمادًا على الطريقة التي سيستجيب بها تطبيقك إلى ما سبق، يمكن أن يوفّر هذا بعض المعلومات المهمّة للمُخترِق مثل اسم جدول قاعدة البيانات الذي تستعمله. بعد هذا، هناك المزيد من الهجمات التي يمكن للمهاجم أن يستخدمها لجلب المزيد من المعلومات، مثل أسماء المستخدمين وكلمات المرور. الفكرة الرئيسية التي يجب عليك فهمها هي أنّ الشفرة الخبيثة تحاول البحث عن ثغرة بعملية استعلام SQL التي يقوم بها تطبيقك لمحاولة استغلالها لجلب المعلومات أو إدراجها وتعديلها. لا تتطلب جميع هجمات حقن SQL إشارة الاقتباس المغلقة ('). إذا كانت شفرتك المصدرية تنفّذ عملية استعلامٍ متعلّقة برقم، فإنّك لن تقوم بالطبع بوضع تلك البيانات داخل إشارة اقتباس. وهذا يتركك عرضةً لهذا النوع من الهجمات: 2097 OR 1=1 يأمل المهاجم أن يقوم تطبيقك بعملية استعلام مشابهة للتالي: SELECT somedata FROM yourtable WHERE userid = 2097 OR 1=1; غالبًا ما تكون شفرتك البرمجية مصممة لتقوم بعملية الاستعلام السابقة لتعيد البيانات فقط في حال تطابق الـ userid مع المستخدم الصحيح. ولكنّ حقنة الـSQL تجعل عملية الاستعلام تقوم دومًا بإرجاع البيانات. النقطة ليست في سلوكٍ معيّن لأيّ حقنة SQL. الشيء الأكثر أهمّية من هذا كلّه هو القاعدة العامّة لجميع حقن SQL: محاولة لتخمين كيفية حذف جزء معيّن من عملية استعلام، وإضافة جزءٍ آخر إليها لم تكن تتوقعه. هذا هو توقيع جميع هجمات حقن SQL. وهذه هي طريقة محاربتها. الخطوة الثانية: اعثر على مدخلاتك أفضل طريقة لتعقّب جميع نقط إدخال حقن SQL الممكنة في شفرتك البرمجية ليس عبر النظر إلى حقول إدخال HTML. بالطبع يمكنك العثور على العديد من الثغرات الممكنة هناك، ولكن هناك طرقٌ أخرى يمكن من خلالها للمستخدم أن يقوم بإدخال البيانات، مثل عنوان الويب (URL)، أو عبر واحدةٍ من واجهات AJAX الخاصّة بك. أفضل مكان للبحث فيه عن الثغرات هو الشيء الذي يريد المخترقون اختراقه بنفسه; جملة استعلام SQL بنفسها. على الأغلب، فإنّك تقوم بتنفيذ جميع عمليات الاستعلام عن طريق الأمر الأساسي نفسه، وربّما أمران آخران أو أكثر قليلًا. فقط ابحث عن هذه الأوامر في شفرتك البرمجية وستجد جميع الثغرات الممكنة بشكلٍ سريع. كمثال، إذا كانت شفرتك البرمجية مكتوبة بـPerl، فإنّ جميع عمليات استعلام SQL الخاصّة بك ستبدو هكذا: $result = mysql_query($sql) في تلك الحالة، يمكنك العثور بسرعة على جميع الثغرات الممكنة بواسطة سطر الأوامر، عبر استخدام أمر شبيه بالتالي: $ grep -R mysql_query * الخطوة الثالثة: نظف مدخلاتك هناك العديد من التقنيات التي يستخدمها الناس لمنع هجمات حقن SQL، ولكن خطّ دفاعك الأمامي يجب أن يكون تنظيف جميع مُدخلات المستخدم من أيّ شفرة خبيثة مشبوهة. يجب ألّا تعتقد بتاتًا أنّ المستخدم سيقوم بإدخال البيانات بالطريقة التي تريدها. في الواقع، يجب عليك أن تفترض العكس - أنّهم سيقومون بإدخال الشفرات الخبيثة في كلّ مكانٍ ممكن في موقعك. تنظيف المُدخلات يعني أنّه يجب اختبار جميع مُدخلات المستخدم للتأكّد من أنّها تحتوي فقط مُدخلات آمنة، مُدخلات لا يمكن استخدامها بتاتًا في شنّ هجوم. المُدخلات التي سيتم إدخالها من طرف المستخدم إلى خادوم SQL الخاصّ بك ستكون على شكلَين: كرقم، مثل 2097. كسلسلة (string)، مثل اسم المستخدم، كلمة المرور أو البريد الإلكتروني. تتوقّع شفرتك البرمجية دومًا مُدخَلًا واحدًا من هذين الشكلين. في الأمثلة التي ذكرناها ببداية هذا المقال، كان المثال الأوّل عبارة عن سلسلة نصّية، وكان المثال الثاني عبارةً عن رقم. هناك أيضًا طريقتان لتنظيف البيانات: طريقة جيدة وطريقة سيئة. الطريقة السيئة هي التحقق من وجود حقن SQL الممكنة. السبب في كونها سيئة هو لأنّ عدد حقن SQL الممكن كبير جدًا، و"إبداع" المهاجمين واسع كذلك. الطريقة الجيّدة هي تنظيف البيانات للتعرّف على ما يبدو شكل الإدخال الصحيح عليه، وتجاهل كلّ شيء لا يتوافق مع شكل ذلك الإدخال الصحيح. البيانات الرقمية هي الأسهل للتنظيف، لذا سنقوم بتغطية هذا أوّلًا. يمكن للرقم أن يحتوي على إشارة سالبة على يساره، أو أن يكون متبوعا بأرقام أخرى، وربّما يحتوي على فاصلة عشرية. هذا كلّ ما يمكن للبيانات الرقمية أن تبدو عليه، في Perl، ستبدو الشفرة التي تتحقق من البيانات الرقمية كالتالي: if($numericaluserinput !~ /^-?[0-9.]+$/) { # البيانات المُدخلة ليست رقمًا } من الصعب تخيّل أيّ حقنة خبيثة يمكنها أن تتخطى ما سبق. تنظيف المُدخلات النصّية أكثر صعوبة، لأنّه هناك العديد من الطرق لمحاولة إدخالها. يمكن للمهاجم أن يستخدم إشارات الاقتباس وغيرها بطرق "إبداعية" للقيام بالهجمات. في الواقع، محاولة إنشاء قائمة سوداء للحروف المُدخلة هو أمرٌ سيّء، لأنّه من السهل نسيان شيء مهم مثلًا. هناك طريقة أفضل، كما قمنا مع البيانات الرقمية، وهي تقييد مُدخلات المستخدم إلى قائمة بيضاء من الحروف فقط. كمثال، عناوين البريد الإلكتروني لا يجب أن تحتوي على شيء سوى الأرقام والحروف العادية وبعض الإشارات مثل @ و _ وعدا ذلك، يجب منع كلّ الحروف الأخرى. في لغة Perl، ستبدو الشفرة كالتالي: if($useremail ~= /^[0-9a-zA-Z\-_+.\@]$/) { # the user's email address is unacceptable } يمكن العثور على قوائم بيضاء للأنواع الأخرى من المُدخلات كذلك مثل اسم المستخدم وكلمة المرور.. إلخ. قد تكون القوائم البيضاء مصدر إزعاج لبعض المستخدمين. فربّما يكون هناك رموز معيّنة في بعض مربّعات الإدخال تكون غير مقبولة من طرفها مثلًا، ولكنّك بالطبع حرّ لتقوم بتعديل القوائم البيضاء حسب حاجتك، ولكن لا تنسى أن تقوم ببحث عن الرموز والمحارف التي تريد تمكينها للتأكّد من أنّه لا يمكن استخدامها في حقن SQL، فعندما تختار بين حماية الموقع وراحة المستخدم، حماية الموقع تأتي أوّلًا. تنظيف المُدخلات بواسطة القوائم البيضاء جيّد لأنّه سهل. إذا كنتَ مُدركًا بشكل صحيح للرموز والمحارف التي تقوم بتمكينها، فحينها سيكون هذا الحلّ كافيًا للتخليص من هجمات حقن SQL. الخطوة الرابعة: قبول المدخلات الخطيرة لا تنخدع بالعنوان! سنتحدّث فقط عن أهمّية عدم قبول المُدخلات الخطيرة. صحيحٌ أنّ القوائم البيضاء شديدة التقييد جيّدة من أجل الحماية في حال ما إذا كان تطبيقك يستطيع أن يتوافق مع تلك التقييدات على المستخدمين. ولكن في بعض الحالات، قد يكون من المهمّ لنموذجك الربحي الخاصّ بالتطبيق ألّا تقوم بفرض أيّ تقييدات على مُدخلات المستخدمين. في هذه الحالة، غالبًا ما تكون لغة البرمجة التي تستعملها في تطبيقك تحوي على مكتباتٍ تساعدك في تنظيف مُدخلات المستخدمين من الشفرات الخبيثة. كمثال، مكتبة Perl DBI تحوي طُرقًا متعددة لمنع مُدخلات المستخدمين من التعامل مع استعلام SQL بخارج المنطقة المخصصة لها: my $sql = "INSERT INTO user (username, email) VALUES (?, ?)"; my $handle = $dbh->prepare( $sql ); $handle->execute( $untrustedusername, $untrustedemail); في المثال السابق، تمّ استخدام إشارة ؟ كعناصر نائبة (placeholders). تقوم مكتبة Perl DBI باستبدال هذه الإشارات بالمتغيّرات الغير موثوقة والتي تمّ إدخالها من طرف المستخدم. ولكن أثناء القيام بهذا، تقوم مكتبة DBI بتقييد هذه المتغيرات وتجعلها تتعامل فقط مع الحقول المخصصة لها بجدول قاعدة البيانات. هناك مكتبات مشابهة باللغات البرمجية الأخرى، إمّا لتقييد مُدخلات المستخدم، أو لتجاهل البيانات في حال حاولت التعامل مع خارج الحقل المخصص لها. ميّزة هذه التقنية هي أنّك قادرٌ على إعطاء ثقتك بالأشخاص المطورين لتلك المكتبات، حيث أنّهم سيقومون بتطويرها، والحفاظ عليها بعيدة عن الثغرات الأمنية والمشاكل الخطيرة. ولكن عيب هذه التقنية هي أنّها أقل قابلية للقراءة البشرية، وهكذا ربّما تنسى استخدام المكتبة الصحيحة لحماية بعض من عمليات استعلام SQL الخاصّة بك. الخطوة الخامسة: خفف ضرر الهجمات الناجحة اعتمادًا على ماهيّة نموذج الأعمال الذي تقوم به بموقعك، فربّما تودّ القيام بإنشاء خطٍّ أخير للدفاع، شيء مستقل تمامًا عن مطوري تطبيقك. فبعد كلّ شيء، ربّما يستخدم واحدٌ منهم القوائم البيضاء الخاطئة في مكان ما، أو فشل باستخدام المكتبة الصحيحة لتنظيف المُدخلات. ثغرة واحدة فقط من هذا النوع قد تسبب في تحويل موقعك بأكمله إلى موقع قابل للاختراق عبر هجمات SQL. أولًا، يجب عليك أن تفترض أنّ المهاجمين نجحوا باختراق دفاعاتك ضدّ حقن SQL، وأنّهم حصلوا على الصلاحيات الكاملة لإدارة خادومك. إنهم يملكون الآلة الآن بالكامل، على الرغم من أنّك من يهتم بصيانتها وتطويرها. لتجنّب ذلك السقوط المروع، يجب على الخادوم نفسه أن يكون مضبوطًا داخل بيئة معزولة عن الشبكة، حيث يكون مستخدم الجذر على النظام غير قادر على الرؤية أو الوصول إلى أيّ أجزاء أخرى موجودة على خادومك. هذا النوع من الدفاع يدعى DMZ، وهو رائع للغاية، وهو كذلك خارج نطاق هذا الدرس. مهما كانت الطريقة التي تستخدمها لتأمين خادومك ضدّ مستخدم مهاجم نجح بالدخول بالفعل، فإنّه يجب عليك أن تقوم بإعداد نظام تنبيهات يقوم بإخطار مدراء النظام في حال حصول نشاط معيّن على الخادوم. هذه التنبيهات ستخبرك ما إذا تمّ اختراق التطبيق، وأنّه عليك عمل مراجعة سريع للشفرة البرمجية وللخادوم نفسه. دون هذه التنبيهات، سيكون المهاجم قادرًا على قضاء وقتٍ ممتع في محاولة اختراق الـDMZ الخاصّ بك دون أن تشعر، وربّما لا تشعر بتاتًا بما يفعله إلى حين أن يسرق جميع البطاقات الائتمانية التي ظننت أنّها كانت معزولة تمامًا عن الخادوم، في بيئةً كنت تظن أنّها منفصلة عن خادومك الرئيسي. الخطوة السادسة: وظف محترف حماية إذا كنتَ تقوم بإدارة تطبيق ويب دون الاستعانة بخبير حماية، فحينها أنت تسبح بالمياه الخطيرة. وإذا كنت ولسبب ما غير قادر على توظيف خبير حماية وأمان، فإنّه يجب عليك الاستعانة بالقوائم البيضاء لتنظيف مُدخلات المستخدمين إلى حين. من السهل تضمين واستخدام القوائم البيضاء. لا بأس من تقييد تجرية المستخدمين قليلًا في سبيل حماية خادومك والبيانات الثمينة الموجودة عليه. وبمجرّد أن تقوم بتوظيف شخص يفهم في مجال الحماية والأمان، فستكون بعدها قادرًا بشكل أفضل على حماية موقعك من هجمات حقن SQL و XSS وغيرها من الهجمات الخطيرة التي قد تصيب موقعك. ترجمة -وبتصرف- للمقال: How To Secure a Cloud Server Against SQL Injection.

طُوّرت على مدار تاريخ الإنترنت العديد من الأدوات والطرق للتأكد من حماية المواقع من الاختراق، أو على الأقل جعله مستعدًا لمجابهة ذلك الخطر. أيًا كان مشروعك، متجرًا إلكتروني، أو مدونة عصرية أو حتى موقعًا لإحدى الشركات، تجب مراعاة تدابير الحماية في كل الأوقات. إذا كنت مطور/مصمم ويب، فمهمتك لم تعد تقتصر على بناء صفحات ويب جميلة، بل عليك المحافظة عليها محمية من جميع الجهات التي قد ترغب باختراقك واستغلال موقعك. ستحتاج لإجراء تدابير أمنية لمنع حصول شيء كذلك. هنالك العديد من الطرق لاختراق المواقع، لذلك يجب وضع تدابير حماية متعددة لقطع جميع تلك الطرق. لكن لا وجود لطريقة محددة قادرة على حمايتك بالكامل من المخترقين، أفضل ما يمكنك فعله هو تصعيب المهمة على المخترقين على نحو كافِ لدرجة تجعلهم ييأسون من المحاولة. طرق الاختراق الشائعة كما أسلفنا، هناك العديد من الطرق يستعملها المخترقون لتخطي حماية الموقع بهدف تدميره أو التلاعب به. سنذكر هذه الطرق حتى يمكنك إجراء تدابير وقائية للتصدي لهذه المحاولات. حقن استعلامات SQL لا يمكن إنكار أن حقن استعلامات SQL‏ (SQL Injection) هي إحدى أكثر طرق الاختراق خطرًا على كل من المواقع والأنظمة. على نحو عام، تتضمن هذه الطريقة إدخال استعلامات SQL في حقول الإدخال مثل حقول تسجيل الدخول أو حتى شريط العناوين الخاص بالمتصفح. بفعل ذلك يتمكن المخترق من الوصول لقواعد البيانات الخاصة بالموقع أو النظام. عندما تدخل اسم المستخدم وكلمة السر في حقل تسجيل الدخوليُدرَج النص الذي أدخلته إلى استعلام SQL. ذلك الاستعلام سيفحص البيانات التي أدخلتها ويوازنها بقاعدة بيانات الموقع أو النظام. بمجرد تطابق القيم المدخلة مع المسجلة ستحصل على تصريح دخولك، إذا لم تتطابق فلا يسعك الدخول. حقن قواعد البيانات يحدث عندما يحاول المخترق إدراج استعلامات SQL في حقول الإدخال الخاصة بموقعك. في العادة سيفحص الموقع البيانات المدرجة ويتأكد من صلاحيتها. إذا حدث واحتوت بياناتك مجرد علامة اقتباس (‘) بنهاية بيانات اسم المستخدم قد تفسرها قاعدة البيانات كاستعلام SQL بنَّاء، وهكذا سيُعدُّ استعلامًا صحيحا. قد لا يدخل المخترقون إلى موقعك عن طريق ذلك الاستعلام بالتحديد، لكن هذه الطريقة ستسمح لهم بالوصول إلى اسم قاعدة بياناتك، والجداول وحقول المفاتيح. وبامتلاك هذه البيانات سيحتاجون فقط إلى إدخال استعلام SQL في أحد حقول موقعك، عندها سيتمكنون من رؤية كامل محتويات قاعدة بياناتك. كيف يمكن التصدي لحقن SQL التأكد من إدخال نوع البيانات الصحيح الاستعلام باستخدام الوسائط (Parameters) تحديد الصلاحيات ترشيح IIS موحَّد تفعيل توثيق طلبات الاستعلام فكر باستخدام إطار لربط العلاقات بالكائنات (ORM) هجمات XSS الهجمات بالسكربتات العابرة للمواقع Cross Site Scripting، التي تُعرف اختصارًا بهجمات XSS، هي إحدى أكثر طرق الاختراق التى يصعب التصدي لها. في الأعوام السابقة، واجه كلٌّ من Microsoft، و MySpace، و Google صعوبات كبيرة في التعامل مع تلك الهجمات. تعتمد هجمات XSS على إرفاق سكربتات خبيثة مكتوبة بلغة جافا سكربت بالروابط الداخلية بهدف التحكم بسجلات الجلسات (Sessions) الخاصة بالموقع، أو اختطاف الإعلانات أو سرقة المعلومات الشخصية. لابد أنك تذكر حدوث هذا: قمت بالضغط خطأً على إعلان غريب الشكل، فأرسلك إلى صفحة شبيهة بتطبيقات الدردشة. ثم ترى رسالة من فتاة لطيفة تطلب منك الضغط على رابط ما للدردشة معها. وعند الضغط على الرابط يظهر لك عنوان URL غريب الشكل مثل العنوان التالي: [%63%61%74%69%6f%6e%3d%274%74%70%3a%2f%2f%77%7…] قد تعتقد أن لا شئ قد حدث ولكن لا، أنت مخطئ بالتأكيد. هذه الروابط تساعد على سرقة ملفات تعريف الارتباط (Cookies) والتي بدورها تعين المخترق على سرقة معلوماتك الشخصية. كيف يمكنك التعامل مع برمجيات تخطي المواقع لا تسمح بإدخال بيانات غير موثوقة إلا إذا تطلب الأمر ذلك خلّص (Escape) وسوم HTML عند معالجة البيانات المدخلة للحقول خلّص خصائص العناصر قبل إدراج البيانات على الموقع خلّص نصوص JavaScript من الحقول حتى تتفادى تسلل بيانات غير موثوقة إلى قيم جافاسكريبت. تخطي الاستيثاق كما يوحي الاسم، تخطي الاستيثاق مخيف. يستهدف عادةً التطبيقات أو أنظمة إدارة المحتوى سيّئة التصميم، ويمكن له إحداث فوضى عارمة بموقعك. يحدث الاختراق على نحو مشابه للتالي: البحث وإيجاد صفحة تسجيل دخول ضعيفة الحماية. فتح الشفرات المصدرية للصفحة. نسخ الشفرات إلى محرر نصِّي. حذف تعليمات JavaScript الخاصة بإدارة التصاريح وتعديل رابط أو اثنين. حفظ التغييرات على النص البرمجي. فتح الملف البرمجي الجديد على متصفحك، سجل الدخول كما لو أنك تمتلك الموقع. وهكذا نجح الاختراق! هل موقعك عُرضة لهذا الاختراق؟ هذا يعتمد على إجابة الأسئلة التالية: هل يقوم خادم موقعك بتشغيل العمليات مستعملًا صلاحيات الجذر، أو مدير النظام، أو النظام المحلي أو حسابات إدارية أخرى؟ هل يُمنح موقعك/تطبيقك صلاحيات الوصول لقاعدة البيانات عبر حساب SA (بالنسبة لأوراكل) أو حسابات أخرى مشابهة؟ هل يمتلك تطبيقك القدرة على الوصول لقاعدة البيانات عبر حسابات تمتلك صلاحيات أعلى من المطلوب؟ هل تعمل الحوسبة الافتراضية بخادم موقعك باستعمال كل الصلاحيات أو بثقة كاملة ببيئات عمل J2EE و NET.؟ هل بالإمكان تحديد إمكانية الوصول لموارد موقعك باستعمال قدرات المنصة المستعملة؟ إذا أجبت بنعم ولو على سؤال واحد فموقعك معرَّض للخطر. كيف يمكنك حماية موقعك تطوير الموقع، واختبارات الأداء ومنهجية التطوير يجدر القيام بها باستعمال أقل صلاحيات ممكنة. تأكد من أن الحسابات التى تدير بيئة العمل محدودة الإمكانات بأقصى قدر ممكن. لا يجوز أن يستخدم خادم موقعك صلاحيات مدير النظام، أو صلاحيات الجذر، أو غيرها من الحسابات الحسّاسة. حدّدد صلاحيات حسابات المستخدمين بموقعك على نحو يتناسب مع حاجتهم. لا يجوز أن تحظى حسابات الشركاء بصلاحيات إدارية والعكس صحيح. عليك استخدام حسابات مختلفة لمهام مختلفة. التدابير الشائعة لمنع الاختراق حافظ على الملحقات والبرامج محدَّثة باستمرار لا شيء يسعد المخترق أكثر من برمجية/ملحق منتهي الصلاحية. عادةً هذه هي أهدافهم المفضلة لاحتوائها على أعطال، أو خلل أو ثغرة أمنية. هذا هو السبب الرئيسي لتحديثها أساسا. لنقلها بهذه الطريقة، أنت تستخدم نوعًا ما من أقفال الأبواب تم التحايل عليه ألاف المرات. هل تتوقع أن يواجه اللص التالي مشكلة في التعامل معها؟ لذا استمع لهذه النصيحة، حدّث الآن! استخدم كلمات مرور قوية كم مرة تمت التوصية بهذا؟ من المهم للغاية استعمال كلمات مرور قوية. ربما لا تدرك أن المخترقين يحاولون سرقة كلمات مرورك باستمرار. إذن، كيف ننشىء كلمة مرورفعّالة؟ طريقة التبديل هذه طريقة جيدة للحفاظ على كلمات مرورك آمنة. حسب المبدأ، عليك استبدال الأحرف والأرقام بأحرف خاصة باستخدام طريقتك الشخصية. مثلاً: استعمل رمز '@' عوضًا عن حرف 'a' استعمل رمز '$' عوضًا عن حرف 's' استعمل رمز '%' عوضًا عن المسافات استعمل الرقم '0' عوضًا عن حرف 'o' استعمل رمز '!' عوضًا عن حرف 'i' بهذه الطريقة قمنا بتحويل كلمة سر بسيطة مثل ‘whoisjohngalt’ إلى كلمة أكثر تعقيدًا ‘wh0!$j0hng@lt’. طريقة Business Insider ابتكرت مجلة Business Insider مؤخرًا طريقة لتشكيل كلمة مرور قوية يسهل تذكرها. طبقًا للمجلة عليك إنشاء كلمة مرور طويلة لأنها تجعل الحواسيب تستغرق وقتًا طويلًا لتكتشفها. المبدأ الرئيسي لهذه الطريقة هو إنشاء كلمات مرور طويلة جدًا باستخدام كلمات غير ذات علاقة بك أو ببعضها. استخدم أداة Google Webmaster لدى Google طريقة لمساعدتك في تأمين موقعك. باستعمال أدوات Webmaster ستحظى بتنبيهات في حال العثور على برمجيات خبيثة. في حال اختراقك وعدم قدرتك على إزالة الاختراق، ستساعدك غوغل عن طريق إضافة موقعك للقائمة السوداء مما يمنحك متسعًا من الوقت للتعامل مع البرمجيات الخبيثة بموقعك، أيضًا هذه الخدمة تتيح لك رؤية تفاصيل المشكلة المرصودة. لا تعرض رقم إصدار WordPress بجانب تحديثك لمنصة التدوين، عليك دائمًا منع المخترقين من معرفة أي من إصدارات WordPress تستعمله. فعل ذلك سيمنعهم من استغلال ثغرات الحماية في موقعك. يمكنك فعل ذلك بتعديل ملف functions.php الخاص بموقعك وإضافة التعليمات التالية: function remove_version() { return ''; } add_filter('the_generator', 'remove_version'); تشديد الحماية على ملف htaccess. عادةً، حماية ملف htaccess متساهلة افتراضيًّا، لكن يمكنك تخصيصها لحمايتك من الاختراق عبر التلاعب بعناوين URL، أو حقن قواعد البيانات أوغيرها. هنالك الكثير من الطرق لتعديل ملف htaccess. لكننا سنشير إلى أكثرها جدوى. تذكّردائمًا أخذ نسخ حتياطية من الملف. order allow,deny deny from all أضف الاستعلامات التالية لمنحك مزيدًا من الأمان، علمًا أنه لن يُسمَح بالوصول غير المرغوب فيه، وستمنع زواحف محركات البحث من الوصول إلى ملف wp-admin.php. يمكن تطبيق تعليمات مماثلة على ملفات أخرى مثل install.php و eror_log. RewriteEngine On RewriteBase / RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]RewriteRule ^(.*)$ - [F,L]RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]RewriteCond %{QUERY_STRING} tag\= [NC,OR]RewriteCond %{QUERY_STRING} ftp\: [NC,OR]RewriteCond %{QUERY_STRING} http\: [NC,OR]RewriteCond %{QUERY_STRING} https\: [NC,OR]RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)||ê|"|;|\?|\*|=$).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare).* [NC]RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$ RewriteRule ^(.*)$ - [F,L] الخاتمة التعرض للاختراق بالتأكيد محبط. أنت ترى ثمرة جهودك تنهار مثل برج رملي. لكن درهم وقاية سيكون دائمًا أفضل من دينار علاج، لذا بينما كل شيء على ما يرام قم بتحسين وإصلاح كل ما يمكن إصلاحه تحسبًا لوقوع الكوارث. ترجمة -وبتصرف- للمقال Security Advice for Preventing Your Website from Being Hacked من إعداد فريق موقع 1stwebdesigner