مراجعة الشيفرة الأمنية مشروحة: ما الذي يبحث عنه المراجع في الفرق، ولماذا

مراجعة الكود الأمنية هي القراءة المتعمدة للشيفرة المصدرية بهدف محدد هو العثور على الطرق التي يمكن بها جعلها تفعل شيئًا لم يقصده مؤلفها. تبدو هذا التعريف بديهيًا حتى تقارنه بما تشغّله معظم الفرق فعليًا، وهو مراجعة وظيفية مع وجود قائمة تحقق أمنية قريبة. يوضح OWASP Secure Code Review Cheat Sheet الحد الفاصل بدقة: تختلف المراجعة الأمنية عن المراجعة الوظيفية باستهدافها التحقق من المدخلات والمصادقة والتفويض وتنفيذ التشفير ومتجهات الهجوم، بدلًا من الصحة الوظيفية. قد يمنح فرق (diff) يعمل بشكل مثالي nevertheless المهاجم مسارًا إلى النظام، وواحدة فقط من هاتين المراجعتين تبحث عنه.

ما يجعل الموضوع يستحق مقالًا الآن بدلًا من عام 2020 هو أن نموذجًا لغويًا يستطيع قراءة فرق برمجي بكفاءة وبتكلفة زهيدة وبشكل مستمر — وهذا يغيّر اقتصاديات المراجعة دون أن يغيّر أي بُعد من الأبعاد التي تُراجَع. القائمة المرجعية أقدم من النماذج ولم تتغيّر. ما تغيّر هو عدد المرات التي يمكنك أن تتحمّل تكلفة تشغيلها فيها.

ما الذي يبحث عنه المراجِع فعليًا عند القراءة

تُنظّم ورقة إرشادات OWASP العمل في ستة مجالات، والجانب المفيد في القائمة هو أنّ كل مجال يمثّل سؤالًا لا فئة. فالفئات تُغري بوضع علامات في المربعات؛ أما الأسئلة فتُنتج نتائج.

المدخلات والحقن. السؤال ليس ما إذا كان الكود يحتوي على أداة تعقيم؛ بل ما إذا كان أي شيء يصل إلى مفسّر — shell أو SQL أو محرك قوالب أو مُقيّم تعبيرات — وفي أي طبقة يُفترض أن يُفرض هذا الشرط. التغيير الذي يضيف استعلامًا مُعامَلًا جيد؛ أما التغيير الذي يضيف استعلامًا مُعامَلًا إلى دالة يمرر مستدعوها الآخرون سلاسل خامًا إليها فهو تغيير نقل المشكلة.

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

التفويض. فحوصات على مستوى الكائن، في كل مرة، وعلى كل مسار. الشيء المحدد الذي يجب البحث عنه في دفعة التغييرات (diff) هو مسار جديد لا يرث الحماية التي تمتلكها المسارات الشقيقة، لأن البرمجيات الوسيطة تُسجَّل لكل موجِّه على حدة، والمسار المضاف تحت موجِّه مختلف لن يكون مغطًى ببساطة.

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

منطق الأعمال. ما إذا كان يمكن إعادة ترتيب التسلسل أو إعادة تشغيله أو توجيهه بقيم اختارها العميل. أي سعر أو كمية أو دور أو انتقال حالة يصل من العميل ولا يُعاد اشتقاقه على جانب الخادم يُعد نتيجة/ثغرة بغض النظر عن طريقة التحقق منه.

الإعدادات والأسرار. ما الذي يُدخله هذا الفرق (diff) إلى المستودع وكان ينبغي ألا يكون فيه أصلًا، وما إذا كانت القيم الافتراضية آمنة في المكان الذي تُشغَّل فيه الشيفرة فعليًا. علم التنقيح (debug) الذي تكون قيمته الافتراضية true هو ملاحظة تخص بيئة الإنتاج، لا ملاحظة عن العلم نفسه.

مراجعة خط الأساس مقابل مراجعة الفروق

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

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

التقنيات، وما تكتشفه كل واحدة منها

تسرد OWASP أربع تقنيات للمراجعة، وهي تتميز بنوع الأدلة التي يتتبعها المراجع لا بمدى شموليتها. تحليل أنماط الشيفرة يتبع أشكالًا مألوفة: استدعاء الدالة الخطِرة، وإلغاء تسلسل مدخلات غير موثوقة، وغياب فحص الطول. وهو سريع، وهو تحديدًا ما تجيده الأداة الحتمية. تحليل تدفق البيانات يتتبع قيمة من نقطة دخولها إلى موضع استخدامها، وهي الطريقة الوحيدة للإجابة عمّا إذا كان المُطهِّر المطبَّق قبل ثلاث دوال لا يزال ساريًا هنا. مراجعة قائمة على التهديد تبدأ من قدرة المهاجم وتتقدم إلى الأمام، وهكذا تلتقط الفجوة بين مكوّنين صحيحين كل على حدة. مراجعة منطق الأعمال تقرأ سير العمل لا الأسطر، فتسأل عن تسلسل العمليات المشروعة الذي يُنتج حالة غير مشروعة.

فقط الأول من هؤلاء الأربعة تخدمه أداة فحص جيدًا، وفقط الأول والثاني تخدمهما جيدًا تمريرة نموذج غير موجّهة. وهذا ليس حجة ضد النماذج؛ بل هو حجة لصالح إخبار المراجع بأي تقنية تريد، لأن المطالبة التي تطلب «مشكلات أمنية» ستُنتج تحليل أنماط بشكل موثوق ثم تتوقف.

ما الذي غيّره الذكاء الاصطناعي، وما الذي لم يغيّره

جعلت الأبحاث حول الشيفرة المؤلّفة بواسطة الذكاء الاصطناعي عنق زجاجة المراجعة أكثر حدة بدلاً من أن تخلقه. فقد وجدت دراسة NYU لاقتراحات GitHub Copilot، المنشورة في IEEE S&P عام 2022، أن نحو 40% من المقتطفات المولّدة احتوت على نمط قابل للاستغلال عبر 18 فئة من CWE. ووجد عمل Stanford حول سلوك المطورين، المنشور في ACM CCS عام 2023، التأثير الأكثر أهمية: كان المطورون الذين يستخدمون المساعدين أكثر ثقة بأن شيفرتهم آمنة بينما ينتجون شيفرة أقل أمانًا بشكل قابل للقياس. زيادة المخرجات مع زيادة الثقة تشكّل مشكلة في المراجعة.

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

OrcaCode Review هي الصيغة المنتَجة تجاريًا لتلك الفكرة، ويستحق النظر إليه عن كثب لأن خيارات التصميم تكشف أنماط الفشل. فالمراجعة التي تعزل حالة الفشل كتعليق محدد قابل لإعادة الإنتاج — هذا المفتاح لا يزال يتغير بمرور الوقت، لذا فإن إعادة محاولة تحصيل رسوم تُنشئ مفتاحًا جديدًا وقد تؤدي إلى تحصيل مزدوج، وهذا هو التغيير ذو السطر الواحد — تؤدي العمل الذي يؤديه المراجع. أما المراجعة التي تبلغ عن "مشكلة أمنية محتملة" دون إعادة إنتاج، فهي تقوم بتحليل الأنماط بدقة أقل من مطابق الأنماط. كما أن محرك القواعد والبوابات المنشور بموجب ترخيص مفتوح يقدم ادعاءً ضمنيًا يستحق التحقق: أن حكم المراجع ينبغي أن يكون قابلًا للمراجعة أيضًا.

الترتيب ثنائي الطبقات الذي ينجح

بوجود ماسح حتمي ومراجع احتمالي، فإن الترتيب الذي يصمد عمليًا هو أن يُسند إلى كل منهما العمل الذي يجيده فعلًا. يعمل الماسح عند كل عملية push: ثوانٍ، بلا نموذج، وبلا تفاوت، فيلتقط الأسرار واستدعاءات API الخطرة وإلغاء التسلسل غير الآمن والاستيرادات المتوهمة. ويعمل المراجع عند كل طلب سحب (pull request): دقائق، ومدعوم بنموذج، فيلتقط المنطق بين السطور — هل يجري فحص التفويض قبل الجلب، وهل مفتاح الـ idempotency مرتبط بقيمة مستقرة، وهل ورث المسار الجديد الحارس.

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

مراجعة التغيير، لا قاعدة الشيفرة

الانضباط العملي لمراجعة الفروق (diff review) هو تسلسل قصير، وقيمته أنه يمكن تعليمه في أمسية واحدة. اقرأ الفرق من أجل ما يضيفه إلى سطح الهجوم لا من أجل ما يغيّره. لكل نقطة دخول جديدة، تتبّع المدخل خطوة واحدة بعد المكان الذي ينتهي فيه الفرق — فالثغرة تكون عادةً في الدالة التي يستدعيها، والتي لم يقرأها المؤلف. ولكل مسار جديد، تحقّق من تسجيل الحارس. ولكل تبعية جديدة، تحقّق مما إذا كانت موجودة وما إذا كان شخص آخر قد نشر الاسم. ولكل قيمة إعداد جديدة، اسأل عمّا ستكون عليه افتراضيًا في المكان الذي ستُنشر فيه فعليًا.

لا شيء من ذلك يتطلب معرفة جيدة باللغة، ولهذا يمكن توسيعه ليشمل مراجعين ليسوا متخصصين في الأمن. لكنه يتطلب أن يرى المراجع الفرق (diff) وليس الملف، لأن الطريقة كلها تعتمد على معرفة ما هو جديد.

والحدّ الصادق: لا تستطيع مراجعة الفروقات العثور على العيب الذي كان موجودًا قبل الفروقات. وإذا لم يخضع التطبيق قط لمراجعة أساسية، فإن أعلى عمل أمني قيمةً متاح ليس مراجعًا أفضل — بل تمريرة واحدة متعمّدة على قاعدة الشيفرة، في المجالات التي تمس المال والهوية والوصول إلى الملفات، بالأسئلة الستة أعلاه. بعد ذلك، كل مراجعة فروقات لاحقة تحمي شيئًا سبقت مراجعته مرة واحدة. وقبلها، كل مراجعة فروقات تحمي شيئًا مجهولًا.