يوفر استكشافًا معمقًا لهجمات تزوير طلبات المواقع المختلفة (CSRF)، بشرح آلياتها، وتوضيح أمثلة، والتفصيل في طرق الوقاية المختلفة لتعزيز أمان تطبيقات الويب.
عند العمل في تطوير الويب، خاصة مع ملفات تعريف الارتباط، نسمع غالبًا عبارات مثل "هذا الإعداد يساعد في منع CSRF". ومع ذلك، فإن الكثير من الناس لديهم فكرة غامضة فقط عن ما يعنيه "CSRF" حقًا.
اليوم، سنقوم بالغوص في عمق CSRF، وهو خلل أمني شائع على الويب. سيساعدنا هذا في التعامل مع القضايا المتعلقة بـ CSRF بشكل أكثر فاعلية.
CSRF (تزوير الطلبات عبر المواقع) هو نوع من الهجمات على الويب حيث يخدع المهاجمون المستخدمين المصادق عليهم لأداء إجراءات غير مقصودة. ببساطة، إنه "هاكرز يتظاهرون بأنهم مستخدمون لتنفيذ إجراءات غير مصرح بها".
لفهم CSRF، نحتاج إلى فهم بعض المفاهيم الرئيسية:
سياسة نفس الأصل هي ميزة أمان في المتصفحات التي تحد من كيفية تفاعل مستند أو سكريبت من أصل واحد مع الموارد من أصل آخر.
يتكون الأصل من بروتوكول (مثل HTTP أو HTTPS)، اسم المجال، ورقم المنفذ. على سبيل المثال، https://example.com:443 هو أصل واحد، بينما https://demo.com:80 أصل آخر.
تقيّد سياسة نفس الأصل الوصول إلى البيانات بين الصفحات من أصول مختلفة، مما يعني:
ومع ذلك، للحفاظ على الانفتاح وقابلية التشغيل البيني للويب (مثل تحميل الموارد من CDN أو إرسال الطلبات إلى APIs خارجية للتسجيل)، لا تقوم سياسة نفس الأصل بتقييد الطلبات الشبكية عبر الأصول:
<script>، <img>، <link>، <iframe>)آلية إرسال ملفات تعريف الارتباط تلقائيًا هي ميزة مهمة في المتصفحات. عندما يرسل المتصفح طلبًا إلى مجال، يقوم تلقائيًا بربط جميع ملفات تعريف الارتباط لذلك المجال. هذه العملية تلقائية ولا تتطلب أي شيفرة جافا سكريبت أو تفاعل من المستخدم.
تسمح هذه الآلية للمواقع بتذكر حالة تسجيل دخول المستخدمين بسهولة لأن كل طلب يحمل تلقائيًا معلومات هوية المستخدم.
غامق
على سبيل المثال، عندما تسجل الدخول إلى موقع بنك (bank.com) وتحصل على ملف تعريف هوية، ثم عندما تضغط لمشاهدة كشف حسابك، يجد المتصفح تلقائيًا جميع ملفات تعريف الارتباط المطابقة لـ bank.com ويرفقها بطلب كشف الحساب. يمكن للبنك بعد ذلك تحديد هويتك من الخلفية وإرجاع معلومات كشف حسابك.
يقوم المستخدم بتسجيل الدخول إلى الموقع المستهدف (مثل موقع البنك) ويحصل على ملف تعريف المصادقة. تستخدم هذه الخطوة آلية إرسال ملفات تعريف الارتباط تلقائيًا. بعد أن يقوم موقع البنك بتعيين ملف تعريف مصادقة الهوية، سيقوم المتصفح تلقائيًا بإرفاق هذا الملف بكل طلب يتم إرساله إلى ذلك الموقع.
بدون تسجيل الخروج، يزور المستخدم موقعًا ضارًا. في هذه المرحلة، بسبب سياسة نفس الأصل، لا يمكن للموقع الضار قراءة أو تعديل ملف تعريف الارتباط لموقع البنك مباشرة. يحمي هذا هوية المستخدم من السرقة المباشرة.
يشتمل الموقع الضار على طلب للموقع المستهدف (مثل عملية التحويل).
على الرغم من أن سياسة نفس الأصل تقيد الوصول عبر الأصول، إلا أنها تسمح بالطلبات الشبكية عبر الأصول، مثل الطلبات التي يتم البدء بها من خلال علامات <img>, <form>. يستغل المهاجمون هذا "الثغرة".
يرسل متصفح المستخدم هذا الطلب تلقائيًا، مع ملف تعريف الارتباط للموقع المستهدف. هذا هو جوهر هجوم CSRF. يستغل السماح بسياسة نفس الأصل للطلبات عبر الأصول وآلية إرسال ملفات تعريف الارتباط تلقائيًا (حتى الطلبات التي تبدأ من مواقع ضارة ستحتوي على ملف تعريف الارتباط المطابق للمجال).
يتلقى الموقع المستهدف الطلب، ويتحقق من صحة ملف تعريف الارتباط، وينفذ العملية. لا يمكن للخادم معرفة ما إذا كان هذا الطلب قادمًا من إجراء مستخدم شرعي لأن ملف تعريف الارتباط المرفق صحيح.
دعونا نوضح كيف يحدث هجوم CSRF من خلال مثال محدد. سنستخدم موقع بنك خيالي bank.com كمثال.
أولاً، يزور المستخدم https://bank.com ويسجل الدخول إلى حسابه.
بعد تسجيل الدخول بنجاح، يقوم الخادم بتعيين ملف تعريف المصادقة، مثلاً:
يقوم المستخدم بتنفيذ عملية تحويل على موقع البنك، مثل تحويل 1000 دولار إلى آليس. قد يرسل هذا الإجراء طلبًا مثل هذا:
الآن، لنفترض أن مهاجمًا أنشأ موقعًا ضارًا https://evil.com يحتوي على HTML التالي:
عندما يضغط المستخدم على رابط https://evil.com دون تسجيل الخروج من حسابه البنكي، ولأنه مسجل دخول بالفعل إلى bank.com، فإن المتصفح يحتوي على ملف تعريف session_id صالح.
بعد تحميل الصفحة الضارة، ترسل بشكل تلقائي النموذج المخفي، وترسل طلب تحويل إلى https://bank.com/transfer.
يقوم المتصفح تلقائيًا بإرفاق ملف تعريف الارتباط الخاص بـ bank.com بهذا الطلب. يتلقى خادم bank.com الطلب، يتحقق من صحة ملف تعريف الارتباط، ثم ينفذ هذه العملية الغير المصرح بها.
إليكم بعض الطرق الشائعة المستخدمة في الدفاع عن هجمات CSRF. سنشرح بالتفصيل مبدأ كل طريقة وكيف تعمل بفعالية في منع هجمات CSRF:
تعد رموز CSRF واحدة من أكثر الطرق فعالية للدفاع عن الهجمات. إليكم كيف تعمل:
نظرًا لأن رمز CSRF هو قيمة فريدة مرتبطة بجلسة المستخدم، ولا يمكن للمهاجم معرفة أو تخمين هذه القيمة (نظرًا لأنها تختلف لكل جلسة)، حتى لو نجح المهاجم في خداع المستخدم لإرسال طلب، سيتم رفض الطلب بواسطة الخادم بسبب عدم وجود رمز CSRF صالح.
مثال على التنفيذ:
على الجانب الخادم (باستخدام Node.js وExpress):
في جافا سكريبت الواجهة الأمامية:
Refererيحتوي عنوان Referer على URL الصفحة التي بدأت الطلب. من خلال التحقق من عنوان Referer، يمكن للخادم تحديد ما إذا كان الطلب يأتي من مصدر شرعي.
نظرًا لأن هجمات CSRF تأتي عادةً من نطاقات مختلفة، سيظهر عنوان Referer اسم نطاق المهاجم. من خلال التحقق مما إذا كان Referer هو القيمة المتوقعة، يمكن حظر الطلبات من مصادر غير معروفة.
ومع ذلك، من الجدير بالذكر أن هذه الطريقة ليست موثوقة تمامًا، حيث إن بعض المتصفحات قد لا ترسل عنوان Referer، ويمكن للمستخدمين تعطيل إرسال عنوان Referer من خلال إعدادات المتصفح أو الإضافات.
مثال على التنفيذ:
SameSite لملفات تعريف الارتباطSameSite هي صفة لملفات تعريف الارتباط تُستخدم للتحكم في ما إذا كانت ملفات تعريف الارتباط تُرسل مع الطلبات عبر المواقع. لديها ثلاث قيم محتملة:
Strict: تُرسل ملفات تعريف الارتباط فقط في الطلبات من نفس الموقع.Lax: تُرسل ملفات تعريف الارتباط في الطلبات من نفس الموقع والتنقل في المستوى الأعلى.None: تُرسل ملفات تعريف الارتباط في جميع الطلبات عبر المواقع (يجب استخدامها مع صفة Secure).عندما يتم تعيين SameSite إلى Strict، يمكن أن تمنع تمامًا المواقع الإلكترونية من إرسال ملفات تعريف الارتباط عبر طرف ثالث، مما يمنع بفعالية هجمات CSRF.
إذا تم تعيين SameSite إلى Lax، فإنه يحمي العمليات الحساسة مع السماح ببعض حالات الاستخدام عبر المواقع الشائعة (مثل الدخول إلى موقع من روابط خارجية).
مثال على التنفيذ:
بالنسبة لطلبات AJAX، يمكن إضافة رؤوس طلب مخصصة. نظرًا لقيود سياسة نفس الأصل، لا يمكن للمهاجمين تعيين رؤوس مخصصة في الطلبات عبر الأصول. يمكن للخادم التحقق من وجود هذا الرأس المخصص للتحقق من صحة الطلب.
مثال على التنفيذ:
على الواجهة الأمامية:
على الجانب الخادم:
التحقق المضاعف لملف تعريف الارتباط هو تقنية فعالة للدفاع ضد CSRF. مبدأها الرئيسي هو أن يقوم الخادم بتوليد رمز عشوائي، ويقوم بتعيينه كملف تعريف ارتباط ويتضمنه في الصفحة (عادةً كحقل مخفي في النموذج). عندما يرسل المتصفح طلبًا، يتم تضمين ملف تعريف الارتباط تلقائيًا، بينما تقوم جافا سكريبت الخاصة بالصفحة بإرسال الرمز كمعامل طلب. يتحقق الخادم بعد ذلك مما إذا كان الرمز في ملف تعريف الارتباط يتطابق مع الرمز في المعاملات.
على الرغم من أنه يمكن للمهاجمين تضمين ملف تعريف الارتباط الخاص بموقع الهدف في الطلبات عبر المواقع، إلا أنهم لا يمكنهم قراءة أو تعديل القيمة في ملف تعريف الارتباط، كما لا يمكنهم الوصول إلى أو تعديل قيمة الرمز في الصفحة. عن طريق طلب أن يتضمن الطلب رموزًا من ملف تعريف الارتباط والمعاملات، فإنه يضمن أن الطلب يأتي من مصدر لديه الإذن بقراءة ملف تعريف الارتباط، وبالتالي يدافع بفعالية ضد هجمات CSRF.
بالنسبة للإجراءات الحساسة بشكل خاص (مثل تغيير كلمات المرور أو إجراء تحويلات كبيرة)، يمكن مطالبة المستخدمين بإعادة المصادقة. يوفر هذا نقطة تفتيش أمنية إضافية للمستخدمين. حتى إذا نجح المستخدم في بدء هجوم CSRF، فلن يتمكن من اجتياز خطوة إعادة المصادقة.
اقتراحات التنفيذ:
من خلال هذا النقاش المتعمق، نأمل أن يكون لديك الآن فهم أكثر شمولاً لهجمات CSRF. لم نتعلم فقط كيف يعمل CSRF، بل استكشفنا أيضًا مجموعة متنوعة من التدابير الدفاعية الفعالة. كل هذه الطرق يمكن أن تعزز بشكل فعال أمان تطبيقات الويب.
نأمل أن تساعدك هذه المعرفة في التعامل بشكل أفضل مع القضايا ذات الصلة بـ CSRF في تطويرك اليومي وبناء تطبيقات ويب أكثر أمانًا.