أكثر 10 ثغرات أمنية على الويب شيوعًا

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

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

على وجه الخصوص ، يركز هذا الدليل على 10 مآزق أمنية على شبكة الإنترنت يجب أن تكون على دراية بها ، بما في ذلك التوصيات حول كيفية التخفيف منها. ينصب التركيز على أهم 10 ثغرات في الويب تم تحديدها بواسطة Open Web Application Security Project (OWASP) ، وهي منظمة دولية غير ربحية تهدف إلى تحسين أمان البرامج في جميع أنحاء العالم.

القليل من الدليل التمهيدي للأمن السيبراني قبل أن نبدأ - المصادقة والترخيص

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

لذا قبل المضي قدمًا ، دعنا نوضح الفرق بين هذين المصطلحين:

• المصادقة: التحقق من أن الشخص (أو على الأقل يبدو كذلك) مستخدمًا معينًا ، نظرًا لأنه قدم بيانات اعتماد الأمان الخاصة به بشكل صحيح (كلمة المرور ، والإجابات على أسئلة الأمان ، ومسح بصمات الأصابع ، وما إلى ذلك).
• التخويل: التأكيد على أن مستخدمًا معينًا لديه حق الوصول إلى مورد معين أو منحه إذنًا للقيام بعمل معين.

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

خطأ أمان الويب الشائع رقم 1: عيوب الحقن

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

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

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

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

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

خطأ أمان الويب الشائع رقم 2: المصادقة غير الصالحة

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

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

1. قد يحتوي عنوان URL على معرف الجلسة وتسريبه في رأس المُحيل إلى شخص آخر.
2. قد لا يتم تشفير كلمات المرور سواء أثناء التخزين أو النقل.
3. قد تكون معرفات الجلسة متوقعة ، وبالتالي فإن الوصول إليها أمر تافه.
4. قد يكون من الممكن تثبيت الجلسة.
5. قد يكون اختطاف الجلسات ممكنًا ، أو لم يتم تنفيذ المهلات بشكل صحيح أو باستخدام HTTP (بدون أمان SSL) ، وما إلى ذلك ...

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

خطأ أمان الويب الشائع # 3: البرمجة النصية عبر المواقع (XSS)

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

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

الخطأ الشائع لأمان الويب # 4: مراجع الكائنات المباشرة غير الآمنة

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

على سبيل المثال ، يحتوي الكود على وحدة download.php التي تقرأ وتسمح للمستخدم بتنزيل الملفات ، باستخدام معلمة CGI لتحديد اسم الملف (على سبيل المثال ، download.php?file=something.txt ). إما عن طريق الخطأ أو بسبب الكسل ، حذف المطور إذن من الكود. يمكن للمهاجم الآن استخدام هذا لتنزيل أي ملفات نظام يمكن للمستخدم الذي يقوم بتشغيل PHP الوصول إليها ، مثل رمز التطبيق نفسه أو البيانات الأخرى المتبقية على الخادم ، مثل النسخ الاحتياطية. عذرًا.

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

بالمناسبة ، كلا هذين المثالين هما أشياء رأيتها بنفسي تظهر غالبًا "في البرية".

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

الخطأ الشائع لأمان الويب # 5: خطأ في تكوين الأمان

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

1. تشغيل التطبيق مع تمكين التصحيح في الإنتاج.
2. تمكين قائمة الدليل على الخادم ، مما يؤدي إلى تسرب معلومات قيمة.
3. تشغيل برنامج قديم (فكر في مكونات WordPress الإضافية ، PhpMyAdmin القديمة).
4. وجود خدمات غير ضرورية تعمل على الجهاز.
5. عدم تغيير المفاتيح الافتراضية وكلمات المرور. (يحدث بشكل متكرر أكثر مما تعتقد!)
6. الكشف عن معلومات معالجة الأخطاء للمهاجمين ، مثل تتبعات المكدس.

الوقاية: امتلك عملية "بناء ونشر" جيدة (ويفضل أن تكون مؤتمتة) ، والتي يمكن أن تجري اختبارات عند النشر. حل خطأ التكوين الأمني ​​للرجل الفقير هو خطافات ما بعد الالتزام ، لمنع الشفرة من الخروج بكلمات المرور الافتراضية و / أو عناصر التطوير المضمنة.

الخطأ الشائع لأمان الويب # 6: التعرض للبيانات الحساسة

تتعلق ثغرة أمان الويب هذه بحماية التشفير والموارد. يجب تشفير البيانات الحساسة في جميع الأوقات ، بما في ذلك أثناء النقل وأثناء الراحة. لا استثناءات. يجب عدم نقل معلومات بطاقة الائتمان وكلمات مرور المستخدم مطلقًا أو تخزينها بدون تشفير ، ويجب دائمًا تجزئة كلمات المرور. من الواضح أن خوارزمية التشفير / التجزئة يجب ألا تكون ضعيفة - عند الشك ، توصي معايير أمان الويب بـ AES (256 بت وما فوق) و RSA (2048 بت وما فوق).

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

وقاية:

• أثناء النقل: استخدم HTTPS بشهادة مناسبة و PFS (Perfect Forward Secrecy). لا تقبل أي شيء عبر اتصالات بخلاف اتصالات HTTPS. احصل على العلم الآمن على ملفات تعريف الارتباط.

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

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

خطأ أمان الويب الشائع رقم 7: فقد التحكم في الوصول إلى مستوى الوظيفة

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

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

الخطأ الشائع لأمان الويب # 8: تزوير طلب المواقع المتقاطعة (CSRF)

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

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

ضع في اعتبارك هذا المثال:

المهاجم أليس يريد تخفيف محفظة تود عن طريق تحويل بعض أمواله إليها. بنك تود عرضة لـ CSRF. لإرسال الأموال ، يجب على تود الوصول إلى عنوان URL التالي:

http://example.com/app/transferFunds؟amount=1500&destinationAccount=4673243243

بعد فتح عنوان URL هذا ، يتم تقديم صفحة نجاح إلى Todd ويتم التحويل. تعرف أليس أيضًا أن تود تزور بشكل متكرر موقعًا تحت سيطرتها على blog.aliceisawesome.com ، حيث تضع المقتطف التالي:

<img src=http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 width=0 height=0 />

عند زيارة موقع Alice على الويب ، يعتقد متصفح Todd أن Alice ترتبط بصورة ، ويصدر تلقائيًا طلب HTTP GET لجلب الصورة ، ولكن هذا في الواقع يوجه بنك Todd لتحويل 1500 دولار إلى Alice.

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

حقيقة ممتعة: CSRF هي أيضًا الطريقة التي استخدمها الأشخاص في حشو ملفات تعريف الارتباط في الماضي حتى تصبح الشركات التابعة أكثر حكمة.

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

الخطأ الشائع لأمان الويب # 9: استخدام مكونات بها ثغرات أمنية معروفة

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

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

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

وقاية:

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

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

الخطأ الشائع لأمان الويب # 10: عمليات إعادة التوجيه وإعادة التوجيه التي لم يتم التحقق منها

هذه مرة أخرى مشكلة تصفية المدخلات. افترض أن الموقع المستهدف يحتوي على وحدة redirect.php تأخذ عنوان URL GET . يمكن أن تؤدي معالجة المعلمة إلى إنشاء عنوان URL على targetsite.com يعيد توجيه المتصفح إلى malwareinstall.com . عندما يرى المستخدم الرابط ، سيرى targetsite.com/blahblahblah التي يعتقد المستخدم أنها موثوقة ويمكن النقر فوقها بأمان. لا يعرفون سوى القليل أن هذا سينقلهم فعليًا إلى صفحة إسقاط البرامج الضارة (أو أي صفحة ضارة أخرى). بدلاً من ذلك ، قد يقوم المهاجم بإعادة توجيه المتصفح إلى targetsite.com/deleteprofile?confirm=1 .

من الجدير بالذكر أن حشو مدخلات محددة من قبل المستخدم في رأس HTTP قد تؤدي إلى إدخال رأس وهو أمر سيء للغاية.

الوقاية: تشمل الخيارات:

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

الخاتمة

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

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

يرجى استخدام هذه المعرفة بشكل مسؤول ، ولا تختبر الصفحات دون إذن!

لمزيد من المعلومات والمزيد من الهجمات المحددة من جانب الخادم ، ألق نظرة على: https://www.owasp.org/index.php/Category:Attack.

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

هنا لأمن الموقع! هتافات.