See the English version
https://my-elliot.medium.com/cross-site-request-forgery-csrf-attack-f72688981aa2
ما هي CSRF(Cross-Site Request Forgery) ؟
CSRF (Cross-Site Request Forgery) هو نوع من الثغرات الأمنية التي تسمح للمهاجم بتنفيذ إجراءات غير مرغوب فيها على موقع ويب نيابة عن مستخدم مصدق عليه أو بالمعني مستخدم قام بتسجيل الدخول الي موقع معين. يستفيد الهجوم من حقيقة أن موقع الويب يعتمد على متصفح المستخدم للمصادقة عليه ، وبالتالي لا يتحقق من أن الطلب مقدم من قبل المستخدم نفسه.
من الأمثلة الشائعة على هجوم CSRF عندما يزور المستخدم موقع ويب ضارًا بينما لا يزال مسجلاً الدخول إلى موقع ويب ضعيف. يمكن لموقع الويب الضار بعد ذلك إرسال طلب إلى موقع الويب الضعيف نيابة عن المستخدم ، وسيعتقد موقع الويب الضعيف أن الطلب مشروع ويقوم بالإجراء المطلوب.
يمكن أن يكون لهجمات CSRF عواقب وخيمة ، مثل المعاملات غير المصرح بها أو سرقة البيانات أو حتى عمليات الاستحواذ الكاملة على الحساب. يحتاج مطورو الويب إلى اتخاذ خطوات لحماية مواقعهم على الويب من هجمات CSRF ، مثل تنفيذ رموز CSRF ، والتحقق من صحة رأس المرجع ، واستخدام ملفات تعريف الارتباط في نفس الموقع.
ما هو تأثير CSRF ؟
يعتمد تأثير هجوم CSRF على الإجراءات التي يستطيع المهاجم تنفيذها نيابة عن الضحية. تتضمن بعض الأمثلة على تأثير هجوم CSRF الناجح ما يلي:
- Unauthorized transactions: يمكن للمهاجم استخدام CSRF لخداع المستخدم لإجراء تعاملات غير مرغوب فيها على موقع ويب ضعيف ، مثل تحويل الأموال إلى حساب المهاجم.
- Data theft: يمكن استخدام CSRF لسرقة البيانات الحساسة من موقع ويب ضعيف ، مثل المعلومات الشخصية أو أرقام بطاقات الائتمان أو بيانات اعتماد تسجيل الدخول.
- اAccount takeover: إذا كان المهاجم قادرًا على تنفيذ إجراءات نيابة عن الضحية ، فقد يكون قادرًا على الاستيلاء على حساب الضحية على موقع الويب الضعيف ، مما يسمح له بأداء المزيد من الأنشطة الضارة.
- Reputation damage: يمكن أن يؤدي هجوم CSRF الناجح إلى الإضرار بسمعة موقع الويب الضعيف ، حيث قد يفقد المستخدمون الثقة في أمان الموقع ويترددون في استخدامه في المستقبل.
كيف تعمل CSRF ؟
يعمل هجوم CSRF من خلال استغلال الثقة التي يتمتع بها موقع الويب في متصفح المستخدم. عادةً ما يستخدم موقع الويب cookie أو tokens لتحديد هوية المستخدم والتحقق من أنه مصرح له بتنفيذ إجراءات معينة على موقع الويب.
في هجوم CSRF ، يقوم المهاجم بإنشاء موقع ويب أو بريد إلكتروني ضار يحتوي على طلب لتنفيذ إجراء معين على موقع الويب المعرض للخطر. عندما ينقر الضحية على رابط أو يزور موقع الويب الضار ، يرسل متصفحه الطلب إلى موقع الويب الضعيف ، إلى جانب أي cookie أوtokens مرتبطة بالموقع أو يحتاجها الموقع لقبول الطلب.
نظرًا لأن موقع الويب الضعيف يثق في متصفح المستخدم ، فإنه يعالج الطلب وينفذ الإجراء كما لو كان من مستخدم شرعي. يسمح هذا للمهاجم بتنفيذ إجراءات نيابة عن الضحية ، مثل تغيير معلومات حسابه أو إجراء عمليات شراء أو إجراء عمليات حساسة أخرى.
لتحقيق النجاح ، يتطلب هجوم CSRF أن يتم تسجيل دخول الضحية حاليًا إلى موقع الويب الضعيف ، وأن الموقع ليس لديه دفاعات كافية لمنع هذه الأنواع من الهجمات أو المحاولة في تخطي هذه الدفاعات.
EXAMPLE
على سبيل المثال ، لنفترض أن أحد التطبيقات يحتوي على وظيفة تتيح للمستخدم تغيير عنوان البريد الإلكتروني في حسابه. عندما يقوم المستخدم بهذا الإجراء ، فإنه يقدم HTTP Request مثل ما يلي:
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:
- يعتبر إجراء تغيير عنوان البريد الإلكتروني على حساب المستخدم محل اهتمام المهاجم. بعد هذا الإجراء ، سيتمكن المهاجم عادةً من إعادة تعيين كلمة المرور والتحكم الكامل في حساب المستخدم.
- يستخدم التطبيق cookie session لتحديد المستخدم الذي أصدر الطلب. لا توجد tokens أو آليات أخرى في المكان لتتبع user sessions.
- يمكن للمهاجم بسهولة تحديد قيم request parameters المطلوبة لتنفيذ الإجراء.
<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>إذا قام victim user أو الضحية بزيارة صفحة الويب الخاصة بالمهاجم ، فسيحدث ما يلي:
- سترسل صفحة المهاجم HTTP Request إلى موقع الويب الضعيف.
- إذا قام المستخدم بتسجيل الدخول إلى موقع الويب الضعيف ، فسيقوم متصفحه تلقائيًا بتضمين session cookie الخاص به في Request ال(assuming SameSite cookies are not being used).
- سيقوم موقع الويب الضعيف بمعالجة الطلب بالطريقة العادية ، ومعاملته على أنه تم إجراؤه بواسطة الضحية ، وتغيير عنوان بريده الإلكتروني.
خطوات البحث عن ثغرات CSRF
- قم بإنشاء حساب مستخدم وهمي في الموقع المستهدف الذي تحتاج إلى اختباره: يتضمن ذلك إنشاء حساب جديد على الموقع المستهدف خصيصًا لأغراض الاختبار. يضمن هذا عدم التأثير عن غير قصد على المستخدمين الآخرين.
- تحقق من عنوان بريدك إذا طلب التحقق: تتطلب بعض المواقع التحقق من البريد الإلكتروني لتفعيل الحسابات المنشأة حديثًا. تأكد من التحقق من عنوان بريدك الإلكتروني إذا لزم الأمر.
- انتقل إلى profile / account setting: بمجرد تسجيل الدخول ، انتقل إلى ملف التعريف أو إعدادات الحساب.
- ابحث عن النماذج الحساسة forms: ابحث عن النماذج التي تسمح للمستخدمين بتنفيذ إجراءات حساسة مثل تغيير كلمات المرور أو تحديث المعلومات أو حذف الحسابات. من المرجح أن تكون هذه الأشكال أكثر عرضة لهجمات CSRF.
- حاول تغيير القيم الافتراضية في تلك النماذج وأرسل النموذج: قم بتعديل القيم الافتراضية في النماذج وأرسلها لمعرفة ما إذا كان الموقع معرض لهجمات CSRF.
- Capture request in BurpSuite: استخدم proxy tool مثل BurpSuite لاعتراض طلبات HTTP وتعديلها.
- تحقق من وجود CSRF tokens : ابحث عن tokens التي تم إنشاؤها بواسطة الخادم والموجودة في كل form لمنع هجمات CSRF. إذا كان النموذج لا يشتمل على CSRF token أو إذا كان token يمكن التنبؤ به أو يمكن تخمينه بسهولة ، فقد يكون الموقع معرض لهجمات CSRF.
- Send the request to repeater and drop the request: كرر الطلب في BurpSuite ومعرفة ما إذا كنت تتلقى استجابة 200. فقد يكون الموقع عرضة للخطر.
- حاول تعديل الطلب: قم بتعديل الطلب قليلاً ومعرفة ما إذا كان لا يزال ناجحًا. إذا كان الأمر كذلك ، فمن المحتمل أن يكون الموقع عرضة لهجمات CSRF.
- تحقق مما إذا كانت القيمة التي قدمتها عبر Burp repeater قد تم تحديثها في ملفك الشخصي profile: إذا تم تحديث القيمة التي قدمتها عبر Burp repeater بنجاح في ملفك الشخصي ، فإن الموقع عرضة لهجمات CSRF.
- إنشاء smaple exploit عن طريق انشاء صفحة ويب للمهاجم أو attacker: تتضمن هذه الخطوة إنشاء صفحة ويب تحتوي على form يحتوي على نفس الحقول مثل form المعرض للخطر على الموقع المستهدف.
<html>
<body>
<h1>this is page!</h1>
<img src="https://example.com/images/candidate.jpg">
<form action="https://example.com/vote.php" method="post" enctype="multipart/form-data" class="form-horizontal">
<input type="hidden” name="firstname" value="hacker">
<input type="hidden" name="lastname" value="hacker">
<input type="hidden" name="email" value="hacker@mail.com">
<input type="hidden" name="confirm_email" value="hacker@mail.com">
<input type="hidden" name="telephone" value="809090900">
<input type="submit" value="Click Here!">
</form>
</body>
</html>Bypassing CSRF Protection
- قم بإزالة CSRF token: تستخدم بعض مواقع الويب CSRF token كإجراء للتخفيف من هجمات CSRF. هذا token عبارة عن مجموعة عشوائية من الأحرف تتغير في كل مرة يتم فيها تحميل موقع الويب. إذا قمت بإزالة قيمة token وparameter من الطلب request، فمن الممكن تجاوز حماية CSRF. ومع ذلك ، لا تستخدم جميع مواقع الويب رموز CSRF ، وقد يكون لبعضها أشكال أخرى من الحماية ، لذلك قد لا تكون هذه التقنية فعالة دائمًا.
- Register 2 users: في هذه التقنية ، تقوم بتسجيل اثنين من المستخدمين على موقع الويب المستهدف واستبدال رمز الحماية CSRF الخاص بمستخدم واحد بطلب المستخدم الآخر. إذا نجح الطلب ، فسيكون التطبيق المستهدف عرضة لهجمات CSRF. يمكن استخدام هذه التقنية لاختبار فعالية آلية حماية CSRF.
- قم بإزالة رمز CSRF وتغيير method إلى "GET" في request:يمكن أن يؤدي تغيير request method إلى GET إلى تجاوز آليات حماية CSRF التي تتحقق فقط من طلبات POST. ومع ذلك ، تستخدم العديد من مواقع الويب إجراءات أمان إضافية ، مثل التحقق من request method ، لذلك قد لا تعمل هذه التقنية دائمًا.
- حاول تخمين tokrn:إذا كان بإمكانك تخمين تنسيق CSRF token ، فيمكنك إضافة token خاص بك إلى الطلب لتجاوز حماية CSRF. يجب أن يكون token الجديد بنفس طول token الأصلي. ومع ذلك ، قد لا يكون تخمين تنسيق token دائمًا سهلاً ، خاصةً إذا تم إنشاؤه عشوائيًا.
- إزالة anti-CSRF headers من الطلب:تستخدم بعض مواقع الويب إجراءات أمان إضافية ، مثل anti-CSRF headers ، للحماية من هجمات CSRF. بإزالة هذه headers ، يمكنك تجاوز آلية الحماية. ومع ذلك ، قد يكون لبعض مواقع الويب إجراءات أمنية أخرى ، وقد لا تكون هذه التقنية فعالة.
Escalating the Attack
Common defences against CSRF
- CSRF tokens - CSRF tokens هو قيمة فريدة وسرية وغير متوقعة يتم إنشاؤها بواسطة التطبيق من جانب الخادم ومشاركتها مع العميل. عند محاولة تنفيذ إجراء حساس ، مثل إرسال نموذج ، يجب على العميل تضمين رمز CSRF المميز الصحيح في الطلب. هذا يجعل من الصعب جدًا على المهاجم إنشاء طلب صالح نيابة عن الضحية.
- SameSite cookie - تعد SameSite آلية أمان للمتصفح تحدد متى يتم تضمين ملفات تعريف الارتباط الخاصة بموقع الويب في الطلبات التي تنشأ من مواقع الويب الأخرى. نظرًا لأن طلبات تنفيذ الإجراءات الحساسة تتطلب عادةً cookie session ، فقد تمنع قيود SameSite المناسبة المهاجم من تشغيل هذه الإجراءات عبر المواقع. منذ عام 2021 ، يفرض Chrome قيود Lax SameSite افتراضيًا. نظرًا لأن هذا هو المعيار المقترح ، نتوقع أن تتبنى المتصفحات الرئيسية الأخرى هذا السلوك في المستقبل.
- Referer-based validation - تستخدم بعض التطبيقات HTTP Referer header لمحاولة الدفاع ضد هجمات CSRF ، عادةً عن طريق التحقق من أن الطلب نشأ من المجال الخاص بالتطبيق. هذا بشكل عام أقل فعالية من التحقق من CSRF token validation.
- CAPTCHAs: تستخدم CAPTCHAs للتحقق من أن الطلب تم بواسطة إنسان وليس بواسطة script أو bot. يمكن أن تكون فعالة في منع هجمات CSRF ، ولكنها قد تكون أيضًا غير مريحة للمستخدمين.
- Two-Factor Authentication: تضيف المصادقة الثنائية طبقة إضافية من الأمان من خلال مطالبة المستخدم بتوفير شكلين من أشكال المصادقة. يمكن أن يكون هذا فعالًا في منع هجمات CSRF ، ولكنه قد يكون أيضًا غير مريح للمستخدمين.
- HTTP Methods: يمكن استخدام HTTP Methods لتقييد نوع الطلبات التي يمكن إجراؤها. على سبيل المثال ، يمكن استخدام طلبات GET لقراءة البيانات ، بينما يمكن استخدام طلبات POST لتعديل البيانات. يمكن أن يكون هذا فعالًا في منع هجمات CSRF التي تعتمد على تعديل البيانات.
- Session Expiration: يمكن استخدام انتهاء الجلسة لتحديد مقدار الوقت الذي تكون فيه session نشطة. يمكن أن يكون هذا فعالًا في منع هجمات CSRF التي تعتمد على سرقة active session.