ما هو Cross-site request forgery (CSRF)؟
في هذه المقالة، سأشرح ما هي Cross-site request forgery (CSRF)، ونوضح بعض الأمثلة عن الثغرات الشائعة في CSRF، واشرح كيفية منع الهجمات التي تعتمد على CSRF.
Cross-site request forgery (CSRF)، والمعروف أيضًا باسم CSRF، هو ثغرة أمنية في الويب تتيح للمهاجم إجبار المستخدمين على تنفيذ إجراءات لا ينوون القيام بها. تمكن المهاجم من تجاوز جزئي لسياسة المصدر الواحد (same origin policy)، التي صُممت لمنع المواقع المختلفة من التدخل في بعضها البعض.
ما هو تأثير هجوم CSRF؟
في حالة نجاح هجوم CSRF، يقوم المهاجم بجعل المستخدم الضحية ينفذ إجراءً دون قصد. على سبيل المثال، قد يكون هذا الإجراء هو تغيير عنوان البريد الإلكتروني في حسابه، تغيير كلمة المرور، أو إجراء تحويل مالي. بناءً على طبيعة الإجراء، قد يتمكن المهاجم من الحصول على تحكم كامل في حساب المستخدم. وإذا كان المستخدم المُخترق يتمتع بدور إداري في التطبيق، فقد يتمكن المهاجم من السيطرة الكاملة على بيانات التطبيق ووظائفه.
ما هو تأثير هجوم CSRF؟
لكي يكون هجوم CSRF ممكنًا، يجب أن تتوافر ثلاثة شروط أساسية:
1.إجراء ذو صلة: يجب أن يكون هناك إجراء في التطبيق يرغب المهاجم في إجبار المستخدم على تنفيذه. قد يكون هذا إجراءً محظوظًا (مثل تعديل صلاحيات المستخدمين الآخرين) أو أي إجراء يتعلق ببيانات المستخدم نفسه (مثل تغيير كلمة مرور المستخدم).
2.إدارة الجلسات بالاعتماد على الكوكيز: يتطلب تنفيذ الإجراء إرسال طلبات HTTP، ويعتمد التطبيق فقط على session cookies لتحديد هوية المستخدم الذي أرسل الطلبات. لا توجد آلية أخرى لتتبع الجلسات أو التحقق من صحة الطلبات.
3.عدم وجود معلمات طلب غير متوقعة: الطلبات التي تنفذ الإجراء لا تحتوي على معلمات لا يمكن للمهاجم تحديد قيمها أو تخمينها. على سبيل المثال، إذا كان المهاجم بحاجة إلى معرفة قيمة كلمة المرور الحالية لتغيير كلمة المرور، فلن يكون التطبيق عرضة للهجوم.
مثال على كيفية تنفيذ هجوم CSRF
افترض أن هناك تطبيقًا يحتوي على وظيفة تتيح للمستخدم تغيير عنوان البريد الإلكتروني في حسابه. عند قيام المستخدم بهذا الإجراء، يرسل طلب HTTP مشابه لهذا:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
email=wiener@normal-user.com
هذا الطلب يستوفي شروط CSRF:
جراء تغيير البريد الإلكتروني للمستخدم مهم للمهاجم، حيث يمكنه بعد ذلك إعادة تعيين كلمة المرور والسيطرة على الحساب بالكامل.
يستخدم التطبيق session cookie لتحديد المستخدم الذي أرسل الطلب. لا توجد رموز أو آليات أخرى لتتبع الجلسات.
يمكن للمهاجم بسهولة تحديد قيم المعلمات المطلوبة لتنفيذ الإجراء.
كيفية تنفيذ هجوم CSRF باستخدام HTML
في هذه الحالة، يستطيع المهاجم إنشاء صفحة ويب تحتوي على الكود التالي:
<html>
<body>
<form action="https://vulnerable-website.com/email/change" method="POST">
<input type="hidden" name="email" value="pwned@evil-user.net" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
إذا قام المستخدم الضحية بزيارة صفحة المهاجم، سيحدث ما يلي:
ستقوم صفحة المهاجم بإرسال طلب HTTP إلى الموقع الضعيف.
إذا كان المستخدم مسجلًا دخوله في الموقع الضعيف، سيقوم المتصفح تلقائيًا بتضمين session cookie الخاصة بالمستخدم في الطلب (بافتراض عدم استخدام SameSite cookies).
سيقوم الموقع الضعيف بمعالجة الطلب كأنه تم من قِبل المستخدم الضحية وتغيير عنوان البريد الإلكتروني الخاص به.
كيفية إنشاء هجوم CSRF
يعد إنشاء HTML اللازم لاستغلال CSRF يدويًا أمرًا مرهقًا، خصوصًا إذا كان الطلب يحتوي على عدد كبير من المعلمات. أسهل طريقة لإنشاء استغلال CSRF هي باستخدام مولد CSRF PoC المدمج في Burp Suite Professional:
حدد الطلب في أي مكان في Burp Suite Professional الذي ترغب في اختباره أو استغلاله.
من قائمة السياق التي تظهر عند النقر بزر الفأرة الأيمن، اختر Engagement tools / إنشاء CSRF PoC.
سيقوم Burp Suite بإنشاء بعض أكواد HTML التي ستُرسل الطلب المحدد (دون ملفات تعريف الارتباط، التي ستُضاف تلقائيًا من قبل متصفح الضحية).
يمكنك تعديل الخيارات المختلفة في مولد CSRF PoC لتخصيص جوانب الهجوم. قد تحتاج إلى ذلك في بعض الحالات غير المعتادة للتعامل مع خصائص غير معتادة في الطلبات.
انسخ HTML المُنشأ إلى صفحة ويب، وافتحها في متصفح يكون فيه المستخدم مسجلًا دخوله في الموقع الضعيف، واختبر ما إذا تم إرسال الطلب المطلوب بنجاح وإذا ما تم تنفيذ الإجراء المطلوب.
كيفية تسليم استغلال CSRF
آليات تسليم هجمات CSRF تشبه إلى حد كبير الهجمات العاكسة reflected XSS. غالبًا ما يقوم المهاجم بوضع HTML الضار على موقع ويب يتحكم فيه، ثم يجبر الضحايا على زيارة هذا الموقع. قد يتم ذلك عن طريق إرسال رابط إلى المستخدم عبر البريد الإلكتروني أو وسائل التواصل الاجتماعي. أو في حال تم إدراج الهجوم في موقع شهير (على سبيل المثال، في تعليق المستخدم)، يمكن أن ينتظر المهاجم ببساطة حتى يقوم المستخدمون بزيارة الموقع.
لاحظ أن بعض هجمات CSRF البسيطة تستخدم طريقة GET ويمكن أن تكون مكتفية ذاتيًا عبر URL واحد على الموقع الضعيف. في هذه الحالة، قد لا يحتاج المهاجم إلى استخدام موقع خارجي، ويمكنه إرسال URL ضار مباشرة إلى الضحية. على سبيل المثال، إذا كان طلب تغيير البريد الإلكتروني يمكن تنفيذه باستخدام طريقة GET، فإن الهجوم المكتفي ذاتيًا سيكون بالشكل التالي:
<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">
الدفاعات الشائعة ضد CSRF
في الوقت الحالي، غالبًا ما يتطلب العثور على ثغرات CSRF وتجاوزها التحايل على إجراءات الحماية ضد CSRF. تشمل الدفاعات الشائعة:
CSRF tokens: وهي رموز فريدة وسرية وغير قابلة للتنبؤ يتم إنشاؤها بواسطة التطبيق ويجب تضمينها في الطلبات الحساسة.
SameSite cookies: وهي آلية أمان تعتمد على المتصفح تحدد متى يتم تضمين ملفات تعريف الارتباط في الطلبات القادمة من مواقع أخرى.
Referer-based validation: تعتمد بعض التطبيقات على ترويسة Referer للدفاع ضد CSRF.
بهذه الطرق يمكن حماية التطبيقات من الهجمات التي تعتمد على CSRF.