CSRF في التطوير المحمول: ماهيته، أنواع الهجمات وطرق الحماية

ما هو هجوم CSRF؟

CSRF (Cross-Site Request Forgery) — هو هجوم حيث يقوم المهاجم بإنشاء طلب مزيف ويجبر متصفح الضحية على إرساله إلى الخادم المستهدف. ينفذ الخادم الطلب لأنه يتلقى بيانات اعتماد ملفات تعريف الارتباط صالحة من جلسة المستخدم الحالية. الهجوم ممكن لأن المتصفح يضيف تلقائياً ملفات تعريف الارتباط إلى كل طلب إلى النطاق المستهدف، بغض النظر عن الصفحة التي أُرسل منها الطلب. قد لا يرى المستخدم حتى صفحة المهاجم — يكفي تحميل <img> أو <form> أو <iframe> مخفي بعنوان URL ضار. CSRF لا يسرق البيانات مباشرة — الهجوم ينفذ إجراءات نيابة عن الضحية (عمليات تغيير الحالة)، مثل تحويل الأموال أو تغيير كلمة المرور أو حذف الحساب.

ما هي العمليات الأكثر عرضة للخطر؟

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

من هو المعرض للخطر؟

أي تطبيق ويب أو API حيث تعتمد المصادقة على ملفات تعريف الارتباط ولا يتحقق الخادم من مصدر الطلب يكون عرضة للخطر. التطبيقات المحمولة التي تستخدم WebView للمصادقة عبر نماذج الويب معرضة للخطر أيضاً: مكون المتصفح يرسل ملفات تعريف الارتباط تلقائياً، ويمكن للمهاجم حقن طلب ضار عبر التحميل في الخلفية. وفقاً لـ HackerOne (2025)، حوالي 12% من جميع تقارير الثغرات في تطبيقات الويب مرتبطة بعدم وجود حماية CSRF.

ما الذي يجعل CSRF خطيراً؟

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

كيف يعمل هجوم CSRF؟

يتطلب هجوم CSRF ثلاثة شروط: الضحية موثقة في الموقع المستهدف، الخادم يستخدم مصادقة ملفات تعريف الارتباط، وطلب المهاجم موجه إلى URL إجراء. يقوم المهاجم بإنشاء صفحة HTML تحتوي على نموذج أو script أو صورة يشير السمة src الخاصة بها إلى URL الهدف. يقوم متصفح الضحية بتحميل هذه الصفحة ويرسل تلقائياً طلباً إلى الخادم مع ملف تعريف ارتباط الجلسة الحالية. يتلقى الخادم ملفات تعريف ارتباط صالحة، ولا يتحقق من مصدر الطلب، وينفذ العملية.

<!-- مثال على هجوم CSRF عبر نموذج مخفي -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

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

دور المتصفح في CSRF

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

الأنواع الرئيسية لهجمات CSRF

تصنف هجمات CSRF حسب طريقة توصيل الطلب الضار. كل نوع يستخدم عنصر HTML مختلفاً لإرسال الطلب، لكن جميعها تعتمد على الإرسال التلقائي لملفات تعريف الارتباط بواسطة المتصفح. يعتمد اختيار الطريقة على أهداف المهاجم: هجمات GET-based تتطلب كوداً أقل، وهجمات POST-based تتجاوز بعض الدفاعات بشكل أكثر موثوقية، وهجمات XMLHttpRequest-based تسمح بالتلاعب بالرؤوس.

CSRF GET-based

أبسط طريقة: يضع المهاجم <img> على صفحة بعنوان URL يحتوي على معايير الطلب. يقوم المتصفح بتحميل الصورة ويرسل طلب GET إلى الخادم. على سبيل المثال، <img src="https://api.example.com/delete?postId=123" /> يحذف سجلاً إذا كان الخادم يعالج DELETE عبر GET. على الرغم من الخطر الواضح، لا تزال بعض واجهات API تستخدم GET لعمليات الحذف أو التحديث.

CSRF POST-based

إذا كان الخادم يقبل طلبات POST فقط، يقوم المهاجم بإنشاء نموذج مخفي بطريقة POST ويرسله تلقائياً عبر JavaScript. لا يظهر النموذج على الشاشة (جميع <input> لها type="hidden")، و autofocus + .submit() يعمل دون نقرة المستخدم. هجمات POST-based لا تعمل إذا كان الخادم يتحقق من رأس Content-Type، لكن معظم واجهات API تقبل application/x-www-form-urlencoded القياسي.

CSRF XHR-based (مع CORS)

XMLHttpRequest أو Fetch API تسمح بإرسال طلبات برؤوس مخصصة. إذا كان الخادم قد ضبط CORS بشكل واسع جداً (Access-Control-Allow-Origin: *)، يمكن للمهاجم إرسال أي طلب وقراءة الاستجابة. ومع ذلك، لهجوم CSRF ليست قراءة الاستجابة ضرورية — يكفي تنفيذ الإجراء. ترسل المتصفحات الحديثة طلب preflight OPTIONS قبل الطلبات غير القياسية، مما قد يمنع CSRF XHR-based إذا كان الخادم مهيئاً بشكل صحيح.

CSRF في التطبيقات المحمولة

التطبيقات المحمولة أقل عرضة لـ CSRF من مواقع الويب لأن التطبيقات الأصلية نادراً ما تستخدم مصادقة ملفات تعريف الارتباط. بدلاً من ذلك، تستخدم واجهات API المحمولة في الغالب رموزاً في رأس Authorization (رموز Bearer، JWT). ومع ذلك، هناك سيناريوهات يكون فيها هجوم CSRF ممكناً: WebView مع تسجيل الدخول عبر الويب، التطبيقات الهجينة، وAPI مع جلسات قائمة على ملفات تعريف الارتباط. وفقاً لـ TechCrunch (2025)، حوالي 18% من واجهات API العامة لتطبيقات المحمول لا تزال تدعم ملفات تعريف ارتباط الجلسة.

CSRF عبر WebView

تفتح العديد من التطبيقات صفحات الويب في WebView — تفويض OAuth، نماذج الدفع، عرض المحتوى. WebView هو متصفح كامل داخل التطبيق يخزن ملفات تعريف ارتباط الجلسة. إذا وجد المهاجم طريقة لتحميل عنوان URL الخاص به في WebView (عبر إعادة توجيه مفتوحة أو Deep Link)، يمكنه تنفيذ هجوم CSRF تماماً كما في المتصفح العادي. الحماية — استخدام Chrome Custom Tabs أو SFSafariViewController بدلاً من WebView للعمليات الحرجة.

CSRF في API مع مصادقة JWT

رموز JWT تُخزن عادة في localStorage أو في ذاكرة التطبيق ولا تُرسل تلقائياً — يضيف المطور رأس Authorization صراحةً إلى كل طلب. هذا يجعل هجوم CSRF الكلاسيكي مستحيلاً. ومع ذلك، إذا كان التطبيق يخزن JWT في ملف تعريف ارتباط (نادر لكن ممكن)، يعود الخطر. حماية إضافية — ربط JWT بأصل طلب محدد عبر claim azp أو aud، مما يمنع استخدام الرمز على نطاق مختلف.

// مثال على التحقق من رمز CSRF من جانب الخادم في Express
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// توليد رمز CSRF عند تسجيل الدخول
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

طرق الحماية من CSRF

الحماية الحديثة من CSRF تُبنى على ثلاثة مستويات: رموز CSRF من جانب الخادم، سمة SameSite لملفات تعريف الارتباط، والتحقق من رأس Origin. مجموعة هذه الطرق توفر حماية من 99% من هجمات CSRF دون تأثير كبير على تجربة المستخدم. يعتمد اختيار النهج على بنية التطبيق: موقع الويب قد يحتاج فقط SameSite=Lax، بينما API تطبيق محمول يتطلب رموزاً في الرؤوس.

رموز CSRF (المزامن)

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

SameSite Cookie

السمة SameSite لملفات تعريف الارتباط تحد من إرسالها في الطلبات عبر النطاقات. القيمة Lax تسمح بإرسال ملفات تعريف الارتباط فقط لطلبات GET للملاحة من المستوى الأعلى — وهذا كافٍ لمعظم المواقع. Strict تحظر ملفات تعريف الارتباط لجميع الطلبات عبر النطاقات، بما في ذلك الملاحة: سيضطر المستخدم إلى إعادة المصادقة عند القدوم من موقع آخر. وفقاً لـ Chrome Platform Status (2026)، SameSite=Lax مفعل افتراضياً في جميع المتصفحات الحديثة، مما قلل عدد هجمات CSRF بنسبة 67%.

التحقق من Origin وReferer

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

// مثال على التحقق من رمز CSRF في Spring Boot
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

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

• رموز CSRF — المعيار الذهبي: موثوقة، مثبتة عبر الزمن، مدعومة من جميع الأطر
• SameSite=Lax — حماية أدنى لتطبيقات الويب: مجانية، تلقائية، لا تتطلب كوداً
• التحقق من Origin — طبقة إضافية: تمنع الهجمات قبل التحقق من الرمز
• Double Submit — لـ REST API بدون جلسات من جانب الخادم: فعال عبر HTTPS
• الرؤوس المخصصة — X-Requested-With: XMLHttpRequest تمنع نماذج CSRF البسيطة

الفرق بين CSRF وXSS

CSRF وXSS نوعان مختلفان من الهجمات التي غالباً ما يتم الخلط بينهما. CSRF يستغل ثقة الخادم في متصفح المستخدم: ينفذ الخادم أمر المهاجم لأن الطلب يصل مع ملفات تعريف ارتباط صالحة. XSS يستغل ثقة المتصفح في محتوى الخادم: ينفذ المتصفح script حقنه المهاجم في الصفحة. CSRF لا يتطلب حقن كود في الموقع المستهدف — يكفي إرسال طلب من نطاق آخر. XSS، على العكس، يتطلب إيجاد طريقة لحقن JavaScript في كود HTML للصفحة. ومع ذلك، يمكن لـ XSS تجاوز حماية CSRF: يقرأ البرنامج النصي المحقون رمز CSRF من الصفحة ويرسله مع الطلب.

فهم الفرق بين CSRF وXSS أمر بالغ الأهمية لبناء حماية متعددة الطبقات. رموز CSRF لا تحمي من XSS، وCSP (Content Security Policy) لا تحمي من CSRF. فقط مجموعة من الطرق تضمن أمن التطبيق من كلا النوعين من الهجمات. في التطبيقات المحمولة مع WebView، تتضاعف المخاطر، لذلك يُوصى للمطورين بتطبيق رموز CSRF على الأقل لطلبات API و Content Security Policy للمحتوى الويب.