بررسی AuthZ به کمک هوش مصنوعی: خواندن مرزهای دسترسی در Ory Kratos

هوش مصنوعی در پیدا کردن باگ‌ها ضعیف است اما در ایجاد شک و تردید عالی عمل می‌کند.

در حوزه امنیت، ارزان‌ترین کاری که یک هوش مصنوعی می‌تواند انجام دهد، ایجاد سیل عظیمی از گزارش‌های نادرست است. به همین دلیل است که برنامه‌های پاداش باگ (bug bounty) در حال متوقف کردن یا سخت‌گیرانه‌تر کردن قوانین خود هستند.

من از هوش مصنوعی به شیوه متفاوتی استفاده می‌کنم. من اجازه می‌دهم هوش مصنوعی بر اساس «کاتالوگ بوهای AuthZ» (AuthZ Smell Catalog) خود، فرضیه‌های بسیار زیادی تولید کند. سپس، کار سخت را خودم انجام می‌دهم. وظیفه من رد کردن (از بین بردن) آن فرضیه‌هاست.

یک بررسی موفق، لیستی از باگ‌ها نیست؛ بلکه جدولی از ایده‌هایی است که در آزمون شکست خورده‌اند.

من کد منبع Ory Kratos را بررسی کردم. Kratos مدیریت هویت و کاربران را بر عهده دارد. این یک حوزه پرخطر است زیرا از هویت‌های متعدد و APIهای عمومی استفاده می‌کند.

من پنج فرضیه را آزمایش کردم:

  • H1: API مدیریت (Admin API) در کد فاقد سطح دسترسی (authorization) است.
  • H2: نشت داده‌های بین‌هویتی یا بین‌مستاجری (cross-tenant).
  • H3: استفاده مجدد از توکن در جریان‌های بازیابی (recovery flows).
  • H4: سردرگمی هویت در جریان‌های تنظیمات (settings flows).
  • H5: تخصیص مستاجر (Tenant) از طریق بدنه درخواست (request payloads).

نتایج:

  • H1: رد شد. سطح دسترسی در مرز شبکه اعمال می‌شود، نه در هندلر کد. این موضوع طبق طراحی سیستم است.
  • H2: رد شد. یک لایه دسترسی به داده‌های مرکزی، تمام پرس‌وجوها را بر اساس شناسه مستاجر (tenant ID) فیلتر می‌کند. کاربران نمی‌توانند این لایه را دور بزنند.
  • H3: رد شد. توکن‌ها تک‌بار مصرف و دارای محدودیت زمانی هستند.
  • H4: رد شد. جریان‌ها به نشست (session) متصل هستند، نه به ورودی کاربر.
  • H5: رد شد. شناسه‌های مستاجر از بافت سیستم (system context) می‌آیند، نه از بدنه درخواست.

پنج فرضیه مطرح شد و هیچ یافته‌ای حاصل نشد. این یک بررسی موفق است.

دو درس برای کار امنیتی شما:

۱. امنیت در لایه استقرار (Deployment-layer)، شبیه به نبودِ امنیت به نظر می‌رسد. اگر یک نگهبان در سطح شبکه حضور داشته باشد، کد «برهنه» به نظر خواهد رسید. تا زمانی که معماری را بررسی نکرده‌اید، آن را گزارش نکنید.

۲. گلوگاه (chokepoint) را پیدا کنید. اگر سیستمی مرزها را در لایه داده اعمال می‌کند، هندلرهای مجزا نیازی به بررسی ندارند. به جای اینکه بپرسید «آیا این هندلر دسترسی‌ها را بررسی می‌کند؟»، بپرسید «آیا کسی می‌تواند بدون عبور از گلوگاه به داده‌ها دسترسی پیدا کند؟»

از هوش مصنوعی برای رد کردن کاندیداها استفاده کنید. از انسان‌ها برای تأیید بازماندگان استفاده کنید. ارزش اصلی در «رد کردن» نهفته است.

Source: https://dev.to/fdjedkdlsspec/ai-assisted-authz-review-reading-permission-boundaries-in-ory-kratos-31cg

Optional learning community: https://t.me/GyaanSetuAi