حماية تعدد المدارس

هذه من أهم نقاط MARVX.

القواعد الصحيحة يجب أن تكون:

لا تقبل الصفحة school_id من GET أو POST لتحديد قاعدة البيانات.
المدرسة تُحدد فقط من Session الموثوقة.
init.php يقرأ المدرسة من marvx_auth.
كل مدرسة تتصل بقاعدة بياناتها فقط.
كل مستخدم MariaDB خاص بمدرسة يمتلك صلاحيات على قاعدة مدرسته فقط.
مستخدم echo_user المركزي يمتلك أقل صلاحيات ممكنة على marvx_auth.

الجزء الحالي في init.php جيد كأساس؛ لأنه يعيد قراءة المدرسة من القاعدة المركزية باستخدام current_school_id ثم يفتح قاعدة المدرسة المرتبطة بها.

لكن بيانات اتصال قواعد المدارس محفوظة حاليًا في الجدول المركزي، لذلك يجب تأمينها جيدًا وعدم عرضها في Logs أو رسائل الأخطاء.

الأشياء الأمنية الناقصة ذات الأولوية
أولوية حرجة
Rate Limiting لتسجيل الدخول

مثال:

5 محاولات خلال 10 دقائق
ثم قفل 15 دقيقة

ويكون العد حسب:

المدرسة + اسم المستخدم + IP
CSRF مركزي

كل طلب يقوم بـ:

إضافة
تعديل
حذف
اعتماد
استرجاع
صرف
تحصيل
ترحيل

يجب أن يحتوي CSRF Token.

بعض الملفات عندك تطبقه، لكن ليس موحدًا على النظام كله.

إعادة التحقق من المستخدم

init.php حاليًا يتأكد أن Session تحتوي:

school_user_id
school_role
current_school_id

لكنه لا يقرأ المستخدم من جدول users في كل صفحة إدارية. بالتالي إذا عُطل الحساب أثناء أن الجلسة مفتوحة، قد تستمر بعض الصفحات حتى انتهاء الجلسة.

الأصح وجود Auth Guard مركزي يعيد التحقق دوريًا من:

وجود المستخدم
is_active
status
account_type
role_key
entity_id

ليس بالضرورة في كل طلب بقاعدة البيانات؛ يمكن Cache قصير لمدة دقيقة أو دقيقتين.

Security Headers

يجب إرسالها مركزيًا من طبقة الأمان:

Strict-Transport-Security
X-Content-Type-Options: nosniff
Content-Security-Policy
Referrer-Policy
Permissions-Policy
frame-ancestors

وهذا يقلل:

XSS.
Clickjacking.
تحميل سكربتات غريبة.
تسريب روابط حساسة.
إزالة كلمات مرور قواعد البيانات من الكود

ملف:

/auth/config/auth_db.php

يجب أن يعتمد على Environment Variables فقط، وألا يحتوي كلمة مرور احتياطية حقيقية داخل الملف.

Audit Log مركزي

يجب تسجيل:

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

مع:

user_id
school_id
action
entity_type
entity_id
old_data
new_data
IP
user_agent
created_at
طبقة الأمان المركزية المقترحة

التركيب الصحيح سيكون:

/security/security_bootstrap.php
/security/session_manager.php
/security/auth_guard.php
/security/csrf.php
/security/rate_limiter.php
/security/security_headers.php
/security/audit_logger.php

ثم init.php يستدعي:

require_once BASE_PATH . '/security/security_bootstrap.php';

ويظل دور init.php:

تشغيل النظام
تحديد المدرسة
فتح الاتصال
استدعاء الأمان
تحميل الصلاحيات

ولا يصبح ملفًا ضخمًا يحتوي كل التفاصيل.

أخطر الأماكن التي يجب مراجعتها بعد ملفات الدخول

بعد تثبيت الملفات الخمسة، أكثر نقاط الهجوم المحتملة داخل النظام هي:

/dashboard/api/app/session_bridge.php
/uploads/
/admissions/
/auth/
/dashboard/school/*_ajax.php
ملفات رفع الصور والمستندات
استيراد Excel
طباعة وتصدير التقارير
استعادة كلمات المرور

وبالأخص رفع الملفات يجب أن يمنع:

.php
.phtml
.phar
.htaccess
الامتدادات المزدوجة
MIME المزور

مع أسماء عشوائية ومنع تنفيذ PHP داخل مجلدات الرفع.