دليلك الشامل لمعرفة كل شيء عن شهادة +A

ماهي CSRF ؟

أولاً، "Cross-Site Request Forgery" هو اختصار لتقنية الاحتيال عبر طلب الموقع الآخر، وتعرف أيضًا بأسماء أخرى مثل الهجوم بنقرة واحدة وXSRF وغيرها.

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

ماذا يمكنني ان افعل عن طريق CSRF ؟

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

اكتشاف الثغرة 

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

دعنا نلقي نظرة سريعة على مثال بسيط لنموذج HTML موجود في بنك، على سبيل المثال:

  
<form accept-charset=”UTF-8″ action=”/sendmoney.php” method=”post”>
<input name=”name” type=”text” value=””>
<input name=”account_number” type=”text” value=””>
<input name=”credit_card_number” type=”text” value=””>
<input name=”expiration_date” type=”text” value=””>
<input name=”cnc_security_digits” type=”text” value=””>
<input name=”amount” type=”text” value=””>
<input type=”submit” value=”Send Money” class=”button”>
  

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

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

 <example.com/index.php?q=<script>document.location.href=’YOUR_CSRF_ATTACK_URL'</script

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

يمكن أيضًا الوصول إلى البيانات التي تمر عبر الشبكة عن طريق هجوم MITM (Man-in-the-Middle)، على سبيل المثال، إذا كنت قد نجحت في الوصول إلى شبكة معينة ونفذت هذا الهجوم، فيمكنك قراءة البيانات التي تمر عبرها وليس فقط القراءة، بل يمكنك حقن الإطارات (IFrames) في المواقع الموثوق بها. على سبيل المثال، إذا كنت قد سجلت الدخول في موقع بنك يستخدم اتصال آمن (HTTPS)، لكن الموقع معرض لهجمات CSRF، في هذه الحالة، يمكنك نقل الأموال من الضحية لنفسك إذا كنت أنت من ينفذ الهجوم.

هذا هو مثال على ثغرة CSRF، حيث يمكنك قراءة هذا التقرير في موقع HackerOne مثلاً: https://hackerone.com/reports/127703. ويمكنك تغيير البريد الإلكتروني وقراءة التقرير ومحاولة فهمه بشكل جيد. هذا مثال آخر أيضًا لتقرير في HackerOne: https://hackerone.com/reports/834366.

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

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

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

عمل Bypasses

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

بالإضافة إلى ذلك، يمكن للموقع الويب تكرار رمز CSRF مع الكوكيز ومعلمة الطلب (request parameter)، أو تعيين رمز CSRF ككوكي CSRF والتحقق منه في الخادم الخلفي (backend). يجب أن تتوخى الحذر فيما يتعلق بهذه النقطة وتحاول العثور على ثغرات مثل تعدد الأسطر النهائية (CRLF)، والتي يمكننا مناقشتها فيما بعد، حيث يمكنك تغيير الكوكيز على سبيل المثال أو ما شابه ذلك. هذه نقطة مهمة يجب أن تأخذها في الاعتبار.

الحماية من هجمات الCSRF 

لحماية الموقع الخاص بك من هجمات CSRF، يمكنك اتباع  الخطوات التالية:

1. استخدام تحقق عنوان المنشأ (Origin) أو الاستعلام المشترك (Referer): يمكنك التحقق من عنوان المنشأ أو الاستعلام المشترك للتأكد من أن الطلبات المرسلة إلى التطبيق مأتاة من نفس الموقع. يمكنك قبول الطلبات فقط إذا كان المنشأ أو الاستعلام المشترك متطابقًا مع عنوان الموقع الأصلي.

2. استخدام رمز مصادقة مزدوج (Double-Submit Cookie): يمكنك إرسال رمز مصادقة مزدوج (مثل رمز مصادقة عشوائي مضاف إلى ملف تعريف الارتباط) مع كل طلبة تم إنشاؤها من قبل الموقع، ومقارنته مع قيمة الارتباط في الجانب الخادم. إذا كانت القيمتان غير متطابقتين، فيعني ذلك أن الطلب مزور ويجب رفضه.

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

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

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

6. التحقق من الهوية والصلاحيات: يجب عليك تنفيذ نظام موثوق به للتحقق من هوية المستخدم والتحقق من صلاحياته قبل تنفيذ أي طلبات تتطلب حقوق وصلاحيات خاصة.

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