تحت هذه التغريدة بإذن الله سأتحدث عن موضوع مهم وسؤال يرد كثيراً، " كيف أجعل موقعي آمن ضد أغلب الهجمات الأمنية؟" بحاول يكون الجواب مبسط وسهل. *سلسلة التغريدات ستأخذ أيام لتكتمل* وكالعادة، الموضوع مفتوح للمشاركة من الجميع.
أولاً، لازم نتفق أن المسؤول الأول عن أمان الموقع هم المبرمجين "مهندسي البرمجيات" بشكل أساسي. فكرة أن المبرمج يكتب البرنامج بشكل غير مسؤول عن آمن النظام، ومن ثم شخص آخر " مختص آمن معلومات" يدقق من الصفر أمر خطأ.
يجب على مهندس البرمجيات أن يبني التطبيق من الصفر على أساس أن يكون أمن، سريع ، سهل الأختبار، وهكذا. أمر جدا أساسي في منظومة DevOps
مختص أمن المعلومات يأتي كمختص للتدقيق وللحالات الخاصة وليس لتعديل أمان النظام بشكل كامل.
مختص أمن المعلومات يأتي كمختص للتدقيق وللحالات الخاصة وليس لتعديل أمان النظام بشكل كامل.
الحين ندخل في موضوع أمان تطبيقات الشبكة العنكبوتية. التغريدات التالية تركز فقط على أهم الممارسات والنصائح الي تجعل من موقعك بشكل كامل آمن "نسبياً" ضد أغلب الهجمات الإلكترونية.
الحديث ينقسم بإذن الله لثلاث أقسام: جهة العميل، جهة الخادم، ونقل البيانات بينهم. والخطوات الأمنية الازمة في كل قسم.
client-side <-> data transmission <-> server-side
client-side <-> data transmission <-> server-side
جهة العميل:
في بدايات الأنترنت، كانت جهة العميل عبارة عن صفحة استعراض لنتائج العمليات التي يقوم بها جهة الخادم. بمعنى أنه لم يكن هناك أي برنامج يعمل في جهة العميل. مجرد استعراض صفحات وربما بعض التأثيرات البسيطة باستخدام جافا سكربت. لهذا، أمن المعلومات في هذا القسم لم يكن ضرورياً
في بدايات الأنترنت، كانت جهة العميل عبارة عن صفحة استعراض لنتائج العمليات التي يقوم بها جهة الخادم. بمعنى أنه لم يكن هناك أي برنامج يعمل في جهة العميل. مجرد استعراض صفحات وربما بعض التأثيرات البسيطة باستخدام جافا سكربت. لهذا، أمن المعلومات في هذا القسم لم يكن ضرورياً
العتاد لجهة العميل تطور كثير وأصبح بإمكانه تنفيذ برمجيات معقدة وضخمة. وهنا بدأ عصر تطبيقات الشبكة العنكبوتية وأصبحت جهة العميل مهمة جداً كأهمية جهة الخادم من ناحية الاهتمام بجودة البرمجيات والسرعة وبالطبع أمان البرمجيات.
مصدر الصور هنا:
1drv.ms
1drv.ms
بما أن جهة العميل أصبحت مسؤولة عن تشغيل جزء وربما أغلب البرمجيات في تطبيقات الشبكة العنكبوتية، وجب علينا التأكد أن هذه الجهة تعمل بأمان ومن الصعب إضرارها أو السيطرة على طريقة عملها.
المشكلة أن فكرة إرسال كود إلى عميل غير موثوق ومحاولة تشغيله في بيئة مجهولة ثم ادعاء أن البرنامج سيعمل بشكل آمن صعب جداً. لهذا، دعنا نفترض على الأقل أن البيئة المجهولة آمنة.
للمزيد عن معضلة Trusting Trust
vxer.org
vxer.org
في جهة العميل، عندك مصدرين خطر: الأول هو المستخدم نفسه والثاني هو طرف آخر يحاول الدخول بينك وبين العميل. المصدر الأول في الغالب أنه يستهدف الخادم تبعك ويحاول مثلا ينفذ بعض الأوامر الغير مسموحة. الردع والحماية من هذا المستخدم ممكنة فقط في جهة الخادم.
لأن أغلب الحمايات الي بترسلها للمتصفح هي لحمايته هو. الحاصل أنه يستطيع تخطي الحمايات بكل بساطه لأنها بالأساس ما تعيقه أبد. في الأخير أنت قاعد تلعب في أرضة وبين جمهوره :). بإذن الله بتكلم عن الحماية ضد هذا المستخدم وتنقيح المدخل إذا تكلمنا عن الحماية في جهة الخادم.
الأن خلنا نشوف المصدر الثانية، هنا تبدأ اللعبة بينك وبين الخطر الرئيسي. تنبيه بسيط قبل ما نبدأ، ما راح أتكلم عن الهجمات بشكل معمق، بإذن الله سأستعرض الحلول وأقدم مراجع إذا أردت الاستزادة.
بما أنا بتكلم عن جهة المستخدم خلنا نفترض أن الخادم آمن والاتصالات أمنه ومشفره وكذا نقدر نركز فقط على المستخدم. أول خطر يكمن أن هناك طرف ثالث يريد قراءة معلومات في متصفح مستخدمك تخص موقعك مثلا cookies كيف تحمي مستخدمك الآن ؟
أولاً أبدأ بالشيء السهل. أجعل هذه المعلومات غير قابلة للقراءة. مثلاً cookies إجعلها قابلة للقراءة فقط من قبل HTTPوليس من الجافا سكربت، وترسل فقط عن طريق HTTPS. تقدر تعمل هذا من خلال إعدادات الخادم. الصورة التالية أخذتها لموقع أتصفحه ويظهر أنه وضع cookies with secure flag
وماذا عن HTML5 storage ? هذا أصعب شوي. مافيه secure flag له على حد علمي. تقدر تستخدمة بإمان إذا منعت هجوم XSS بالكامل على موقعك. هجوم XSS هو عبارة عن طرف ثالث يقوم بتنفيذ أكواد داخل متصفح مستخدمك خلال تصفح موقعك لإحداث ضرر لمستخدمك أو ضرر لخادمك.
طيب كيف نقوم بالحماية هنا؟ الحل الجديد والأفضل هو بإستخدام content security policy. معروفة بإختصار CSP. ال CSP يإختصار هو عبارة عن واحد من HTTP headers الخاص يتأمين موقعك.
تقدر من خلالها تعمل قائمة بالمواقع المسموح لموقعك التواصل بها ومنع أي inline code من العمل. وش معنى inline code ؟ معناه أكواد تنفذ من خلال طرف ثالث يرفقها في رابط الموقع أو يكون بداخل script tag بداخل صفحة HTML. الق نظرة على مثال هجمة XSS على موقع ebay.
كتابة CSP كامل ووافي أمر صعب جداً جداً. قد يأخذ وقت طويل لكن صدقني الموضوع يستاهل. بإذن الله بارفق مراجع راح تساعدك في فهم وتنفيذ CSP
الهجوم الأخر الي أحب أذكر هو Cross Site Request Forgery أو CSRF.فكرة الهجوم أن المهاجم يضع رابط يقوم المستخدم بضغطة لتنفيذ أمر في الموقع الخاص بك من غير علم المستخدم. مثلا حذف ملفات!
وبما أن المتصفح يرسل cookies مع كل HTTP requetهذا يعني أن المستخدم قد ينفذ أوامر حساسة حتى التي تطلب تسجيل دخول بدون علم منه!! الحل الأبسط والأجمل هو بإستخدام Cross Origin Resource Sharing أو CORS .
وهو قائمة بالمصادر الموثوقة التي تخبر خادمك أن يقبل منها الطلبات. بمعنى لو مهاجم حاول وضع رابط ل API خاصة بك في موقع لم تسمح له بمخاطبة خادمك، فهذا العملية ستفشل. صورة توضح الخطأ الذي سيقع حينما يحاول المهاجم التواصل مع خادمك عن طريق ربطه في موقعه الخاص.
فيه هجمات كثير تقدر تتفاداها. بس بالنسبة لي، أخطر هجومن تأتي من طرف المستخدم الي لازم مهندس البرمجيات يتفاداها من البداية هي XSS و CSRF. والحل لتفادي هذه الهجمات زي ما قلت CSP و CORS منفذة بإتقان.
خلنا نعطي بعض المصادر هنا، لأني أعلم التغريدات السابقة غير كافية أطلاقاً :).
أولا فديوهات:
youtube.com
youtube.com
أولا فديوهات:
youtube.com
youtube.com
الان خلنا نتكلم عن مرحلة نقل البيانات Data Transition .المصدر الوحيد للخطر هنا هو أن يكون هناك شخص يتنصت على الإتصال بين الخادم والعميل، هذا الشخص أو "البرنامج" يسمى في مجال أمن المعلومات بـ Man-In-The-Middle. وش الحل مع المتطفل هذا ؟ شفر كل أتصالاتك بإستخدام TLS/SSL
TLS/SSL هي طبقة تشفير تستخدمها مع معيار HTTP وينتج عن هذا الدمج المعيار HTTPS. أستخدام ال https في جميع إتصالات الخادم والعميل أمر مهم جدا جدا جدا. إذا موقعك لا يستخدم الـ https في جميع أتصالاته، فهو غير أمن بعض النظر عن أي جهود آخرى.
لماذا؟ لان سلامة البيانات وموثوقيتها غير مضمونة في حال عدم استخدام https. مثلا يستطيع متطفل التنصت على شبكة أنترنت داخل مقهى. ويستطيع إيضاً تغير ال payload الي جاي من الخادم للمستخدم. والكارثة الكبرى أنه يستطيع قراءة إعطاء بينات آخرى للمستخدم.
تخيل أنك تملك موقع وقمت بتنفيذ جميع النصائح الي قدمتها لك في تأمين موقعك في مرحلة المستخدم. مثلا كتبت أفضل CSP في العالم :). لكن الخطأ الكبير الذي ارتكبته هو أنك ما استخدمت https. بما أن CSP عبارة عن HTTP header. يقدر أي متطفل على الشبكة قراءته وتعديله أو حذفه. مصيبة!
قبل مدة، الكثير من المطورين يحاجك أن أستخدام https غالي الثمن بسبب سعر الشهادة المرتفع، لهذا فقط يقوم باستخدامها في صفحات تسجيل الدخول. المشكلة أن هذا الحل غير صحيح وهو مجرد خدعة يخدع بها من حوله أن موقعه أمن. في النهاية أي متطفل يستطيع تغير الرابط لصفحة التسجيل لصفحة آخرى مزيفة!
عموما السبب هذا أنتفى وأصبح أستخراج الشهادات أمر سهل جدا ومجاناً. شكرا لمبادرة letsencrypt.org
مصادر1
youtube.com
youtube.com
مصادر3
fouad.io
fouad.io
تأمين جهة الخادم يعتبر أصعب مهمة في عملية بناء تطبيقات شبكة عنكبوتية آمنة. كما سبق، بإذن الله سأسرد الأسس والخطوات الرئيسية في هذا الموضوع. أول وأهم نقطة هي ضبط عملية التحقق من الهوية والصلاحية Authentication & Authorization .
أما إذا قررت إدارة عمليات التحقق من الهوية والصلاحية بنفسك، فهناك عدة تحديات: 1. سرقة قاعدة بيانات المستخدمين، لتخفيف ضرر هذا الخطر يجب عليك تشفير كلمات المرور بإستخدام خوارزميات ال hashing الآمنة مثل SHA-512 or BCrypt
خطر آخر هنا هو أن المهاجم بعد ما يسرق قاعدة البيانات يحاول يعاود إنتاج القيم قبل تطبيق hashing. أو بما يعرف بـ Rainbow table لتفادي هذه المشكلة يجب أن تضيف مايسمى ب salt عند تنفيذ عملية hashing ويجب أن يكون قيمة salt كبيرة يصعب إعادة إنتاج ال hash.
الخطر الثالث هنا مايسمى بـ brute force attack لتخمين كلمة المرور. الحل هنا هو بجعل عملية الـ hasing أو بالأدق key derivation بطيئة حيث لا يتسنى للمهاجم تخمين كم كبير من كلمات المرور في وقت قصير.
بعد نقطة ضبط عملية التحقق من الهوية والصلاحية تأتي نقطة الدفاع ضد هجمات حقن الأوامر "Injection” وأشهرها مايعرف بـ SQL injection. لجعل موقعك أو تطبيقك منيع ضد هذه الهجمة يجب عليك التأكد أن ليس هناك نقطة وصل بين مدخلات المستخدم وبين أوامر البرنامج.
بمعنى لا تأخذ ما يعيطه لك المستخدم كمدخل وتحقنه أو تضيفه مباشرة في أمر برمجي، لأن هذا قد يسمح للمهاجم التلاعب بالأمر البرمجي مثل أمر SQL، فيجب عليك تعقيم وتصفية مدخلات المستخدم من ما يسمى Metacharacters.
بالنسبة لـ denial of services attacks ،فصعب جدا جدا ضمان أن موقعك منيع ضده 100%.
خصوصا لما يكون موقعك يخدم كل دول العالم، الحل هنا أن ترفع جداً من تكلفة هذه الهجمة على المهاجم، وأفضل طريقة هي عن طريق استخدام الحوسبة السحابية.
خصوصا لما يكون موقعك يخدم كل دول العالم، الحل هنا أن ترفع جداً من تكلفة هذه الهجمة على المهاجم، وأفضل طريقة هي عن طريق استخدام الحوسبة السحابية.
فمثلا تقوم بإعداد موقعك ليتحمل نص مليون طلب في الثانية لكن في حال الحاجة يستطيع موقعك الاتساع بشكل عرضي scale horizontally إلى ثلاث ملايين طلب. وفي حال الاتساع يقوم الموقع بتنبيهك لتراقب الوضع. . الآن المهاجم يحتاج إلى توليد مايقارب ثلاث ملايين طلب لينفذ الهجوم بنجاح.
وآخيراً، تأكد دائما من أن برمجياتك محدثة إلى آخر أصدار، فأغلب الهجمات تأتي من ثغرات معروفة وليست ثغرات Zero-day.
المصدر 1
youtube.com
youtube.com
المصدر 2 ، أطلع على الفصل 5 ، 7 ، 8، 9
dwheeler.com
dwheeler.com
جاري تحميل الاقتراحات...