رویکرد «میز قتل»؛ چرا هوش مصنوعی در شکار باگ‌های امنیتی شکست می‌خورد؟

ارزش واقعی هوش مصنوعی در بررسی مجوزهای دسترسی (Authorization یا AuthZ) نه در یافتن یک باگ تصادفی، بلکه در ثبت دقیق و سیستماتیک مواردی است که رد شده‌اند. این نتیجه‌گیری در تاریخ ۴ ژوئیه ۲۰۲۶، طی یک بررسی دقیق کد منبع Ory Kratos، که یک سرور مدیریت هویت متن‌باز است، حاصل شد. کریتوس (Kratos) به عنوان میدان آزمایش متدی به کار رفت که قصد داشت روند فعلی ممیزی‌های امنیتی مبتنی بر AI را معکوس کند. در حال حاضر، ممیزی‌های AI در حال غرق کردن برنامه‌های جایزه باگ (Bug Bounty) در موجی از گزارش‌های متقاعدکننده اما غلط هستند. هدف این متد جدید این بود که از AI برای تولید فرضیات ارزان و از انسان‌ها برای «کشتن» یا رد کردن سیستماتیک آن‌ها استفاده شود.

این رویکرد در لحظه‌ای بحرانی برای صنعت امنیت ارائه می‌شود. در طول سال ۲۰۲۶، بسیاری از برنامه‌های جایزه باگ مجبور شدند عملیات خود را سخت‌گیرانه‌تر کنند یا به‌طور کامل متوقف نمایند؛ زیرا توسط گزارش‌های مربوط به «احتمال وجود IDOR» که توسط هوش مصنوعی تولید شده بود، بمباران شدند. ارزان‌ترین کاری که یک مدل AI می‌تواند در حوزه امنیت انجام دهد، ایجاد «شک» است. یک مدل که روی یک کدبیس متمرکز شود، می‌تواند پیش از آنکه کاربر قهوه‌اش را تمام کند، پنجاه مورد مشکوک و محتمل را فهرست کند. با این حال، اکثر این موارد غلط هستند؛ زیرا یا سه خط بالاتر محافظت شده‌اند، یا در لایه داده محدود شده‌اند، یا در مرزی محافظت شده‌اند که مدل هرگز آن را ندیده است. برای یک AI ساده‌لوح، هر نقطه پایانی (Endpoint) که بررسی مشهودی در آن نباشد، شبیه به یک آسیب‌پذیری است؛ اما برای یک انسان، این اغلب یک انتخاب طراحی‌شده است. این چالش‌های مدیریتی در دنیای واقعی منجر به حوادث گسترده‌ای شده است، مانند آنچه در نقص «نایب سرگردان» متا مشاهده شد و منجر به افشای هزاران حساب کاربری گردید.

زمینه و محدوده بررسی (Context and Scope)

این بررسی به‌طور ویژه بر روی Ory Kratos متمرکز بود؛ یک سرور متن‌باز مدیریت هویت و کاربر که وظایف حیاتی نظیر ورود (Login)، ثبت‌نام (Registration)، بازیابی حساب (Recovery)، تایید هویت (Verification)، مدیریت نشست‌ها (Sessions) و تنظیمات سلف‌سرویس را بر عهده دارد. این پروژه تحت مجوز Apache-2.0 در دسترس است. کریتوس هدفی ایده‌آل برای بررسی AuthZ است، زیرا معماری آن دقیقاً جایی است که مجوزهای دسترسی معمولاً شکست می‌خورند: این سیستم چندین هویت را مدیریت می‌کند، همزمان دارای یک API عمومی و یک API مدیریتی است و در محصول میزبانی‌شده‌ی Ory، از قابلیت چند‌مستأجری (Multi-tenancy) پشتیبانی می‌کند.

برای حفظ یک متدولوژی سخت‌گیرانه، محدوده بررسی تنها به خواندن کد منبع در مخزن عمومی برای یک ساختار تک‌مستأجر (Single-tenant OSS build) محدود شد. هیچ‌کدام از اهداف میزبانی‌شده (Hosted) مورد دسترسی قرار نگرفتند. این فعالیت به‌طور صریح در لایه‌های بازتولید به عنوان repo_only دسته‌بندی شده است؛ به این معنا که نتایج به طراحی کد مربوط می‌شود و لزوماً به یک محصول فعال و میزبانی‌شده تعمیم نمی‌یابد. این تلاش یک ممیزی کامل امنیتی نبود، بلکه یک مطالعه موردی (Case Study) بود تا نشان دهد چگونه بررسی‌های به کمک AI می‌توانند با کشتن شک‌ها به‌جای ارسال آن‌ها، از مثبت‌های کاذب جلوگیری کنند.

مرحله تولید فرضیات (The Hypotheses Phase)

با استفاده از «کاتالوگ بوهای AuthZ» (AuthZ Smell Catalog)، یک مدل AI مامور شد تا فرضیات مشکوک را در کدبیس Ory Kratos بیش از حد تولید کند. AI در مرحله تولید بسیار موثر است و می‌تواند فهرستی خام و بدون فیلتر از کاندیداهای احتمالی تولید کند. این فرآیند منجر به پنج فرضیه با اطمینان بالا شد:

• H1: نبود مجوز در API مدیریتی (Admin API Lack of AuthZ): شک به اینکه عملیات CRUD هویت، حذف نشست‌ها و نقاط پایانی مربوط به کوریر (Courier) در API مدیریتی، فاقد بررسی‌های مجوز در سطح هر درخواست در هندلر باشند. (این مورد با بخش §01 جایگزینی ID شیء و بخش §13 مجوزهای مبتنی بر میان‌افزار در کاتالوگ مطابقت دارد).
• H2: نشت داده‌های بین‌مستأجری (Cross-Tenant Data Leaks): شک به اینکه یک هویت بتواند داده‌های هویت دیگر را از طریق /sessions/whoami یا جستجوهای هویت و فراخوانی‌های مدیریتی بخواند. (مطابق با بخش §04 شناسه مستأجر از ورودی کلاینت و بخش §05 نشت بین‌مستأجری از طریق اشیاء مرتبط).
• H3: استفاده مجدد از توکن (Token Reuse): سوالاتی در مورد اینکه آیا توکن‌های بازیابی و تایید واقعاً یک‌بار مصرف هستند یا خیر. (مطابق با بخش §09 استفاده مجدد از توکن‌های دعوت/اشتراک).
• H4: اختلال در جریان تنظیمات (Settings-Flow Confusion): شک به اینکه جریان تنظیمات سلف‌سرویس بتواند به سمت ویژگی‌های (Traits) یک هویت دیگر هدایت شود. (مطابق با بخش §02 مالکیت در مقابل دسترسی‌پذیری و بخش §07 امتیازات منقضی شده).
• H5: تزریق شناسنامه مستأجر در بدنه (Tenant Payload Injection): شک به اینکه یک درخواست ایجاد یا به‌روزرسانی ادمین بتواند یک شناسه شبکه (nid) دلخواه را برای عبور از مرز مستأجری تنظیم کند. (مطابق با بخش §04).

فرآیند «کشتن» (The Killing Process)

هر یک از این فرضیات تحت یک «تست کشتن» قرار گرفتند. قانون حاکم این بود که هر رفتاری «طراحی‌شده»-تلقی شود، مگر اینکه یک مسیر دسترسی واقعی و قابل دسترس برای کاربر ثابت کند که آن ناوردا (Invariant) در واقع شکسته شده است.

H1: مجوزهای API مدیریتی
این فرضیه به عنوان «طراحی‌شده» کشته شد. کریتوس عمداً API مدیریتی را بدون مجوزهای داخلی در هندلرها عرضه می‌کند. مستندات رسمی Ory صراحت دارد که API مدیریتی باید در مرز شبکه (با استفاده از Ingress، یک Reverse Proxy یا Oathkeeper) محافظت شود و هرگز نباید به‌طور عمومی در دسترس باشد. هوش مصنوعی یک حفاظ «گمشده» را پرچم‌گذاری کرد که در واقع یک لایه بالاتر قرار داشت؛ این یک نمونه کلاسیک از مثبت کاذب است که در بخش §13 کاتالوگ تعریف شده است.

H2: خواندن‌های بین-هویتی و بین-مستأجری
این فرضیه از طریق «طراحی گلوگاه» (Chokepoint Design) کشته شد. کریتوس از پخش کردن بررسی‌های مستأجری در تک‌تک هندلرها اجتناب می‌کند. در عوض، لایه پایداری (Persistence Layer) آن از یک Contextualizer مرکزی استفاده می‌کند که شناسه شبکه (nid) را مستقیماً در SQL تزریق می‌کند. چون لایه دسترسی به داده‌ها به‌طور مرکزی بر اساس مستأجر فیلتر می‌کند، یک هندلر نمی‌تواند به‌طور تصادفی داده‌های خارج از مرز را بخواند. در API عمومی، دسترسی به هویت از هویتِ موجود در نشست (Session) مشتق می‌شود و هرگز از شناسه‌های ارسالی کلاینت گرفته نمی‌شود. برای شکست دادن H2، باید یک مسیر خواندن پیدا می‌شد که به‌طور کامل لایه Persister را دور بزند، که در این ساختار هیچ موردی یافت نشد. این با الگوهای بخش §B کاتالوگ مطابقت دارد.

H3: استفاده مجدد از توکن
کشته شد. توکن‌های بازیابی و تایید به‌گونه‌ای طراحی شده‌اند که تک‌بار مصرف و دارای محدودیت زمانی باشند. فرآیند بازخرید (Redemption) توکن را در همان تراکنش باطل می‌کند و تضمین می‌کند که هرگونه تلاش برای تکرار (Replay) بعد از استفاده، با شکست مواجه شود.

H4: اختلال هویت در جریان تنظیمات
کشته شد. جریان تنظیمات به‌طور خاص به هویتی متصل می‌شود که از نشست احراز هویت شده استخراج شده است. از آنجایی که هویتی که اصلاح می‌شود از ورودی کلاینت گرفته نمی‌شود، این جریان نمی‌تواند به ویژگی‌های کاربر دیگری تغییر هدف دهد. این امر اصل موجود در بخش §02 کاتالوگ را تقویت می‌کند: «دسترسی برای خواندن، به معنای دسترسی برای نوشتن نیست».

H5: تخصیص مستأجر از طریق بدنه درخواست
کشته شد. شناسه شبکه (nid) از بستر (Context) درخواست مشتق می‌شود، نه از بدنه درخواست (Request Body). در نتیجه، یک عملیات ایجاد یا به‌روزرسانی ادمین نمی‌تواند یک nid خارجی را به سیستم تزریق کند.

نتیجه میز قتل (The Kill Table Outcome)

خروجی نهایی یک «میز قتل» بود که رد شدن فرضیات را به عنوان یک مصنوع (Artifact) اصلی ثبت می‌کرد:

این بررسی به این نتیجه رسید که هدف مورد بررسی، دفاع شده است؛ به‌ویژه به این دلیل که کریتوس مرز مستأجری خود را در Layer Persister متمرکز کرده و هویت را از نشست‌ها مشتق می‌کند. این امر کل ممیزی امنیتی را به یک سوال واحد تبدیل کرد: «آیا چیزی وجود دارد که بتواند بدون عبور از Persister به داده‌های ذخیره‌شده برسد؟»

در ساختار عمومی متن‌باز، پاسخ منفی بود. این نتیجه به عنوان repo_only دسته‌بندی شد که طراحی کد منبع را تایید می‌کند، بدون اینکه ادعا کند در برابر هر استقرار میزبانی‌شده‌ی احتمالی مقاوم است.

تحلیل: تغییر در رویه امنیتی AI

این مطالعه موردی نشان‌دهنده یک تغییر بنیادین در نحوه استفاده توسعه‌دهندگان از LLMها برای امنیت است. روش فعلی «بپاش و دعا کن» (Spray and Pray)، نسبت نویز به سیگنال ناپایداری ایجاد می‌کند. با تبدیل AI به یک «تولیدکننده فرضیه» و انسان به یک «کلید قطع» (Kill Switch)، ارزش از «شک» به «رد کردن» منتقل می‌شود. این رویکرد در راستای تلاش‌های گسترده‌تر برای ایجاد حاکمیت بر دسترسی‌های AI است، مشابه آنچه Weavz برای تضمین ردپای حسابرسی تعاملات AI با نرم‌افزارهای تجاری پیاده‌سازی کرده است.

دو الگوی کلیدی از این بررسی ظهور کرد:

• مجوزهای لایه استقرار، شبیه به «نبود مجوز» عمل می‌کنند: نقاط پایانی بدون بررسی‌های درون-کد، تنها زمانی علامت قرمز هستند که هیچ چیز خارج از کد آن‌ها را محافظت نکند. صفحات مدیریتی و سرویس‌های داخلی اغلب AIهای ساده‌لوح را گمراه می‌کنند. بررسی‌کنندگان باید بپرسند حفاظ در کجا جای دیگری می‌تواند باشد (بخش §13 کاتالوگ).
• مرزهای گلوگاهی در سطح هر هندلر، بدون محافظ به نظر می‌رسند: وقتی یک مرز در یک لایه دسترسی به داده‌ی واحد اجرا می‌شود، هر هندلر «لخت» به نظر می‌رسد. سوال درست این نیست که «آیا این هندلر بررسی می‌کند؟»، بلکه این است که «آیا چیزی می‌تواند بدون عبور از گلوگاه به داده‌ها برسد؟» (بخش §B و §12 کاتالوگ).

گام‌های بعدی و دفتر ثبت (Ledgering)

برای به کارگیری این متد، توسعه‌دهندگان باید کدبیس‌ها را برای یافتن گلوگاه‌های مرکزی نقشه‌برداری کرده و از «کاتالوگ بوهای AuthZ» برای تولید فرضیات استفاده کنند. نتایج باید در یک دفتر ثبت نتایج (Outcome Ledger) ذخیره شوند. برای این بررسی، ورودی دفتر ثبت به شرح زیر است:

• تاریخ: ۲۰۲۶-۰۷-۰۴
• برنامه: Ory Kratos (بررسی خود-هدایت شده متن‌باز)
• نوع منبع: oss_source_available
• کلاس: tenant_boundary
• لایه بازتولید: repo_only
• حکم انسانی: by_design
• وضعیت نهایی: not_applicable
• پرداخت: $0
• درس: گلوگاه Contextualizer/nid مرز مستأجری را متمرکز می‌کند؛ مجوز API ادمین به‌طور طراحی در لایه استقرار است. بررسی به این موضوع تقلیل می‌یابد که آیا Persister قابل دور زدن است یا خیر.

ردیف اول در یک دفتر ثبت درباره پرداخت نیست، بلکه درباره «صادق بودن» است. گام بعدی شامل هدف قرار دادن یک سیستم در دسترس-منبع با یک مرز newly-added (مانند یک ویژگی تازه RBAC یا SSO/SCIM) و اجرای آن در همان چرخه «بیش-تولید-سپس-کشتن» است.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.