هجمات CSRF: فهم تزوير الطلبات عبر المواقع واختطاف الجلسات
تعد ثغرة تزوير الطلبات عبر المواقع (CSRF) من الثغرات المدمرة التي تجبر مستخدمًا تمت مصادقته على تنفيذ إجراءات غير مرغوب فيها في تطبيق ويب. على عكس هجمات البرمجة عبر المواقع (XSS)، التي تستغل ثقة المستخدم في موقع معين، تستغل CSRF الثقة التي يمتلكها الموقع في متصفح المستخدم. في هذا التحليل العميق من Cayvora Security، سنستكشف تشريح هجمات CSRF، وأمثلة HTTP من العالم الحقيقي، وتقنيات المنع الحديثة لعام 2025.
تشريح هجوم CSRF
لكي يكون هجوم CSRF قابلاً للتطبيق، يجب استيفاء ثلاثة شروط رئيسية:
- إجراء ذو صلة: يجب أن يكون هناك إجراء داخل التطبيق لدى المهاجم سبب لحثه، مثل تغيير كلمة المرور أو تحويل الأموال.
- معالجة الجلسة المستندة إلى ملفات تعريف الارتباط: يعتمد التطبيق كليًا على ملفات تعريف ارتباط HTTP لتحديد هوية المستخدم، ويرفقها المتصفح تلقائيًا.
- عدم وجود معلمات طلب غير متوقعة: لا يمكن للطلب أن يحتوي على أي معلمات لا يمكن للمهاجم تخمينها.
مثال استغلال واقعي: تحويل الأموال
ضع في اعتبارك تطبيقًا مصرفيًا يحتوي على نقطة نهاية ضعيفة:
GET /transfer.do?acct=ATTACKER_ACCOUNT&amount=10000 HTTP/1.1
Host: bank.example.com
Cookie: sessionid=abcdef1234567890
الاستغلال:
يقوم المهاجم بإنشاء صفحة ويب خبيثة تحتوي على علامة صورة غير مرئية تشير إلى نقطة النهاية:
<img src="https://bank.example.com/transfer.do?acct=ATTACKER_ACCOUNT&amount=10000" width="0" height="0" border="0" style="display:none;">
عندما تزور الضحية الموقع، يحاول متصفحها تحميل الصورة ويرفق تلقائيًا ملف تعريف ارتباط الجلسة الصالح للضحية. يقوم خادم البنك بمعالجة الطلب وتحويل الأموال.
طلبات POST عبر النماذج
لتجاوز التطبيقات التي تستخدم طلبات POST، يستخدم المهاجمون JavaScript:
<form action="https://bank.example.com/api/user/email/update" method="POST" id="csrf_form">
<input type="hidden" name="email" value="[email protected]" />
</form>
<script>
document.getElementById('csrf_form').submit();
</script>
يتم إرسال النموذج فور زيارة الصفحة، مما يؤدي إلى تنفيذ الهجوم بنجاح.
استراتيجيات المنع والمعالجة
يتطلب منع CSRF إجبار المتصفح على إثبات أن الطلب قد بدأ عن قصد بواسطة المستخدم الفعلي.
1. رموز مكافحة CSRF (نمط الرمز المتزامن)
الدفاع الأقوى هو تضمين رمز غير متوقع ومحدد للمستخدم في كل طلب يؤدي إلى تغيير الحالة.
مثال التنفيذ في PHP:
// إنشاء الرمز على الخادم
session_start();
if (empty($_SESSION['csrf_token'])) {
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}
// تضمين الرمز في النموذج
<form action="/transfer" method="POST">
<input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>">
</form>
يقارن الخادم الرمز المقدم مع الرمز المخزن في جلسة المستخدم.
2. سمة SameSite في ملفات تعريف الارتباط
توجه سمة SameSite المتصفح حول ما إذا كان سيتم إرسال ملفات تعريف الارتباط مع الطلبات عبر المواقع.
SameSite=Strict: يتم إرسال الملف فقط إذا كان الطلب ينشأ من نفس الموقع.SameSite=Lax: يوفر الحماية ضد هجمات POST الافتراضية.
تكوين آمن:
Set-Cookie: JSESSIONID=xyz123; Secure; HttpOnly; SameSite=Lax
3. طلب إعادة المصادقة
بالنسبة للإجراءات شديدة الحساسية، يجب مطالبة المستخدم بإعادة المصادقة (كلمة المرور أو رمز التحقق OTP).
الخاتمة
من خلال فهم كيفية تزوير المهاجمين للطلبات، يمكن للمطورين بناء تطبيقات مرنة تحمي جلسات المستخدمين تمامًا وتمنع الاختطاف. نرجو منك مراجعة دليل ثغرات XSS وطرق الحماية منها للحصول على أقصى درجات الأمان.
هل إدارة الجلسات في نظامك أمنة؟
تأكد من حصانة التدفقات الأمنية لديك. اتصل بشركة Cayvora Security لمراجعة هندسة الأمن السيبراني الخاصة بك.
📱 تواصل معنا عبر الواتساب في المغرب