اكتشاف الذكاء الاصطناعي لمخاطر الإنفاق المزدوج في TOCTOU
ظروف سباق وقت التحقق من وقت الاستخدام هي فئة من أخطاء التوقيت التي تسد الفجوة بين نقطة قرار النظام ولحظة اتخاذ هذا القرار. في تدفقات مدفوعات البلوك تشين يمكن أن تكون هذه الفجوة هي الفرق بين عملية شراء واحدة صالحة و عملية إنفاق مزدوجة. عندما يقرأ الرمز البرمجي الرصيد، ثم يطبق عملية شراء لاحقًا، يمكن للمهاجم الذي يمكنه تقديم معاملات شبه متزامنة أو استغلال إعادة الترتيب أن يجعل عملية التحقق تنجح مرتين بينما يحدث تحديث الحالة مرة واحدة فقط. هذا هو لبّ مشكلة الإنفاق المزدوج TOCTOUU.
كيف يعمل بنليجنت
لا يعتمد نهج Penligent في العثور على هذه المشكلات على التخمين. فهو يبدأ بأنماط التحليل الثابتة التي تشير إلى تعابير "التحقق ثم التصرف" - وهي عبارة عن أسطر من التعليمات البرمجية حيث تتم قراءة الرصيد أو الاستحقاق ثم تقوم الكتابة اللاحقة بتحديث عداد الاستحقاق. تتلقى هذه المواقع التي تم وضع علامة عليها سياقًا: الرسم البياني لاستدعاء مسار التعليمات البرمجية، ونقطة نهاية الشبكة التي تستدعيها، والافتراضات البيئية التي تقوم بها (على سبيل المثال، "يفترض تحديثات أحادية الخيط" أو "يفترض تأكيدات الحظر قبل الخطوة التالية"). من خلال هذا السياق، يقوم Penligent بتشغيل التحقق المضبوط: اختبارات غير مدمرة ضد نقاط نهاية التدريج، والارتباط مع آثار المعاملات عند توفرها، واختبارات التزامن المستهدفة التي تختبر السلوك في ظل عمليات الإرسال شبه المتزامنة.
بشكل ملموس، قد يبدو التدفق الضعيف كما يلي في الإنتاج: يتحقق التطبيق من الرصيد[عنوان_المتجر] == 1_000_000_000 ثم يزيد عدد الماس للمشتري. يقوم أحد المهاجمين بإرسال معاملتي DDCoin بقيمة 1,000,000 DDCoin تصل ضمن النافذة بين الشيك وتغيير الحالة الفعالة. ونظرًا لأن الشيك يعمل قبل إجراء أي من المعاملتين، فإن كلا الشيكين يجتازان، ويكتسب المستخدم ماستين بينما ينفق وحدة واحدة فقط من الأصل. يجمع Penligent الأدلة من خلال جمع آثار الطلب/الاستجابة، ومعرّفات المعاملات، والطوابع الزمنية للكتل، وأي آثار سباق يمكن ملاحظتها، ثم يربطها بموقع الكود الثابت الذي يقوم بإجراء الفحص.
كيفية إصلاح TOCOTOU
عادةً ما يعني إصلاح TOCTOUU في سياقات البلوك تشين جعل التحقق من الرصيد وتغيير الحالة ذريًا. في الدعامات التقليدية، هذا يعني معاملات قاعدة البيانات مع مستويات عزل قوية وكتم الصوت أو مخططات التزامن المتفائلة مع إعادة المحاولة. أما في العقود الذكية، فهذا يعني تصميم العقد بحيث يتم تنفيذ انتقالات الحالة في معاملة واحدة، أو استخدام آليات مثل nonces وأرقام التسلسل الصريحة لكل حساب لمنع إعادة التشغيل أو العمليات المكررة. يُظهر الرمز الزائف الآمن التالي النمط الدفاعي، مع التركيز على الذرية والصحة بدلاً من قابلية الهجوم:
# كود زائف دفاعي: تحديث ذري داخل معاملة قابلة للتسلسل
مع معاملة db.transaction(العزل="قابل للتسلسل"):
إذا كان الرصيد[shop_address] >= PRICE:
الرصيد[عنوان_المتجر] -= السعر
الجلسة["ألماساتك"] += 1
غير ذلك:
رفع خطأ عدم كفاية الرصيد غير كافٍ()
من الناحية التشغيلية، تساعد التدابير الإضافية في: اشتراط وجود عدادات غير متزامنة أو رتيبة في عمليات إرسال المعاملات، والحفاظ على ترتيب صارم للعمليات في بوابة واجهة برمجة التطبيقات، وأداة التتبع الكامل بحيث يمكن إعادة بناء أنماط الإرسال المتزامن. كما يمكن للحد من المعدل والتجميع أن يقلل من النافذة العملية التي يمكن فيها استغلال التزامن.
من من منظور الكشف، تكمن قيمة Penligent الحقيقية في دمج الإشارات. فالمؤشرات الثابتة وحدها تولد العديد من النتائج الإيجابية الخاطئة؛ حيث تفتقر مؤشرات وقت التشغيل وحدها إلى الاتصال المباشر بالشيفرة المصدرية. يربط Penligent نتائج التعليمات البرمجية الثابتة بأدلة التنفيذ الحقيقية: أي نقاط النهاية التي تم استدعاؤها، ومعرفات المعاملات التي تمت ملاحظتها على السلسلة، وتسلسل الأحداث التي أدت إلى اختلاف الحالة. والنتيجة هي حزمة أدلة قابلة للتنفيذ: يتلقى المطورون خطوط المصدر الدقيقة لإصلاحها، وتحصل العمليات على آثار المعاملات للتحقق من صحة عملية عكس أو تخفيف، وتحصل فرق الأمن على خطة علاجية ذات أولوية.
بالنسبة للفرق التي تعتمد هذا النموذج، يصبح سير العمل أسرع وأكثر قابلية للمساءلة. فبدلاً من أشهر من الفرز اليدوي، تحصل على أدلة قابلة للتكرار ومسار إصلاح واضح. يتعلق الإصلاح بالهندسة بقدر ما يتعلق بالعملية: يجب على مالكي المنتجات قبول قيود الذرية، ويجب على العمليات ضمان عزل المعاملات في النشر، ويجب على الأمن التحقق من صحة عمليات التخفيف من خلال عمليات إعادة التشغيل المستهدفة.
المطالبة المقترحة (لغة طبيعية) - للاستخدام الداخلي
إذا كنت تريد أن يقوم Penligent بالبحث عن مخاطر الإنفاق المزدوج على غرار TOCTOU على خدمة معينة، يمكن أن تكون المطالبة الموجزة:
"افحص نقطة نهاية المدفوعات في https://staging.example.com/create_transaction لظروف سباق TOCTOU وظروف سباق الإنفاق المزدوج. ركز على مسارات التعليمات البرمجية التي تقرأ الأرصدة أو الاستحقاقات ثم تكتب الحالة. قم بتوليد عينات تحقق غير مدمرة وربط أي آثار معاملات متزامنة وإنتاج حزمة أدلة مع مواقع المصدر والإصلاحات ذات الأولوية."
توجّه هذه المطالبة Penligent للجمع بين مطابقة الأنماط الثابتة والتحقق الآمن من صحة وقت التشغيل وارتباط الأدلة.
