9

لا تكتب كلمة مرور مدير قاعدة البيانات في الكود

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

المبرمج عادة يجعل مستخدم واحد لقراءة البيانات و تعديلها و إدارتها، و هذا خطأ.

ما حل تلك المشكلة؟

يجب إنشاء مستخدم (مستخدم في قاعدة البيانات، يمكنك أن تبحث عن MySQL User Account Management لو تستعمل MySQL) لقراءة المحتوى و ربما إنشاء تعليقات فقط، أي صلاحيات أساسية جدا يسمح لمستخدم الموقع القيام بها.

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

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

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

أمور يجب أن تتوفر في الموقع و الخادم لكي تعمل هذه الطريقة بشكل لائق:

  • استعمال HTTPS.

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

  • استعمال خادم و برمجيات آمنة و محدثة.

  • استعمال Two-Factor Authentication للدخول إلى صفحة المدير، مثلا يجب إدخال كود تم إرساله عبر SMS إلى هاتف المدير.

  • إخفاء عنوان صفحة دخول المدير في الموقع عبر جعلها في ملف اسمه طويل و معقد مثل (site/b8218e0dca7337500a2726429c71a75aa34f6e1f)، لكن سيعرف المخترق مكان الصفحة لو استطاع تصفح الكود :-)

  • يجب أن يدخل المدير من حاسوب نظيف و أمن، ما الفائدة من كل هذا إن كان في جهازك من يتجسس عليك؟

ما رأيك بهذه الطريقة و كيف يمكن تحسينها؟

يرجى الدخول لحسابك أو تسجيل حساب لتستطيع إضافة تعليق
حساب جديد دخول

التعليقات

3
alsadi أضف ردا

إخفاء عنوان صفحة دخول المدير في الموقع عبر جعلها في ملف اسمه طويل و معقد مثل (site/b8218e0dca7337500a2726429c71a75aa34f6e1f)، لكن سيعرف المخترق مكان الصفحة لو استطاع تصفح الكود :-)

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

الطريقة الصحيحة أن لا يكون هناك موقع للإدارة بل تتم الإدارة عبر الأدوات الموثوقة للإدارة مثل ssh (وما يستعملها مثل fabric و ansible وغيرها). وإن كان ولابد لموقع إدارة أن يتم تثبيته ليستمع أو يرتبط bind على عنوان محلي فقط 127.0.0.1 وليس 0.0.0.0 ثم تتصل به عبر قناة آمنة ssh tunnel

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

0
mexaw أضف ردا

ما الفرق بين العنوانين المحليين؟ 127.0.0.1 , 0.0.0.0

1
alsadi أضف ردا

الثاني ليس محليا بل يعني أي عنوان *. مثلا عندما يستمع خادم على المنفذ 0.0.0.0:8080 فإنه يستمع للطلبت من أي مصدر إلى المنفذ 8080. في حين 127.0.0.1:8080 فإنه لا يستمع إلى المنفذ إلا للطلبات القادمة من نفس الجهاز.

2
mohamed akef أضف ردا

في حالة اختراق اي شخص الموقع فهو يمكنه ان يتم تخزين كلمة المرور الذي سوف يقوم بأدخالها المدير بهذا سوف يحصل عل كلمة مرور قاعدة البايانات

و ايضا ان تم اختراق المدير بأي شكل او الحصول عل كلمة المرور من عل جهازه الشخصي او اي شئ فبهذا انت تملك قاعده البيانات رغم ان المبرمج من الممكن ان يكون قد اضافة خاصيه Soft Deleting في الكود لكن مع حصول الشخص عل كلمة المرور سوف يكون الامر سهل للحذف عل مستوي الدادا بيز

اظن الحل ممكن ان يكون هناك سرفرين مختلفين

الاول يكون عليه قاعده البيانات و api للتخاطب مع قاعدة البيانات و في حالة طلب التعديل او الحذف يتم عمل Soft Deleting او اضافه حقول جديده بالبيانات الجديده و عمل ايقاف للحقول القديمة و يكون هذا السيرفر مؤمن بشكل كامل ولا يمكن رفع ملفات عليه او اي شئ فقد التخاطب عن طريق الapi فقد

و الثاني يكون في الكود البرمجي و هو الذي يمكن للمخترق الوصول له يفعل فيه ما شاء

0
abderraouf adjal أضف ردا

في حالة اختراق اي شخص الموقع فهو يمكنه ان يتم تخزين كلمة المرور الذي سوف يقوم بأدخالها المدير بهذا سوف يحصل عل كلمة مرور قاعدة البايانات

لقد كتبت:

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

أليس هذا مناسب لمنع المخترق من تعديل الكود و جعل الكلمة ترسل إليه؟

1
mohamed akef أضف ردا

نحن لم نحدد مستوي الاختراق فنفترض ان استطاع المخترق الوصول الي صلاحيات ال root ؟

1
abderraouf adjal أضف ردا

نحن لم نحدد مستوي الاختراق فنفترض ان استطاع المخترق الوصول الي صلاحيات ال root ؟

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

يجب أن يؤمن نظامه و دائما يحدث البرمجيات. الخطر الأكبر هو الوصول إلى root عبر ثغرة تستغل عن بعد.

كل من OpenBSD و GNU/Linux جيدان لما تديرهما بشكل جيد.

1
mohamed akef أضف ردا

كلامك سليم

2
nash-ye أضف ردا

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

معظم التطبيقات الويب اليوم، تقوم بحفظ كلمة المرور واسم مستخدم قاعدة البيانات في ملف إعدادات منفصل، وجعله للقراءة فقط. البعض ايضاً يقوم بنقله إلى خارج مجلد الـ public_html لزيادة ضمان عدم الوصول إليه بشكل سهل.

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

لذا..

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

وهذه بعض الملاظات التي يجب الإهتمام بها، إضافة إلى ما تفضلت بذكره أنت والأخوة الكرام.

1- تغيير كلمة مرور مستخدم قاعدة البيانات بشكل دوري. إختيار كلمة مرور معقدة.

2- إستخدام الـ SSL، والإستفادة منها في إنشاء إتصال آمن بقاعدة البيانات.

3- تقليل الصلاحيات الممنوحة لمستخدم قاعدة البيانات.

4- الإهتمام بآمان النظام والتطبيق ومتابعة التحديثات.

5- منع الـ Remote Connections لقاعدة البيانات.

1
hasansalem أضف ردا

أتفق معك في عدم كتابة كلمة مرور مدير قاعدة البيانات في الكود لأمان أفضل

ولكن أرى أن الطريقة البديلة التي شرحتها غير منطقية من الناحية العملية

فإنه ومع أن أمن الموقع من الأهمية بمكان إلا أن تجربة المستخدم وسهولة الإستخدام مهمة كذلك

فلا يعقل أن يقوم المدير بإدخال كلمة مرور مدير قاعدة البيانات عندك كل عملية يريد تنفيذها !

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

ولهذا فإن برمجيات كبرى الشركات العالمية على درجة كبيرة من الأمان وسهولة الإستخدام فنراهم يهتمون بكلا الجانبين

أعتقد أن هناك بعض الحلول التي أوردها الإخوة في التعليقات على درجة ممتازة من الأمان ولا تؤثر على تجربة المستخدم

موضوع رائع ونقاشات مميزة وأتطلع إلى المزيد من الآراء والطرق ليتم إثراء هذا الموضوع والوصول به إلى الأفضل

تحياتي

0
s4ad أضف ردا

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

1
abderraouf adjal أضف ردا

معك حق في هذه النقطة، فالطريقة لا تصلح لجميع أنواع المواقع.

تعديل: هناك مواقع المستخدم يعتبر فقط قارئ، و هناك مواقع المستخدم يعتبر قارئ و كاتب.

0
mohamed akef أضف ردا

ممكن حل طويل شويه لكنو منجز

ان يقوم العضو بكتابه كلمة المرور الجديده ثم تذهب الي المدير للموافقه عليها

بهذا سوف نسمح للعضو الكتابه في جدول واحد فقد و يستمر التأمين

0
Omar Albelbaisy أضف ردا

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

أعتقد أن هذه الطريقة أكثر أمانا من طلبها من المستخدم عند كل عملية.

0
abderraouf adjal أضف ردا

لكن ما الذي سيمنع المهاجم من جلب ذلك الملف؟

أين يقع ذلك الملف؟ في حاسوب آخر في على الشبكة المحلية و يجلب كلمة المرور عبر اتصال HTTP ؟

هل وضع كلمة المرور في مكان ما أكثر أمان من عدم وضعها أصلا؟

الفكرة لا بأس بها، الأمان سيعتمد على أمان ذلك الخادم الآخر (ربما فكرتك مشابه لفكرة u/mohamed-akef حول الـ API)، و يمكن تحسينها قليلا و إضافة لها 2FA .

1
Omar Albelbaisy أضف ردا

أقصد وضع الملف خارج المجلد الرئيسي القابل للوصول من خلال الويب مثل وضعه خارج مجلد www او public_html ثم تقوم بقرائتها من ذلك الملف.

لنفرض أن اسم ذلك الملف هو config.ini

وأن صفحة الphp موجودة على المجلد الرئيسي مباشرة

عندها سنقوم بقراءة محتوى ملف config.ini بالشكل التالي

$config = parse_ini_file('../config.ini');

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

2
abderraouf adjal أضف ردا

كما ذكرت سابقا الفكرة لا باس بها و هي بأمان مناسب، لكن هل عيبها أن الكلمة ممكن كشفها لو وجدت ثغرة تمكن من قراءة ملف ما في الخادم (file inclusion vulnerability) ؟

حتى بروتوكول https لم يعد آمن تماما.

هذا يعتمد على الشهادة التي في جهاز المدير حيث لا يخدع بموقع مزيف، خوارزميات التشفير المستعملة، مكتبة الـ TLS، ...

0
Omar Albelbaisy أضف ردا

هذا صحيح

0
s4ad أضف ردا

ربما ننتظر لنرى ربما تكنولوجيا تمكننا من إستعمال كلمات المرور لقواعد البيانات بنفس تقنية المفاتيح العامة و الخاصة في SSL .