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

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

ما هو CSRF؟

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

ما هو تأثير هجوم CSRF؟

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

كيف يعمل CSRF؟

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

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

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

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

على سبيل المثال ، لنفترض أن أحد التطبيقات يحتوي على وظيفة تتيح للمستخدم تغيير عنوان البريد الإلكتروني في حسابه. عندما يقوم المستخدم بهذا الإجراء ، فإنه يقدم طلب 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:

· يعتبر إجراء تغيير عنوان البريد الإلكتروني على حساب المستخدم محل اهتمام المهاجم. بعد هذا الإجراء ، سيتمكن المهاجم عادةً من تشغيل إعادة تعيين كلمة المرور والتحكم الكامل في حساب المستخدم.

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

· يمكن للمهاجم بسهولة تحديد قيم معلمات الطلب المطلوبة لتنفيذ الإجراء.

مع توفر هذه الشروط ، يمكن للمهاجم إنشاء صفحة ويب تحتوي على 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 إلى موقع الويب الضعيف.

· إذا قام المستخدم بتسجيل الدخول إلى موقع الويب الضعيف ، فسيقوم متصفحه تلقائيًا بتضمين ملف تعريف ارتباط الجلسة الخاص به في الطلب (بافتراض عدم استخدام ملفات تعريف ارتباط SameSite ).

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

ملحوظة

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

كيفية بناء هجوم CSRF

يمكن أن يكون إنشاء HTML المطلوب لاستغلال CSRF يدويًا أمرًا مرهقًا ، لا سيما عندما يحتوي الطلب المطلوب على عدد كبير من المعلمات ، أو هناك مراوغات أخرى في الطلب. أسهل طريقة لإنشاء ثغرة CSRF هي استخدام مولد CSRF PoC المدمج في Burp Suite Professional :

· حدد طلبًا في أي مكان في Burp Suite Professional الذي تريد اختباره أو استغلاله.

· من قائمة سياق النقر بزر الماوس الأيمن ، حدد أدوات المشاركة / إنشاء CSRF PoC .

· سيقوم Burp Suite بإنشاء بعض HTML الذي سيؤدي إلى تشغيل الطلب المحدد (باستثناء ملفات تعريف الارتباط ، والتي سيتم إضافتها تلقائيًا بواسطة متصفح الضحية).

· يمكنك تعديل الخيارات المختلفة في منشئ CSRF PoC لضبط جوانب الهجوم. قد تحتاج إلى القيام بذلك في بعض المواقف غير العادية للتعامل مع الميزات الغريبة للطلبات.

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

تطبيق عملي LAB : استغلال ثغرة CSRF

كيفية تقديم استغلال CSRF

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

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

<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">

منع هجمات CSRF

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

· لا يمكن التنبؤ به مع نسبة عالية من الانتروبيا ، كما هو الحال بالنسبة لرموز الجلسة بشكل عام.

· مرتبطة بجلسة المستخدم.

· تم التحقق من صحتها بدقة في كل حالة قبل تنفيذ الإجراء ذي الصلة.

دفاع إضافي فعال جزئيًا ضد CSRF ، ويمكن استخدامه بالاقتران مع رموز CSRF ، هو ملفات تعريف ارتباط SameSite .

نقاط الضعف الشائعة في CSRF

تنشأ نقاط الضعف الأكثر إثارة للاهتمام في CSRF بسبب الأخطاء التي ارتكبت في التحقق من صحة الرموز المميزة لـ CSRF .

في المثال السابق ، افترض أن التطبيق يشتمل الآن على رمز CSRF ضمن طلب تغيير كلمة مرور المستخدم:

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

csrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&email=wiener@normal-user.com

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

يعتمد التحقق من صحة رمز CSRF على طريقة الطلب

تقوم بعض التطبيقات بالتحقق من صحة الرمز بشكل صحيح عندما يستخدم الطلب طريقة POST ولكنه يتخطى التحقق عند استخدام طريقة GET.

تطبيق عملي LAB : استغلال ثغرة CSRF

يعتمد التحقق من صحة رمز CSRF على وجود الرمز المميز

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

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

GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

رمز CSRF غير مرتبط بجلسة المستخدم

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

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

رمز CSRF مرتبط بملف تعريف ارتباط غير متعلق بالجلسة

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

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

email=pwned@evil-user.net

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

ملحوظة

لا يلزم وجود سلوك إعداد ملفات تعريف الارتباط حتى داخل نفس تطبيق الويب مثل ثغرة CSRF. يمكن الاستفادة من أي تطبيق آخر ضمن نطاق DNS العام نفسه لتعيين ملفات تعريف الارتباط في التطبيق المستهدف ، إذا كان ملف تعريف الارتباط الذي يتم التحكم فيه له نطاق مناسب. على سبيل المثال ، يمكن الاستفادة من وظيفة إعداد ملفات تعريف الارتباط على staging.demo.normal-website.com لوضع ملف تعريف ارتباط يتم إرساله إلى secure.normal-website.com .

يتم ببساطة تكرار رمز CSRF المميز في ملف تعريف ارتباط

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

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa

csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=wiener@normal-user.com

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

تطبيق عملي LAB : استغلال ثغرة CSRF

يعتمد التحقق من صحة المرجع على header

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

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

<meta name="referrer" content="never">

يمكن التحايل على التحقق من صحة المرجع

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