جربنا نعمل مراجعة أمنية للكود بتاعنا بنفسنا بس اتعطلنا — إيه الفخاخ الشائعة؟

اضبط ميزة 'Taint analysis' (تتبع البيانات الملوثة) في أدوات الـ SAST كويس. راقب مدخلات المستخدم واتأكد بتتعقم فين قبل ما توصل لقاعدة البيانات أو أوامر النظام. لو قفلت القواعد الغبية اللي بتعتبر أي دمج نصوص (String concat) ثغرة SQL، هتلاقي تلتين التحذيرات اختفت فوراً.

إن جعل مبرمج لم يتلقَّ تدريبًا أمنيًا يراجع كوده بنفسه من الناحية الأمنية مجرد إجراء شكلي. فمن كتب الكود لا يستطيع رؤية خطأ التصميم في عمله. إذا كانت ميزانيتك ضيقة، فاستقدام تدقيق خارجي مركّز لمدة 2-3 أيام على وحدة المصادقة والدفع فقط بدلًا من النظام كله أرخص وأكثر فعالية بكثير.

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

في أول فحص تلقّينا 410 تحذيرات. وظللنا نتخبط مع الفريق أسبوعين. ثم ضبطنا فلتر الأمان على أخطر 10 ثغرات ويب فقط؛ فانخفض العدد فجأة إلى 19. ومن تلك النتائج الـ19 لم يكن يحمل خطرًا حقيقيًا سوى 4 فقط تستحق الإصلاح فعلًا.

أدوات الأتمتة لا تعرف ماذا يفعل الكود، هي فقط تطابق القوالب. إذا كنتم تستخدمون مكتبات ذات معاملات في استعلامات قاعدة البيانات فأنتم أصلًا تزيلون تلقائيًا معظم خطر sql injection، فلا تتوقفوا بلا داعٍ عند كل تحذير من الأداة.

في منتجنا الأول تناقشنا مع الفريق أيامًا حول قواعد تحقق معقدة بـ regex، وفرحنا لأننا أجرينا مراجعة كود آمنة. وفي اليوم الثالث بعد إطلاقنا للإنتاج، غيّر أحد العملاء قيمة id في معامل url وسحب الميزانية المالية لشركة أخرى. هذه بالضبط أخطاء المنطق التي لا تراها الأدوات.

هناك ثلاثة فخاخ كلاسيكية تقعون فيها: 1) اعتبار مخرجات الأداة صحيحة مطلقًا وإضاعة ساعات على تحذيرات كاذبة، 2) جعل المراجعة الأمنية تُفهم كأنها تقييم أداء للمطور فينشأ رد فعل دفاعي، 3) الخلط بين أسلوب الكود والثغرة الأمنية.

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

كنت أفكر في نفس الشيء. عندما نتخذ قرارات دون قياس، نعود لنفس النقطة دائماً.

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

حدث معي العكس تماماً، لذلك أكتب هذا. الأمان ليس مطلقاً؛ بل يعني جعل الهجوم غير مجدٍ من حيث الجهد.

بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

أوافق.

ملخص سريع للجدد: لا يتم التحقق من تغييرات معلومات الدفع أبداً عبر القناة الواردة منها.

الأمان ليس مطلقاً؛ بل يعني جعل الهجوم غير مجدٍ من حيث الجهد. بالتوفيق.

حدث معنا هذا. نسخة احتياطية غير مختبرة ليست نسخة احتياطية.

إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.

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

بالتوفيق.

أوافقك الرأي تمامًا. عند اتخاذ القرار، اكتب أسوأ سيناريو أيضًا، وليس الأفضل فقط.

اكتبوا إذا كانت لديكم أسئلة، سأجيب قدر استطاعتي.

سأجمع الموضوع، لأن هناك عدة إجابات مختلفة. الناس يدافعون عن العادات وليس العمليات. المقاومة تأتي من هناك.

أنا في نفس الوضع، لذلك أسأل ثم بصراحة إذا كانت هذه أول مرة، ابدأ صغيراً، والتوسع يأتي لاحقاً.

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

لا تتجاهل شيئاً: معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة.

ابدأ بتجربة صغيرة، لا تربط كل شيء دفعة واحدة... على كل حال بالتوفيق.