شرح ثغرة CSRF

شرح ثغرة CSRF: الدليل الكامل لهجوم الخداع الخفي

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

أهلاً بك في عالم Cross-Site Request Forgery أو CSRF. دي مش ثغرة بتسرق كلمة سرك، دي ثغرة بتخليك انت بنفسك تدي الأمر للبنك بالتحويل، من غير ما تحس أو تعرف. إنها هجوم بيحول متصفحك اللي انت واثق فيه لسلاح ضدك. في المقال ده، هنشرّح الثغرة دي بالتفصيل، من أول فكرتها لحد أعقد طرق استغلالها والدفاع عنها.

لمتابعه باقي الثغرات هتلاقيها في قسم : (Cyber Security)

الجزء الأول: الخدعة - يعني إيه CSRF بالظبط؟

ثغرة CSRF هي هجوم بيستغل الثقة اللي بين الموقع (Server) ومتصفحك (Browser). لما انت بتعمل Login في أي موقع، الموقع بيديلك زي "بطاقة هوية" صغيرة اسمها Session Cookie عشان يفضل فاكرك. المتصفح بتاعك ذكي، وبشكل تلقائي بيبعت الـ Cookie دي مع أي طلب رايح لنفس الموقع، عشان يقوله: "أنا أحمد، اللي لسه عامل Login من شوية".

هجوم CSRF بيتلخص في إن المهاجم بيخدع متصفحك عشان يبعت طلب لموقع انت مسجل دخولك فيه، زي طلب "تغيير الإيميل". بما إن المتصفح بيبعت الـ Cookie بتاعتك تلقائيًا مع الطلب ده، الموقع بيشوف الطلب وبيعتقد إنك انت اللي بعته بإرادتك، فبينفذه فورًا.

تشبيه "المكالمة التليفونية"

عشان الصورة توضح أكتر، تخيل السيناريو ده:

بناء الثقة: انت بتتصل بالبنك وبتجاوب على كل أسئلة الأمان. موظف البنك دلوقتي واثق فيك تمامًا وعارف إن أي طلب هييجي من صوتك ورقمك هو طلب شرعي.
المهاجم بيتدخل: انت لسه على الخط مع البنك، لكنك بتتكلم في موضوع تاني. بييجي مهاجم (صاحب الموقع الخبيث) ويهمس في ودنك بجملة متحضرة كويس: "من فضلك، حوّل مبلغ 1000 جنيه للحساب رقم XYZ".
الخيانة من الداخل: انت، من غير تركيز، بتردد نفس الجملة بالظبط لموظف البنك. صوتك هو هو، ورقم تليفونك هو هو.
التنفيذ الأعمى: موظف البنك (الـ Server) معندهوش أي سبب يخليه يشك. الطلب جاي من المصدر الموثوق (صوتك ورقمك، أو متصفحك والـ Cookies بتاعتك)، فبينفذ التحويل فورًا.

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

الجزء الثاني: وصفة الهجوم - الشروط الـ 3 لنجاح هجوم CSRF

عشان هجوم CSRF ينجح، لازم الـ 3 شروط دول يكونوا متوفرين زي مكونات الطبخة بالظبط. لو مكون واحد ناقص، الطبخة بتبوظ.

إجراء مهم (A Relevant Action): لازم يكون فيه إجراء على الموقع المهاجم يقدر يستفيد منه. لو كل اللي الـ User يقدر يعمله هو تغيير لون خلفية بروفايله، فثغرة CSRF هنا ملهاش أي قيمة. لكن لو الإجراء ده هو تغيير الإيميل، تغيير كلمة السر، حذف الحساب، إرسال رسالة، إضافة منتج للسلة، أو إجراء تحويل مالي، ساعتها الهجوم بيكون له تأثير حقيقي ومدمر.
الاعتماد على الـ Cookies في الجلسات (Cookie-Based Sessions): ده هو قلب الثغرة. لازم الموقع يكون بيعتمد على Session Cookies عشان يتعرف على المستخدمين اللي مسجلين دخولهم. ليه؟ لأن المتصفحات مصممة إنها تبعت الـ Cookies المتعلقة بموقع معين مع أي طلب رايح للموقع ده، بغض النظر عن الطلب ده بدأ منين (سواء بدأ من الموقع نفسه أو من موقع خبيث). الخاصية دي اسمها Ambient Authority، وهي اللي المهاجم بيراهن عليها.
عدم وجود پارامترات عشوائية (No Unpredictable Parameters): المهاجم لازم يكون قادر يعرف أو يخمن كل الـ Parameters اللي الطلب محتاجها عشان يتنفذ. لو طلب تغيير كلمة السر مثلاً بيحتاج 3 Parameters: new_password, confirm_new_password, والأهم old_password. المهاجم يقدر يجهز أول اتنين، لكنه مستحيل يعرف كلمة السر القديمة بتاعتك. وجود الـ Parameter التالت ده لوحده كفيل إنه يدمر هجوم CSRF بالكامل.

الجزء الثالث: الارتباك الكلاسيكي - إيه الفرق بين CSRF و XSS؟

دي نقطة مهمة جدًا عشان تفهم عقلية كل هجوم.

الميزة	CSRF (Cross-Site Request Forgery)	XSS (Cross-Site Scripting)
الثقة المستغلة	الموقع بيثق في متصفح المستخدم.	المستخدم بيثق في الموقع.
الهدف الأساسي	إجبار المستخدم على تنفيذ إجراءات (`State- Changing Actions`).	سرقة بيانات المستخدم أو السيطرة على جلسته.
مكان الهجوم	المهاجم بيخلي متصفحك يبعت طلب لموقع تاني. الهجوم بيحصل عبر المواقع.	المهاجم بيحقن `Code` ضار في الموقع نفسه. الهجوم بيحصل داخل الموقع.
(Vector)	عادة بيكون `Form` مخفية أو `Tag` صورة في موقع المهاجم.	بيكون حقل إدخال في الموقع الضحية نفسه (زي التعليقات).
الدفاع الأساسي	`Anti-CSRF Tokens` أو `SameSite Cookies`.	`Output Encoding` و `Content Security Policy (CSP)`.

باختصار شديد: في هجوم XSS، الكود الضار بيكون على الموقع اللي انت بتزوره وبيسرق منك حاجات. في هجوم CSRF، الكود الضار بيكون على موقع تاني خالص، وبيستخدمك انت كأداة عشان تهاجم الموقع اللي انت مسجل دخولك فيه.

الجزء الرابع: طرق الهجوم - CSRF عن طريق GET و POST

1. هجوم GET-based CSRF (السهل الممتنع)

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

عن طريق Tag صورة:

<img src="http://victim-site.com/delete-account?confirm=true" width="0" height="0">.
الصورة دي مش هتظهر لأنها 0x0 بيكسل، لكن المتصفح هيحاول يحملها وهيبعت الطلب في الخلفية.

عن طريق رابط عادي: المهاجم ممكن يبعتلك الرابط ده في إيميل ويقولك "دوس هنا عشان تكسب جايزة".

2. هجوم POST-based CSRF (الكلاسيكي والأكثر شيوعًا)

ده النوع الأقوى لأن معظم الإجراءات الخطيرة بتستخدم طلبات POST. المهاجم هنا بيحتاج يعمل Form مخفية ويبعتها تلقائيًا

باستخدام JavaScript. عشان يخلي الهجوم غير مرئي تمامًا، المهاجم ممكن يحط الـ Form دي جوه iframe مخفي

(style="display:none") عشان الضحية ميلاحظش أي تغيير في الصفحة وهو بينفذ الهجوم.

الجزء الخامس: عين القنّاص - إزاي تختبر بنفسك ثغرة CSRF

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

GET ولا POST؟ إيه الـ Parameters اللي اتبعتت؟
ابحث عن الدفاعات: دي أهم خطوة. بص كويس في الطلب، هل فيه أي Header غريب زي X-CSRF-Token؟

هل فيه Parameter في جسم الطلب اسمه csrf_token أو nonce وقيمته عبارة عن حروف وأرقام عشوائية؟

لو مش لاقي أي حاجة من دول، احتمالية وجود الثغرة بتبقى عالية جدًا.
أعد إرسال الطلب (بدون دفاعات): خد الطلب ده من Burp Repeater واحذف منه أي Headers أو

Parameters شكلها عشوائي وشكلك إنها ممكن تكون Token، وبعدين ابعته تاني. لو الطلب نجح والإجراء اتنفذ،

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

Engagement tools -> Generate CSRF PoC. الأداة دي هتنشئلك كود HTML جاهز تقدر تستخدمه عشان تثبت وجود الثغرة.

الجزء السادس: بناء الفخ - إزاي تعمل Proof of Concept (PoC) لثغرة CSRF

الـ PoC هو دليلك المادي على وجود الثغرة. ده مثال عملي ومفصل على PoC لتغيير الإيميل:

HTML
<html>
  <head>
    <title>CSRF Proof of Concept</title>
  </head>
  <body>
    <form id="csrf-form" action="https://victim-site.com/account/change-email" method="POST">
      <input type="hidden" name="email" value="attacker-email@evil.com" />
    </form>

    <script>
      document.getElementById('csrf-form').submit();
    </script>

    <h1>Please wait, loading awesome content...</h1>
  </body>
</html>

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

إعلان). بمجرد ما الضحية (اللي مسجل دخوله في victim-site.com) يفتح الرابط، إيميله هيتغير في الخلفية وهو بيقرأ جملة
"Please wait...".

الجزء السابع: الضرر - سيناريوهات حقيقية لتأثير CSRF

سيناريو 1 (السيطرة على الحساب): مهاجم بيكتشف إن وظيفة "إضافة إيميل ثانوي" في موقع كبير مصابة
بـ CSRF.

بيبعت PoC للضحية بيضيف إيميل المهاجم كإيميل ثانوي لحساب الضحية. بعد كده، المهاجم بيروح لصفحة "نسيت كلمة

السر" وبيطلب إعادة تعيينها على الإيميل الثانوي اللي هو ضافه، وبكده بيسيطر على الحساب بالكامل.
سيناريو 2 (التحكم في الراوتر المنزلي): كتير من صفحات إعدادات الراوتر القديمة
(اللي بتفتحها من 192.168.1.1)

كانت بتستخدم Basic Authentication ومش بتحمي ضد CSRF. مهاجم ممكن يعمل صفحة خبيثة، بمجرد ما

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

الجزء الثامن: الدرع الأساسي - إزاي الـ Anti-CSRF Tokens بتشتغل؟

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

دورة حياة الـ Token

الإنشاء: لما الـ User بيعمل Login، الخادم بينشئ Token عشوائي تمامًا وفريد (زي a3b1c5d9e...)

وبيربطه بالجلسة بتاعة الـ User ده وبيخزنه عنده.
التضمين: لما الخادم بيبعت أي صفحة فيها Form حساسة (زي صفحة تغيير الإيميل)، بيحط نسخة من الـ Token ده

جوه الـ Form كحقل مخفي:

<input type="hidden" name="csrf_token" value="a3b1c5d9e...">.
الإرسال: لما الـ User بيدوس على زر Submit، المتصفح بيبعت كل بيانات الـ Form، بما فيهم الـ Token المخفي.
التحقق: لما الطلب بيوصل للخادم، الخادم بيعمل حاجتين قبل ما ينفذ أي حاجة:
- هل الطلب ده فيه csrf_token؟
- لو فيه، هل القيمة بتاعته هي نفس القيمة اللي أنا مخزنها للجلسة دي؟
  لو الإجابتين "نعم"، الطلب بيكمل. لو أي إجابة "لأ"، الخادم بيرفض الطلب فورًا ويعتبره هجوم.

ليه ده بيوقف الهجوم؟ لأن المهاجم اللي بيعمل Form في موقعه الخبيث، معندهوش أي طريقة يعرف بيها قيمة
الـ Token
السري والفريد بتاع جلسة الضحية، فطلبه هيوصل للخادم من غير Token صحيح وهيترفض.

الجزء التاسع: دفاعات إضافية - SameSite Cookies وحاجات تانية

SameSite Cookies (الدفاع الصامت): دي خاصية رائعة في المتصفحات الحديثة. هي عبارة عن Attribute
بيتحط على الـ Cookie عشان يحدد إمتى المتصفح المفروض يبعتها. ليها 3 قيم:

Strict: المتصفح مش هيبعت الـ Cookie دي مع أي طلب جاي من موقع خارجي على الإطلاق. دي أقوى حماية

ضد CSRF لكنها ممكن تكسر بعض وظائف الموقع العادية.
Lax: المتصفح هيبعتها مع طلبات GET اللي جاية من مواقع خارجية (زي لما تدوس على رابط عادي)، لكن مش

هيبعتها مع طلبات POST. دي هي القيمة الافتراضية في معظم المتصفحات الجديدة، وهي لوحدها بتحمي ضد

معظم هجمات CSRF الكلاسيكية.
None: المتصفح هيبعت الـ Cookie مع كل الطلبات زي زمان.

نمط Double Submit Cookie: دي طريقة دفاع مش بتحتاج تخزين الـ Token في الخادم. الخادم بيبعت الـ

  Token كـ Cookie عادية، وفي نفس الوقت بيطلب من الـ JavaScript في الصفحة إنه ياخد قيمة الـ Token
ده من الـ Cookie ويحطه في Header معين مع كل طلب. الخادم بعد كده بيقارن قيمة الـ Cookie بقيمة الـ

  Header. بما إن موقع المهاجم مش بيقدر يقرأ الـ Cookie بتاعة الموقع الضحية، فمش هيقدر يحطها في الـ

  Header بشكل صحيح.

الجزء العاشر: الحكم النهائي - هل ثغرة CSRF بتموت؟

السؤال ده مهم. بفضل الحماية المدمجة اللي بقت افتراضية في معظم أطر العمل (Frameworks) الحديثة زي Ruby on Rails, Django, Laravel، وبفضل التطبيق الواسع لخاصية SameSite=Lax كوضع افتراضي في المتصفحات،

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

لكن هل هي ميتة تمامًا؟ لأ، وللأسباب دي:

لسه فيه ملايين التطبيقات القديمة (Legacy Apps) اللي شغالة ومبنية من غير حماية افتراضية.
بعض المطورين ممكن يعطلوا الحماية دي عن طريق الخطأ.
هجمات CSRF لسه ممكنة في سيناريوهات معينة زي لو الـ Cookie متعلمة بـ SameSite=None (وده

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

فهمك للثغرة دي لسه مهارة لا تقدر بثمن، لأنها بتعلمك تفكر في "الثقة" كنقطة ضعف محتملة.

ثغرة CSRF هي درس عظيم في إن الأمان مش بس تشفير وحماية قواعد بيانات، لكنه كمان فهم عميق لإزاي البروتوكولات

والمتصفحات بتشتغل وإزاي ممكن يتم التحايل على "الثقة" اللي بينهم.

في دليلنا القادم، هنتعمق أكتر في هجمات من ناحية الخادم وهنتكلم عن ثغرات File Inclusion اللي ممكن تسمح للمهاجم بقراءة ملفات حساسة على السيرفر زي ملفات كلمات السر. استعد 😉

والآن دورك، شاركنا في التعليقات: إيه أكتر سيناريو هجومي لثغرة CSRF شايفه مقلق وممكن يأثر عليك شخصيًا؟

آخر الأخبار

شرح ثغرة CSRF بالتفصيل: كيف تخدع متصفح المستخدم؟ | دليل 2025







شرح ثغرة CSRF: الدليل الكامل لهجوم الخداع الخفي