ما هي هجمات CSRF وكيف يمكنك منعها؟

يعتبر تزوير الطلب عبر المواقع (CSRF) أحد أقدم الطرق لاستغلال نقاط الضعف في موقع الويب، إذ إنه يستهدف محولات الويب من جانب الخادم والتي تتطلب عادةً مصادقات مثل تسجيل الدخول، وأثناء هجوم CSRF، يهدف المهاجم إلى إجبار ضحيته على تقديم طلب ويب ضار وغير مصرح به نيابة عنهم.

تعتبر ممارسات أمان موقع الويب الضعيفة أو السيئة والإهمال في مسار المستخدم من الأسباب الشائعة لهجوم CSRF الناجح.

لنلقِ نظرة على هجوم CSRF والطرق الممكنة التي يمكنك من خلالها منع نفسك منه كمطور أو كمستخدم.

كيف تؤثر هجمات CSRF عليك؟

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

على سبيل المثال، يؤدي تمكين إجراءات مكافحة CSRF إلى منع التفاعلات الضارة عبر المجالات.

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

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

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

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

تم استخدام CSRF لاختطاف معاملات الأموال عبر الويب وكذلك تغيير أسماء المستخدمين وكلمات المرور، مما يؤدي إلى فقدان المستخدمين الوصول إلى الخدمة المتأثرة.

كيف يخطف المهاجمون جلساتك باستخدام CSRF

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

أثناء هجوم CSRF، تعتبر إجراءات GET و DELETE و PUT، بالإضافة إلى طلبات POST الضعيفة هي الأهداف الرئيسية للمهاجم.

لنلقِ نظرة على معنى هذه المصطلحات:

• GET: طلب لجمع نتيجة من قاعدة البيانات؛ وعلى سبيل المثال، بحث Google.
• POST: عادةً لتقديم الطلبات عبر نماذج الويب، ويعد طلب POST أمرًا شائعًا أثناء تسجيل المستخدم أو تسجيل الدخول، والمعروف باسم المصادقة.
• DELETE: لإزالة مورد من قاعدة البيانات، ويمكنك القيام بذلك عندما تقوم بحذف حسابك من خدمة ويب معينة.
• PUT: يقوم طلب PUT بتعديل أو تحديث مورد موجود، ومثال على ذلك هو تغيير اسم Facebook الخاص بك .

في الممارسة العملية، يستخدم المهاجمون اختطاف الجلسة لعمل نسخة احتياطية من هجوم CSRF، وعند استخدام هذه المجموعة، يمكن للمهاجم استخدام الاختطاف لتغيير عنوان IP للضحية.

يؤدي التغيير في عنوان IP بعد ذلك إلى تسجيل الضحية في موقع ويب جديد حيث أدخل المهاجم رابطًا مخادعًا يرسل نموذجًا مكررًا أو طلب خادم معدل تم إنشاؤه عبر CSRF.

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

مثال على هجوم GET Request CSRF

تخيل أنك تحاول إجراء الدفع عبر الإنترنت من خلال منصة تجارة إلكترونية غير آمنة، ويستخدم مالكو المنصة طلب GET لمعالجة معاملتك، قد يبدو استعلام GET هذا على النحو التالي:

https://mystorename.com/pay?amount=$10&company=[company ABC's account]

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

https://mystorename.com/pay?amount=$20000&company=[attacker's account]

بمجرد النقر فوق ارتباط لطلب GET المعدل، ينتهي بك الأمر بإجراء نقل غير مقصود إلى حساب المهاجم.

يعد التعامل مع طلبات GET ممارسة سيئة، ويجعل الأنشطة عرضة للهجمات.

مثال على هجوم طلب POST CSRF

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

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

على سبيل المثال ، قد يبدو نموذج طلب POST بالشكل التالي:

<form action="Company ABC's account" method="POST">
<input type="text" name="name" placeholder="name"><br>
<input type="number" name="amount"><br>
<input type="submit" name="submit">
</form>

ومع ذلك ، يمكن للمهاجم تبديل بيانات الاعتماد الخاصة بك عن طريق إنشاء صفحة جديدة وتعديل النموذج أعلاه إلى ما يلي:

<body onload="document.getElementById('payment-form').submit();">
<form action="Attacker's account" id="payment-form" method="POST">
<input type="text" hidden name="name" placeholder="name"><br>
<input type="number" hidden value=30000 name="amount"><br>
<input type="submit" hidden name="submit">
</form>
</body>

في النموذج الذي تم التلاعب به، يقوم المهاجم بتعيين قيمة حقل المبلغ إلى “30000”، ومبادلة رقم حساب المستلم برقمه، وإرسال النموذج عند تحميل الصفحة، وأيضًا إخفاء حقول النموذج عن المستخدم.

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

يؤدي النقر فوق هذا إلى تحميل إرسال النموذج المنسوخ، والذي يحول أموالك إلى حساب المهاجم، وهذا يعني أنك لست بحاجة إلى النقر فوق أزرار مثل “إرسال” لإجراء المعاملة، حيث يقوم JavaScript بذلك تلقائيًا عند تحميل صفحة الويب التالية.

بدلاً من ذلك، يمكن للمهاجم أيضًا صياغة بريد إلكتروني مضمن بتنسيق HTML يطالبك بالنقر فوق ارتباط لإجراء إرسال نموذج تحميل الصفحة نفسه.

إجراء آخر يكون عرضة لهجوم CSRF هو تغيير اسم المستخدم أو كلمة المرور، مثال على طلب PUT، ويقوم المهاجم بتكرار نموذج الطلب الخاص بك واستبدال عنوان بريدك الإلكتروني بعناوينهم.

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

يقوم هذا بعد ذلك بإرسال نموذج تم التلاعب به يرسل رابط إعادة تعيين كلمة المرور إلى عنوان البريد الإلكتروني للمتسلل بدلاً من عنوان بريدك الإلكتروني، وبهذه الطريقة، يغير المخترق كلمة مرورك ويسجّل خروجك من حسابك.

كيفية منع هجمات CSRF كمطور

تتمثل إحدى أفضل الطرق لمنع CSRF في استخدام الرموز المميزة المتغيرة بشكل متكرر بدلاً من الاعتماد على ملفات تعريف الارتباط للجلسة لتشغيل تغيير الحالة على الخادم.

توفر العديد من أطر العمل الخلفية الحديثة الأمان ضد CSRF، لذلك إذا كنت ترغب في تجنب الجوانب الفنية لتعزيز CSRF بنفسك، فيمكنك معالجتها بسهولة باستخدام أطر عمل من جانب الخادم تأتي مع الرموز المميزة المضادة لـ CSRF.

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

يؤدي تطبيق نظام مصادقة ثنائية (2FA) لتشغيل المعاملات على تطبيق الويب الخاص بك أيضًا إلى تقليل فرص CSRF.

من الممكن بدء CSRF عبر البرمجة النصية عبر المواقع (XSS)، والتي تتضمن إدخال البرنامج النصي في حقول المستخدم مثل نماذج التعليقات، ولمنع هذا، من الممارسات الجيدة تمكين ميزة الهروب التلقائي لـ HTML في جميع حقول نماذج المستخدم عبر موقع الويب الخاص بك، حيث يمنع هذا الإجراء حقول النموذج من تفسير عناصر HTML.

كيفية منع هجمات CSRF كمستخدم

بصفتك مستخدمًا لخدمة الويب التي تتضمن المصادقة، لديك دور تلعبه في منع المهاجمين من سرقة بيانات اعتمادك وجلساتك عبر CSRF أيضًا.

تأكد من أنك تستخدم خدمات ويب موثوقة أثناء الأنشطة التي تتضمن تحويل الأموال.

بالإضافة إلى ذلك، استخدم  متصفحات الويب الآمنة التي تحمي المستخدمين من التعرض للجلسة، بالإضافة إلى محركات البحث الآمنة التي تحمي من تسرب بيانات البحث.

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

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

عزز أمن الويب الخاص بك

يحتاج المطورون إلى اختبار تطبيقات الويب بانتظام بحثًا عن انتهاكات الأمان أثناء التطوير والنشر.

ومع ذلك، فمن الشائع إدخال نقاط ضعف أخرى أثناء محاولة منع الآخرين، لذا كن حذرًا للتأكد من أنك لم تنتهك معلمات الأمان الأخرى أثناء محاولة حظر CSRF.