مع تطور تطبيقات الويب الحديثة وزيادة الاعتماد على الأنظمة الإلكترونية، أصبحت حماية المستخدمين والبيانات من الهجمات الأمنية أمراً أساسياً في أي مشروع برمجي.
ومن بين أكثر الهجمات شيوعاً وخطورة في تطبيقات الويب تأتي هجمات 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
* التحقق من الطلبات
بناء نظام آمن لا يعتمد على إجراء واحد فقط، بل على مجموعة من الممارسات الأمنية المتكاملة التي تعمل معاً لحماية التطبيق والمستخدمين.
التعليقات (0)
لا توجد تعليقات
اترك تعليق