​💡 نتیجه‌گیری معماری؛ چرا نباید به لایه‌های بعدی اعتماد کرد؟

​شاید بعد از خوندن باگ‌های پست قبل بگید:

«خب این باگ‌ها روی سرور بانک واقعی کار نمی‌کنه چون بانک خودش دبل تراکنش یا موجودی رو چک می‌کنه». اما نویسنده مقاله یک استدلال فوق‌العاده درست و استاندارد رو مطرح می‌کنه:

​تسوویه و منطق تراکنش‌ها وظیفه خودِ پردازشگر پرداخت (Payment Processor) هست که این وسط قرار گرفته. لایه‌هایی مثل بررسی هویت کارت در زمان ابطال، عدم دسترسی فروشگاه‌ها به تراکنش‌های همدیگه (IDOR) و ثبت لاگ‌ها تماماً باید در لایه همین سوکت مدیریت بشن و رها کردن این باگ‌ها به امید اینکه «بانک نهایی جلوش رو می‌گیره» یک خطای بزرگ در معماری امنیته.

​🛠 چک‌لیست پیشنهادی برای تست پروتکل ISO 8583:

اگر رفقای تستر می‌خوان این لایه رو تست کنن، حتماً این موارد رو فازینگ (Fuzzing) کنن:

🔹 تغییر مقدار تراکنش به صفر یا اعداد منفی

🔹 تغییر کدهای ارز (تست جابه‌جایی ارزها)

🔹 دستکاری طول فیلدهای متغیر (LLVAR/LLLVAR) برای بررسی بافر سرور

🔹 به‌هم ریختن نقشه بیتی (Bitmap) فیلدها

​خوشبختانه این باگ‌ها قبل از اینکه پوزها عملیاتی بشن و به بانک واقعی وصل بشن، در این پروژه تست نفوذ کشف و اصلاح شدن که اهمیت ارزیابی امنیتی رو قبل از ریلیز نشون میده.

​🔗 مطالعه کامل و فنی مقاله در وبلاگ نویسنده:
👉 https://m4kr0.vercel.app/posts/iso-8583-under-fire-finding-vulnerabilities-in-a-payment-socket

​🆔 @androidSec_fa

​#امنیت #تست_نفوذ #معماری_امنیت #تست_پوز #پروتکل_ISO8583 #امنیت_اندروید