فهم هجمات CSRF وتأمين نقاط الضعف CSRF

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

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

تستكشف هذه المقالة هجوم CSRF ، وكيف يعمل ، والخطوات التي يمكنك اتخاذها للاستعداد لهجوم.

ما هو هجوم CSRF؟

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

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

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

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

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

كيف يعمل هجوم CSRF؟

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

لكي ينجح هجوم CSRF ، يجب أن تحدث الشروط التالية:

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

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

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

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

دعنا نلقي نظرة فاحصة على مثالين من طرق هجوم CSRF ، أحدهما بطلب GET والآخر بطلب POST.

CSRF لطلب GET

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

لنفترض أن طلب GET لتحويل الأموال يبدو كالتالي:

 GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1

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

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

سيكون الطلب الخبيث ساريًا على أي من مستخدمي البنك طالما لديهم جلسات إدارة ملفات تعريف الارتباط المستمرة.

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

 GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1

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

 <a href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.

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

CSRF لطلب POST

دعونا نرى كيف ستختبر نفس المؤسسة المالية CSRF إذا قبلت فقط طلبات POST. في هذه الحالة ، لن يعمل تسليم الارتباط التشعبي المستخدم في مثال طلب GET. لذلك ، قد يتطلب هجوم CSRF الناجح من المهاجم إنشاء نموذج HTML. سيبدو الطلب الحقيقي لإرسال 1000 دولار لمنتج تم شراؤه كما يلي:

 POST /online/transfer HTTP/1.1 Host: xymbank.com Content-Type: application/x-www-form-urlencoded Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg amount=1000 account=547895

يتطلب طلب POST هذا ملف تعريف ارتباط لتحديد هوية المستخدم والمبلغ الذي يرغبون في إرساله والحساب الذي يريدون إرساله. يمكن للمهاجمين تغيير هذا الطلب لتنفيذ هجوم CSRF.

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

 <html> <body> <form action="https://xymbank.com/online/transfer" method="POST"> <input type="hidden" name="amount" value="500"/> <input type="hidden" name="account" value="654585" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

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

3 طرق للحد من هجمات CSRF

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

• استخدام رموز CSRF
• استخدام رأس المرجع
• اختيار حل استضافة يركز على الأمان ، مثل Kinsta

كيفية منع هجمات CSRF باستخدام رموز CSRF

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

نقاط الضعف المحتملة في رموز CSRF الرمزية

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

• تجاوز التحقق - تتخطى بعض التطبيقات خطوة التحقق إذا لم تعثر على رمز مميز. إذا تمكن المهاجم من الوصول إلى التعليمات البرمجية التي تحتوي على رمز مميز ، فيمكنه إزالة هذا الرمز وتنفيذ هجوم CSRF بنجاح. لذلك ، إذا كان الطلب الصالح إلى الخادم يبدو كالتالي:

 POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433

يحتاج المهاجم فقط إلى إزالة الرمز المميز وإرساله مثل هذا لتنفيذ الهجوم:

 POST /change_password POST body: password=pass123

• الرموز المجمعة - تحتفظ بعض التطبيقات بمجموعة من الرموز للتحقق من صحة جلسات المستخدم بدلاً من تعيين رمز مميز لجلسة ما. يحتاج المهاجم فقط إلى الحصول على أحد الرموز المميزة الموجودة بالفعل في التجمع لانتحال شخصية أي من مستخدمي الموقع.

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

 [application_url].com?csrf_token=93j9d8eckke20d433

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

• يمكن نسخ رمز CSRFs إلى ملف تعريف الارتباط - ستقوم بعض التطبيقات بنسخ المعلمات المتعلقة بالرمز المميز إلى ملف تعريف ارتباط المستخدم. إذا تمكن المهاجم من الوصول إلى ملف تعريف الارتباط هذا ، فيمكنه بسهولة إنشاء ملف تعريف ارتباط آخر ووضعه في متصفح وتنفيذ هجوم CSRF.

لذلك يمكن للمهاجم تسجيل الدخول إلى تطبيق باستخدام حسابه وفتح ملف تعريف الارتباط لرؤية ما يلي:

 Csrf_token:93j9d8eckke20d433

يمكنهم بعد ذلك استخدام هذه المعلومات لإنشاء ملف تعريف ارتباط آخر لإكمال الهجوم

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

كيفية منع هجمات CSRF باستخدام رأس المرجع

هناك إستراتيجية أخرى لمنع هجمات CSRF وهي استخدام رأس المرجع. في HTTP ، تشير رؤوس المُحيل إلى أصل الطلبات. تُستخدم عادةً لإجراء التحليلات والتحسين والتسجيل.

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

يعد استخدام رؤوس المُحيل أسهل بكثير من استخدام الرموز المميزة لأنها لا تتطلب تعريف مستخدم فردي.

نقاط الضعف المحتملة في رأس المُحيل

مثل رموز CSRF ، تحتوي رؤوس المُحيل على بعض نقاط الضعف المهمة.

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

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

 <meta name="referrer" content="no-referrer">

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

كيف يحمي Kinsta من هجمات CSRF

بالإضافة إلى استخدام رأس المُحيل ورموز CSRF ، هناك خيار ثالث وأسهل طريقة: اختيار خدمة استضافة آمنة مثل Kinsta لمواقع الويب وتطبيقات الويب الخاصة بك يوفر حاجزًا أقوى وأكثر أمانًا بين المهاجمين والمستخدمين.

علاوة على ميزات الأمان الهامة مثل النسخ الاحتياطية التلقائية ، والمصادقة الثنائية ، و SFTP عبر بروتوكولات SSH ، يوفر تكامل Kinsta Cloudflare حماية على مستوى المؤسسة مع حماية قائمة على IP وجدار الحماية.

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

ملخص

تزوير الطلبات عبر المواقع (CSRF) هو هجوم يخدع المستخدمين المصادق عليهم لبدء طلبات تغيير الحالة عن غير قصد. إنهم يستهدفون التطبيقات التي لا يمكنها التفريق بين الطلبات الصالحة والمزورة لتغيير الحالة.

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

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

يؤدي الترحيل إلى نظام استضافة آمن مثل Kinsta إلى تأمين مواقع الويب أو تطبيقات الويب من هجمات CSRF. علاوة على ذلك ، فإن تكامل Kinsta مع Cloudflare يمنع هجمات CSRF محددة.