في هذا الدرس 7تصفّح المواضيع
في فصل الواجهة الأمامية تعلّمنا حقيقة جوهرية: كل ما يعمل داخل متصفح المستخدم يمكن للمستخدم فحصه أو تعديله أو تجاوزه بالكامل. وهذا يعني أن خادم الواجهة الخلفية هو خط الدفاع الأمني الحقيقي لأي موقع أو تطبيق! فلأن الخادم يحتضن قاعدة البيانات والحسابات المالية وصلاحيات المستخدمين والمفاتيح السرية، فإن أي ثغرة في أمان الخلفية قد تعرض بيانات النظام كله للخطر. في هذا الدرس التأسيسي سنستكشف أهم ركائز أمان الواجهة الخلفية بأسلوب مفاهيمي واضح ومبسط يبني لديك الحس الأمني السليم قبل تعلم أي لغة برمجة.
قبل الغوص في تفاصيل هذا الدرس، استعرض جدول المصطلحات الأساسية التالية:
| المصطلح بالعربية | المصطلح بالإنجليزية | النطق التقني | المعنى المبسط |
|---|---|---|---|
| التحقق من المدخلات بالخادم | سيرفر سايد فاليديشن | فحص الخادم لكل بيان قادم من العميل للتأكد من نوعه وطوله ومنطقيته قبل معالجته أو حفظه. | |
| تجزئة كلمات المرور وتمليحها | باسوورد هاشينج آند سالتينج | تحويل كلمة المرور إلى بصمة مشفرة أحادية الاتجاه لا يمكن عكسها مع إضافة نص عشوائي فريد (Salt). | |
| ثغرة حقن قواعد البيانات | إس كيو إل إنجكشن | ثغرة خطيرة تحدث عند دمج نص المستخدم مباشرة داخل أمر SQL مما يسمح للمهاجم بالتلاعب بقاعدة البيانات. | |
| الاستعلامات المحضّرة الآمنة | بريبيرد ستيتمنتس | الأسلوب الآمن لكتابة أوامر قاعدة البيانات بحيث يُفصل هيكل الأمر تماماً عن بيانات المستخدم. | |
| الإشارة المباشرة غير الآمنة للموارد | آي دور (IDOR) | ثغرة تحدث عندما يغيّر مستخدم رقم السجل في الرابط (مثل /orders/500) فيعرض الخادم بيانات غيره دون فحص الملكية. | |
| تحديد معدل الطلبات | ريت ليميتينج | وضع سقف لعدد الطلبات المسموحة للمستخدم خلال فترة زمنية قصيرة لمنع تخمين كلمات المرور وإغراق الخادم. |
لماذا يردد مهندسو البرمجيات والأمن السيبراني القاعدة الذهبية: «لا تثق أبداً بأي بيانات قادمة من جهة العميل» ()؟ تخيل أن مطور الواجهة الأمامية وضع شرطاً بلغة يمنع كتابة كمية سالبة في سلة الشراء، أو أخفى زر «حذف الدورة» بتنسيق حتى لا يراه الطلاب؛ فهل هذا يحمي النظام فعلاً؟
- المهاجم لا يلتزم بشاشة المتصفح أصلاً: يستطيع أي شخص فتح أدوات المطور () لتعطيل شرط المتصفح في ثوانٍ، بل يستطيع تجاهل المتصفح بالكامل وإرسال طلب مباشر إلى الخادم باستخدام أداة مثل !
- فحص المتصفح لراحة المستخدم وفحص الخادم للحماية الحقيقية: التحقق في الواجهة الأمامية وظيفته تنبيه المستخدم العادي بسرعة لتحسين تجربته ()، أما خادم الواجهة الخلفية فيجب أن يعيد فحص كل رقم وكل سعر وكل صلاحية من الصفر وكأن الواجهة الأمامية غير موجودة.
أول بوابة يمر عبرها أي طلب فور وصوله إلى خادم الواجهة الخلفية هي التحقق الصارم من المدخلات وتطهيرها () قبل السماح لها بالوصول إلى منطق العمل أو قاعدة البيانات:
| نوع الفحص في الخادم | ماذا يفحص الخادم بالتحديد؟ | مثال لمدخلات يرفضها الخادم فوراً |
|---|---|---|
| وجود الحقل ونوع البيانات | هل الحقل الإجباري موجود؟ وهل حقل «الكمية» رقم صحيح فعلاً وليس نصاً؟ | رفض إرسال نص في خانة الكمية الرقمية |
| حدود الطول والنطاق المسموح | هل الكمية بين و؟ وهل طول الاسم لا يتجاوز الحد الأقصى المسموح؟ | رفض كمية سالبة أو نص ضخم يستهلك ذاكرة الخادم |
| مطابقة الصيغة والقائمة البيضاء | هل البريد مكتوب بصيغة قياسية؟ وهل الخيار المرسل ضمن الخيارات المعتمدة؟ | رفض بريد غير صالح أو حالة طلب غير موجودة بالنظام |
كيف يحفظ خادم الواجهة الخلفية كلمات مرور المستخدمين داخل قاعدة البيانات؟ يُمنع منعاً باتاً حفظ كلمات المرور كنص صريح مقروء ()! فلو خزّن الموقع كلمة مرورك كما هي () وتسربت نسخة من قاعدة البيانات، لانكشفت حسابات جميع المستخدمين في لحظة واحدة.
بدلاً من ذلك، تحمي أطر العمل الخلفية الحديثة كلمات المرور تلقائياً عبر التجزئة أحادية الاتجاه والتمليح ():
- التجزئة أحادية الاتجاه (): عند إنشاء الحساب، يحوّل الخادم كلمة المرور عبر معادلة رياضية باتجاه واحد إلى بصمة رموز غير مفهومة ()؛ وعند تسجيل الدخول، يجزّئ الخادم الكلمة التي كتبتها ويقارن البصمتين دون أن يعرف أحد كلمة مرورك الأصلية.
- إضافة الملح العشوائي الفريد (): يدمج الخادم نصاً عشوائياً فريداً مع كلمة مرور كل مستخدم قبل تجزئتها؛ بحيث لو اختار مستخدمان نفس كلمة المرور بالضبط، تظهر بصمتاهما في قاعدة البيانات مختلفتين تماماً.
- خوارزميات كلمات المرور البطيئة عمداً ( و): لا تُستخدم خوارزميات الفحص السريعة مثل لكلمات المرور، بل تُستخدم خوارزميات مصممة خصيصاً لتكون بطيئة ومكلفة للمهاجم مثل bcrypt وArgon2 لمنع تجربة ملايين الكلمات في الثانية.
تُعد ثغرة حقن قواعد البيانات () من أشهر وأخطر ثغرات الخوادم في تاريخ الويب. فكيف تحدث هذه الثغرة مفاهيمياً؟ وكيف يمنعها مطور الواجهة الخلفية بنسبة 100%؟
- الخطأ البرمجي المسبب للثغرة (الدمج النصي المباشر): إذا قام مبرمج بلصق النص الذي كتبه المستخدم مباشرة داخل جملة أمر ، يستطيع المهاجم إدخال علامات تنصيص وعبارات منطقية خبيثة تخدع قاعدة البيانات فتتعامل مع مدخلات المستخدم وكأنها أوامر برمجية تنفذها!
- الحل الجذري الحاسم (الاستعلامات المحضّرة ): تستخدم أطر العمل الخلفية الحديثة ما يُسمى الاستعلامات المحضّرة؛ حيث يرسل الخادم أولاً قالب الأمر إلى قاعدة البيانات مع وضع علامة استفهام () مكان قيمة المستخدم، ثم يمرر مدخلات المستخدم في خطوة منفصلة كبيانات نصية صافية يستحيل أن تنفذها قاعدة البيانات كأمر برمجي.
قارن في المثال التوضيحي الآتي بين الدمج النصي الخطر وبين الاستعلام المحضّر الآمن:
-- 1. UNSAFE: Gluing raw input directly into SQL text
SELECT * FROM users WHERE email = '$userInput';
-- 2. SAFE: Prepared Statement with ? placeholder
SELECT * FROM users WHERE email = ?;وفقاً لتقرير منظمة OWASP Top 10 العالمي لأمن تطبيقات الويب، فإن الثغرة رقم 1 الأكثر انتشاراً في المواقع الحديثة هي كسر وتجاوز الصلاحيات ()، وأشهر صورها العملية ثغرة IDOR ():
- كيف تقع ثغرة ؟ لنفترض أن المستخدم رقم سجّل دخوله وفتح فاتورته عبر الرابط ، ثم غيّر الرقم في الرابط إلى . إذا اكتفى الخادم بفحص «هل المستخدم مسجل الدخول؟» ونسِي أن يفحص «هل الفاتورة رقم 106 مملوكة فعلاً للمستخدم رقم 7؟»، فسيعرض الخادم فاتورة عميل آخر بالخطأ!
- الحل الهندسي لمنع : يجب على مطور الواجهة الخلفية فحص ملكية السجل في كل طلب ()؛ فلا يجلب الفاتورة إلا إذا كان رقمها ومملوكة للمستخدم الحالي صاحب الجلسة، وإلا يرفض الطلب فوراً بكود .
تأمل المخطط التوضيحي الآتي الذي يلخص طبقات الحماية الخمس المتكاملة داخل خادم الواجهة الخلفية:
يحتاج خادم الواجهة الخلفية أثناء عمله إلى مفاتيح سرية بالغة الحساسية: مثل كلمة مرور قاعدة البيانات، ومفتاح توقيع رموز ، ومفاتيح الربط مع بوابات الدفع الإلكتروني. فأين يحفظ مطور الواجهة الخلفية هذه الأسرار بأمان؟
- عدم كتابة الأسرار داخل ملفات الكود البرمجي أبداً: كتابة كلمة مرور قاعدة البيانات مباشرة داخل ملفات الكود تعني أنها ستُرفع مع الكود إلى منصة وتنكشف لكل من يطّلع على المستودع.
- عزل الأسرار في ملف متغيرات البيئة (): تُحفظ جميع كلمات المرور والمفاتيح السرية في ملف بيئة خاص يُسمى يبقى داخل الخادم فقط، ويُدرج اسمه داخل ملف لضمان عدم رفعه إلى مستودعات الكود نهائياً.
شاهد في المثال التوضيحي الآتي كيف يبدو ملف إعدادات البيئة داخل بيئة التطوير المحلية:
# Local development environment variables (.env)
APP_ENV=local
DB_HOST=127.0.0.1
DB_DATABASE=closetag_local
DB_USERNAME=local_dev_user
DB_PASSWORD=dev_only_placeholder_passحتى لو كان مسار تسجيل الدخول في خادمك محمياً بالاستعلامات المحضّرة وتجزئة كلمات المرور، فما الذي يمنع برنامجاً آلياً خبيثاً من تجربة 50,000 كلمة مرور شائعة على حساب مستخدم خلال دقائق (وهو ما يُعرف بهجوم التخمين Brute-Force Attack)؟ الحل الهندسي هو تحديد معدل الطلبات ():
- وضع سقف زمني للمحاولات: يراقب الخادم عدد الطلبات القادمة من نفس عنوان أو الحساب خلال نافذة زمنية محددة (مثلاً: السماح بـ 5 محاولات تسجيل دخول فقط في الدقيقة).
- الإيقاف المؤقت بكود : بمجرد تجاوز الحد المسموح، يوقف الخادم استقبال المحاولات الإضافية مؤقتاً ويرد بكود الحالة القياسي لحماية الحسابات وموارد الخادم من الإغراق.
جرّب محاكي جدار حماية الواجهة الخلفية التفاعلي الآتي لتختبر كيف يتصدى الخادم لمحاولات التلاعب بالأسعار، وحقن ، وتجاوز ملكية السجلات ، وهجمات التخمين:
ملخص الدرس
حصاد الدرسمراجعة مركّزة لأهم المفاهيم والقواعد الهندسية التي أتقنتها في هذا الدرس قبل التطبيق العملي
ماذا تعلّمت في هذا الدرس؟
تعلّمنا في هذا الدرس لماذا يمثّل خادم الواجهة الخلفية خط الدفاع الأمني الحقيقي، وكيف يرفض التحقق من المدخلات بالخادم البيانات المتلاعب بها، وكيف تحمي التجزئة أحادية الاتجاه () كلمات المرور، وكيف تقضي الاستعلامات المحضّرة على ثغرات حقن ، وكيف يمنع فحص ملكية السجل ثغرات ، وأهمية عزل الأسرار في ملفات ، ودور تحديد معدل الطلبات () في صد هجمات التخمين. الخطوة التالية: انتقل الآن إلى الدرس السادس (مميزات وتحديات مجال الواجهة الخلفية) لنتعرف بشفافية وواقعية على أبرز مميزات هذا التخصص وأهم التحديات الهندسية التي يواجهها مطور الخلفية!
سجّل الدخول لحفظ تقدمك
تابع إنجاز المواضيع والمصطلحات والمهام، وكمّل من آخر خطوة على أي جهاز.
المصطلحات7
راجع المعنى، اشرحه لنفسك، ثم علّم البطاقة كمفهومة.
- 01 Server-Side Input Validation التحقق من المدخلات في الخادم
- فحص الخادم الصارم لنوع وطول وصيغة ومنطقية البيانات القادمة من العميل دون الاعتماد على فحوصات المتصفح.
- للمراجعة
- 02 Password Hashing (bcrypt / Argon2) تجزئة كلمات المرور (bcrypt / Argon2)
- تحويل كلمات المرور إلى بصمات مشفرة أحادية الاتجاه لا يمكن عكسها مع إضافة ملح عشوائي فريد قبل حفظها في قاعدة البيانات.
- للمراجعة
- 03 SQL Injection (SQLi) ثغرة حقن قواعد البيانات (SQL Injection)
- ثغرة أمنية خطيرة تحدث عند دمج مدخلات المستخدم نصياً داخل استعلام قاعدة البيانات مما يسمح بالتلاعب بمنطق الأمر.
- للمراجعة
- 04 Prepared Statements الاستعلامات المحضّرة (Prepared Statements)
- آلية استعلام آمنة تفصل هيكل أمر SQL عن مدخلات المستخدم عبر علامات حجز (?) بحيث تُعامل المدخلات كبيانات نصية فقط ولا تُنفذ ككود.
- للمراجعة
- 05 IDOR (Insecure Direct Object Reference) ثغرة الإشارة المباشرة غير الآمنة للموارد (IDOR)
- ثغرة في ضبط الصلاحيات تحدث عندما يغير المستخدم رقم السجل في الرابط فيصل لبيانات غيره بسبب إغفال الخادم لفحص ملكية السجل.
- للمراجعة
- 06 Environment Variables (.env) ملف متغيرات البيئة السرية (.env)
- ملف إعدادات خاص بالخادم يحفظ كلمات مرور قواعد البيانات والمفاتيح السرية بعيداً عن الكود البرمجي ومستودعات Git.
- للمراجعة
- 07 Rate Limiting تحديد معدل الطلبات (Rate Limiting)
- تقييد العدد الأقصى للطلبات المسموح بها من نفس المستخدم أو عنوان IP خلال فترة زمنية محددة لمنع تخمين كلمات المرور.
- للمراجعة
لا توجد بطاقات تطابق البحث والتصفية.
اقرأ البطاقات بحرية. سجّل الدخول لحفظ تقدم مراجعتك.
الاختصارات3
راجع المعنى، اشرحه لنفسك، ثم علّم البطاقة كمفهومة.
- 01 SQLi SQLi
- SQL Injection
- حقن عبارات SQL خبيثة عبر المدخلات في الاستعلامات المبنية بالدمج النصي غير الآمن.
- للمراجعة
- 02 IDOR IDOR
- Insecure Direct Object Reference
- الوصول غير المصرح به لسجلات الآخرين عبر تغيير معرّف المورد عند غياب فحص الملكية في الخادم.
- للمراجعة
- 03 OWASP OWASP
- Open Worldwide Application Security Project
- المنظمة العالمية المفتوحة لأمن التطبيقات التي تصدر قائمة OWASP Top 10 لأشهر مخاطر الويب وطرق الحماية منها.
- للمراجعة
لا توجد بطاقات تطابق البحث والتصفية.
اقرأ البطاقات بحرية. سجّل الدخول لحفظ تقدم مراجعتك.
مهامك قبل الاختبار
خطوة صغيرة كل مرة. وإنجاز تقدر ترجع له.
-
تنقّل بين الحالات الأربع في محاكي الأمان التفاعلي وسجّل كود حالة HTTP أو الآلية الدفاعية التي أوقفت كل هجوم.
-
قارن بين السطرين في الموضوع الرابع واشرح في جملة واحدة لماذا يمنع استخدام العلامة (?) مدخلات المستخدم من تغيير منطق أمر SQL.
-
إذا طلب المستخدم رقم 7 الرابط GET /api/orders/900، اذكر الشرطين اللذين يجب على الخادم التحقق منهما قبل إرجاع بيانات الطلب رقم 900.
تأشير المهمة إقرار منك بإتمامها، وليس تصحيحًا آليًا للكود. يُحفظ تقدمك في حسابك.
اختبر فهمك.
ووصلها للإتقان.
كل سؤال خطوة لقدّام. اختار، اكتب كود، وشوف نتيجتك فورًا.
أكمل المهام، واجمع كل الإجابات الصحيحة. أقل من 100%؟ راجع وأعد المحاولة.
الأسئلة متاحة للاطلاع. سجّل الدخول للتفاعل وحفظ تقدمك.