تقنيات مراجعة الشيفرة الآمنة

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

تكتشف أدوات SAST الآلية (Semgrep وSonarQube وCodeQL) الأنماط المعروفة بسرعة، لكنها قد تفوّت عيوب منطق الأعمال، والثغرات المعقدة متعددة المكونات، والمشكلات المعتمدة على السياق. أما المراجعة اليدوية فتكتشف ما تفوّته الأتمتة. وكلاهما ضروري.

ابدؤوا المراجعة الأمنية برسم خريطة لجميع نقاط الدخول: نقاط نهاية HTTP، ومعالجات قوائم الرسائل، وعمليات رفع الملفات، والمهام المجدولة، وخطافات الويب، ومعاملات CLI. كل نقطة دخول تقبل بيانات خارجية هي نقطة حقن محتملة تتطلب التدقيق.

تتبّعوا البيانات التي يتحكم فيها المستخدم من نقطة دخولها، مرورًا بالتطبيق، وصولًا إلى استخدامها النهائي. هل تصل إلى استعلام قاعدة بيانات؟ أم إلى أمر shell؟ أم إلى قالب HTML؟ أم إلى استدعاء API؟ اتبعوا تدفق البيانات وتحققوا من كل خطوة تحويل وتعقيم.

تحدث القرارات الأمنية عند حدود الثقة، أي حيث تنتقل البيانات من سياق أقل ثقة (طلب HTTP) إلى سياق أكثر ثقة (قاعدة البيانات أو نظام التشغيل). يجب التحقق من البيانات أو تعقيمها أو التصريح بها عند كل عبور لحدود الثقة.

ضعوا علامة على استخدام: eval() وexec() وsystem() وshell_exec() وinnerHTML وdangerouslySetInnerHTML وdeserialize() وpickle.loads() وRuntime.exec() وProcessBuilder، ومحللات XML التي لم يُعطَّل فيها توسيع الكيانات، والأوليات التشفيرية المستخدمة مباشرةً بدلًا من واجهات برمجة التطبيقات عالية المستوى.

تحققوا مما يلي: هل كل نقطة نهاية حساسة محمية بالمصادقة؟ هل يجري التحقق من التخويل من جانب الخادم لكل إجراء؟ هل يستطيع مستخدم الوصول إلى بيانات مستخدم آخر عبر تغيير معامل المعرّف (IDOR)؟ هل العمليات الحساسة محمية من CSRF؟

ابحثوا عن كتل catch التي تبتلع الاستثناءات بصمت. تحققوا من أن رسائل الخطأ المعروضة للمستخدمين لا تكشف المسارات الداخلية أو تتبعات المكدس أو بنية قاعدة البيانات. وتحققوا من تسجيل الاستثناءات الأمنية (AuthenticationException) وعدم تجاهلها بهدوء.

ضعوا علامة على ما يلي: استخدام MD5 أو SHA-1 لتجزئة كلمات المرور (استخدموا bcrypt أو Argon2)، والمفاتيح المتماثلة أو متجهات التهيئة المضمّنة في الشيفرة، وتشفير نمط ECB (استخدموا GCM أو CBC مع HMAC)، وتنفيذات التشفير المخصصة، ومولدات الأرقام العشوائية غير الآمنة تشفيريًا.

راجعوا package.json/pom.xml بحثًا عن التبعيات القديمة. وتحققوا من إعدادات التطبيق للتأكد من تعطيل وضع التصحيح في الإنتاج، وعدم عرض صفحات أخطاء مفصلة، وعدم وجود بيانات اعتماد المسؤول في ملفات الإعداد، وعدم غياب ترويسات الأمان (HSTS وCSP وX-Frame-Options).

تطابق قواعد Semgrep أنماط البنية النحوية مع وعي دلالي. اكتبوا قواعد مخصصة للأنماط الخاصة بقاعدة شيفرتكم. ويتعامل CodeQL مع الشيفرة باعتبارها بيانات؛ فاكتبوا استعلامات على AST للعثور على تدفقات البيانات من المصادر إلى المصارف عبر الملفات واستدعاءات الدوال.

ما ثغرة IDOR، وأين تبحثون عنها في مراجعة الشيفرة؟

تجمع مراجعة الشيفرة الآمنة الفعالة بين رسم خريطة نقاط الدخول، وتتبع تدفق البيانات، وتحليل حدود الثقة، واكتشاف واجهات برمجة التطبيقات الخطرة، وأدوات SAST الآلية. وهي تكتشف مشكلات أمنية تفوّتها المراجعة الوظيفية، ولا سيما عيوب منطق الأعمال وثغرات التخويل الدقيقة.