أساسيات أمن الويب: شرح SSRF و CSRF و CORS

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

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

1. SSRF (تزوير الطلبات عبر الخادم)

SSRF هي ثغرة أمنية تسمح للمهاجم بإجبار تطبيق من جانب الخادم على إجراء طلبات HTTP إلى نطاق عشوائي يختاره المهاجم.

كيف تعمل

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

قد يقوم الخادم، الذي يعمل كوكيل، بجلب بيانات حساسة من الخدمات الداخلية التي لا تظهر على الإنترنت العام، مثل:

• بيانات تعريف السحاب: الوصول إلى 169.254.169.254 على AWS/GCP لاسترداد بيانات اعتماد IAM.
• لوحات إدارة داخلية: الوصول إلى أدوات داخلية مثل Jenkins أو لوحات تحكم Kubernetes.
• فحص المنافذ: اكتشاف الخدمات الأخرى التي تعمل على الشبكة الداخلية.

الوقاية

• القائمة المسموح بها: السماح فقط بالطلبات إلى قائمة محددة مسبقًا من النطاقات الموثوقة.
• التحقق من المدخلات: التأكد من أن عنوان URL يستخدم البروتوكولات المسموح بها (مثل https:// فقط) ولا يشير إلى نطاقات عناوين IP الداخلية.
• عزل الشبكة: التأكد من أن خادم الويب لديه وصول محدود للموارد الداخلية.

2. CSRF (تزوير الطلبات عبر المواقع)

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

كيف تعمل

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

1. يقوم المستخدم بتسجيل الدخول إلى bank.com.
2. يزور المستخدم موقعًا ضارًا evil.com في علامة تبويب أخرى.
3. يحتوي evil.com على نموذج مخفي يرسل طلب POST إلى bank.com/transfer?amount=1000&to=attacker.
4. يرسل المتصفح الطلب مع ملف تعريف ارتباط جلسة المستخدم في bank.com.
5. يرى bank.com جلسة صالحة ويقوم بمعالجة التحويل.

الوقاية

• رموز مكافحة CSRF: تضمين رمز فريد وسري وغير متوقع في كل طلب يغير الحالة. يقوم الخادم بالتحقق من هذا الرمز قبل المعالجة.
• ملفات تعريف الارتباط SameSite: ضبط سمة SameSite في ملفات تعريف الارتباط على Strict أو Lax لمنع إرسالها في الطلبات عبر المواقع.
• عناوين مخصصة: لطلبات AJAX، اطلب عنوانًا مخصصًا (مثل X-Requested-With) لا يمكن ضبطه بواسطة نموذج HTML قياسي.

3. CORS (مشاركة الموارد عبر الأصول)

على عكس SSRF و CSRF، فإن CORS ليست ثغرة أمنية بحد ذاتها، بل هي آلية أمنية. إنها طريقة للخوادم لإخبار المتصفح: “من الجيد لهذا الأصل الخارجي المحدد الوصول إلى مواردي.”

لماذا هي موجودة

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

تسمح CORS للخوادم بتخفيف هذه السياسة بأمان. عندما يقوم تطبيق ويب بطلب عبر الأصول، يرسل المتصفح عنوان Origin. يستجيب الخادم بـ Access-Control-Allow-Origin.

التكوينات الخاطئة الشائعة

• الأصل العام (*): السماح لجميع الأصول. بينما يكون مقبولاً لواجهات برمجة التطبيقات العامة، فإنه خطير إذا تم دمجه مع Access-Control-Allow-Credentials: true.
• عكس الأصل: ضبط الأصل المسموح به ديناميكيًا بناءً على عنوان Origin دون التحقق. هذا يتجاوز فعليًا سياسة الأصل الواحد بالكامل.

أفضل الممارسات

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

مقارنة ملخصة

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

ابق آمناً، وتمنياتنا لك ببرمجة سعيدة!