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

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

العديد من المواقع والأنظمة الحديثة تعتمد على تسجيل الدخول والجلسات Sessions، وهذا ما يجعل الحماية من CSRF ضرورة حقيقية خصوصاً في:

* لوحات التحكم
* الأنظمة الإدارية
* المتاجر الإلكترونية
* الأنظمة البنكية
* مواقع العضويات
* تطبيقات MVC
* واجهات API

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

---

# ما هو CSRF؟

CSRF اختصار لـ:

Cross-Site Request Forgery

ويعني:
تزوير الطلبات عبر المواقع.

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

---

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

عندما يسجل المستخدم دخوله إلى موقع ما، يتم حفظ جلسة Session أو Cookie داخل المتصفح.

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

وبما أن المتصفح يرسل الـ Cookies تلقائياً، قد يعتقد الموقع أن الطلب شرعي.

---

# مثال بسيط على هجوم CSRF

لنفترض وجود نموذج لتحويل الأموال:

```html
<form action="https://example.com/transfer" method="POST">
<input type="hidden" name="amount" value="1000">
<input type="hidden" name="to" value="attacker">
</form>
```

إذا كان المستخدم مسجل الدخول بالفعل، فقد يتم تنفيذ العملية تلقائياً.

---

# لماذا تعتبر هجمات CSRF خطيرة؟

قد تسمح للمهاجم بتنفيذ عمليات حساسة مثل:

* تغيير كلمة المرور
* حذف البيانات
* تعديل الحسابات
* تنفيذ عمليات مالية
* إنشاء مستخدمين جدد
* تغيير البريد الإلكتروني

كل ذلك باسم الضحية.

---

# الفرق بين CSRF و XSS

الكثير يخلط بين الهجومين.

---

# XSS

يعتمد على حقن JavaScript داخل الموقع.

---

# CSRF

يعتمد على استغلال ثقة الموقع بالمستخدم المسجل دخوله.

---

# متى يكون التطبيق معرضاً لـ CSRF؟

يصبح التطبيق معرضاً للخطر عندما:

* يعتمد على Cookies للجلسات
* لا يتحقق من مصدر الطلب
* لا يستخدم CSRF Tokens
* يسمح بتنفيذ عمليات حساسة عبر POST بدون حماية

---

# ما هو CSRF Token؟

هو رمز عشوائي يتم إنشاؤه لكل جلسة أو لكل نموذج.

يقوم السيرفر بالتحقق منه قبل تنفيذ أي عملية حساسة.

---

# لماذا تعتبر الـ Tokens فعالة؟

لأن المهاجم لا يستطيع معرفة قيمة الرمز المخزن داخل جلسة المستخدم.

---

# إنشاء CSRF Token في PHP

مثال بسيط:

```php
if (empty($_SESSION['csrf'])) {
   $_SESSION['csrf'] = bin2hex(random_bytes(32));
}
```

---

# إضافة الـ Token داخل النموذج

```php
<input type="hidden"
      name="csrf_token"
      value="<?= $_SESSION['csrf'] ?>">
```

---

# التحقق من الـ Token

```php
if (
   !isset($_POST['csrf_token']) ||
   $_POST['csrf_token'] !== $_SESSION['csrf']
) {
   die('Invalid CSRF token');
}
```

---

# أفضل الممارسات عند استخدام CSRF Tokens

# 1. استخدام رموز عشوائية قوية

يفضل استخدام:

```php
random_bytes()
```

بدلاً من الطرق القديمة.

---

# 2. إنشاء Token لكل جلسة أو طلب

بعض الأنظمة تستخدم:

* Token ثابت للجلسة
* Token جديد لكل نموذج

الطريقة الثانية أكثر أماناً.

---

# 3. انتهاء صلاحية الـ Token

يفضل عدم بقاء الرمز صالحاً لفترات طويلة.

---

# 4. عدم تخزين الـ Token داخل JavaScript بشكل مكشوف

لتقليل مخاطر XSS.

---

# 5. حماية جميع العمليات الحساسة

مثل:

* الحذف
* التعديل
* الدفع
* تغيير الإعدادات

---

# أهمية استخدام POST بدلاً من GET

العمليات الحساسة لا يجب تنفيذها عبر GET.

---

# مثال خاطئ

```html
<a href="/delete/5">Delete</a>
```

---

# الأفضل

استخدام نموذج POST:

```html
<form method="POST">
<button>Delete</button>
</form>
```

---

# حماية روابط الحذف داخل لوحات التحكم

الكثير من المطورين ينسون حماية عمليات الحذف.

---

# مثال آمن

```php
<form method="POST"
     action="/admin/posts/delete/5">

<input type="hidden"
      name="csrf_token"
      value="<?= $_SESSION['csrf'] ?>">

<button type="submit">
Delete
</button>

</form>
```

---

# SameSite Cookies ودورها في الحماية

المتصفحات الحديثة تدعم خاصية SameSite.

---

# ماذا تفعل؟

تقلل إرسال Cookies عبر الطلبات الخارجية.

---

# الإعداد الموصى به

```php
session_set_cookie_params([
   'samesite' => 'Strict'
]);
```

---

# أنواع SameSite

## Strict

أكثر أماناً.

---

## Lax

توازن بين الأمان والتوافق.

---

## None

يسمح بالإرسال عبر المواقع ويتطلب HTTPS.

---

# أهمية التحقق من Referer و Origin

بعض الأنظمة تتحقق من:

* Origin Header
* Referer Header

للتأكد من أن الطلب جاء من نفس الموقع.

---

# هل تكفي هذه الطريقة وحدها؟

لا.

لأن بعض المتصفحات أو الشبكات قد لا ترسل هذه القيم دائماً.

---

# الحماية في تطبيقات AJAX

عند استخدام AJAX يجب إرسال CSRF Token مع كل طلب.

---

# مثال باستخدام Fetch API

```javascript
fetch('/save', {
   method: 'POST',
   headers: {
       'X-CSRF-TOKEN': csrfToken
   }
});
```

---

# التحقق داخل PHP

```php
$token = $_SERVER['HTTP_X_CSRF_TOKEN'] ?? '';
```

---

# CSRF في أنظمة MVC

أنظمة MVC الحديثة غالباً توفر حماية مدمجة.

---

# أمثلة

## Laravel

يوفر حماية تلقائية.

Laravel

---

# مثال Blade

```php
@csrf
```

---

## Symfony

يوفر نظام حماية قوي للنماذج.

Symfony

---

# CSRF في واجهات API

واجهات API التي تعتمد على Tokens بدلاً من Cookies تكون أقل عرضة لـ CSRF.

---

# لماذا؟

لأن المتصفح لا يرسل الـ Authorization Tokens تلقائياً مثل Cookies.

---

# هل تحتاج APIs إلى حماية CSRF؟

إذا كانت تعتمد على:

* Session Cookies
* Authentication Cookies

فالإجابة نعم.

---

# الأخطاء الشائعة في الحماية من CSRF

# 1. استخدام Token ثابت جداً

---

# 2. عدم التحقق من الـ Token

---

# 3. حماية بعض النماذج فقط

---

# 4. استخدام GET للعمليات الحساسة

---

# 5. كشف الـ Token داخل JavaScript بدون حماية

---

# أهمية اختبار الحماية

الحماية يجب اختبارها باستمرار.

---

# طرق الاختبار

## محاولة إرسال طلب بدون Token

---

## استخدام أدوات الاختبار الأمنية

---

## اختبار الجلسات والمتصفحات المختلفة

---

# أدوات تساعد في اختبار الأمان

## OWASP ZAP

أداة مفتوحة المصدر لاختبار تطبيقات الويب.

OWASP ZAP

---

## Burp Suite

من أشهر أدوات اختبار الاختراق.

Burp Suite

---

# العلاقة بين CSRF و XSS

إذا كان التطبيق يحتوي على XSS فقد يستطيع المهاجم سرقة CSRF Tokens.

لذلك:
الحماية من XSS و CSRF يجب أن تعمل معاً.

---

# كيف تبني نظام حماية متكامل؟

## استخدام CSRF Tokens

---

## حماية الجلسات

---

## استخدام SameSite Cookies

---

## التحقق من Origin

---

## منع XSS

---

## استخدام HTTPS

---

# أهمية HTTPS في الحماية

HTTPS يمنع اعتراض البيانات أثناء النقل.

كما يحسن أمان:

* الجلسات
* Cookies
* Tokens

---

# مستقبل الحماية من CSRF

المتصفحات الحديثة بدأت تضيف تقنيات حماية إضافية، لكن مسؤولية الحماية الأساسية ما زالت تقع على المطورين.

التطبيقات الحديثة تحتاج إلى:

* حماية متعددة الطبقات
* مراجعات أمنية دورية
* تحديثات مستمرة

---

# الخلاصة

هجمات CSRF تعتبر من أخطر الهجمات التي قد تستغل ثقة المواقع بالمستخدمين المسجلين دخولهم.

الحماية الصحيحة تعتمد على:

* استخدام CSRF Tokens
* حماية الجلسات
* استخدام POST للعمليات الحساسة
* تفعيل SameSite Cookies
* التحقق من الطلبات

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