PoC — اثبات مفهوم

PoC چیست و در گزارش چه نقشی دارد؟

PoC مخفف Proof of Concept است: نمایشی کمینه، مستند و قابل تکرار که نشان می‌دهد یک آسیب‌پذیری واقعاً وجود دارد و اثری که در گزارش ادعا شده را ایجاد می‌کند. کارکردش تبدیل یک ادعا به یک واقعیت قابل راستی‌آزمایی است.

سه کاربرد عملی که PoC را از یک ضمیمه‌ی تشریفاتی به هسته‌ی گزارش تبدیل می‌کند:

• حذف بحث مثبت کاذب. بیشتر اختلاف تیم امنیت و توسعه از این پرسش شروع می‌شود که «این یافته واقعی است یا خروجی اسکنر؟»؛ یک PoC قابل تکرار بحث را تمام می‌کند.
• امکان بازتولید برای توسعه‌دهنده، که باید مشکل را ببیند تا رفعش کند.
• امکان آزمون مجدد. بدون PoC دقیق، تأیید رفع ممکن نیست. در PCI DSS نسخه‌ی 4.0.1 نیز آزمون مجدد پس از رفع یافته‌های قابل بهره‌برداری الزامی است (بند ۱۱٫۴٫۴)، و اجرای این الزام بدون PoC ثبت‌شده عملاً غیرممکن است.

به همین دلیل در یک گزارش تست نفوذ حرفه‌ای، هر یافته چهار عنصر دارد: شناسه‌ی CWE، دسته‌ی OWASP، امتیاز CVSS با ذکر نسخه، و یک PoC.

ویژگی‌های یک PoC خوب

نکته‌ی مهم درباره‌ی داده‌ی حساس: اثبات دسترسی نباید به استخراج داده‌ی واقعی تبدیل شود. اگر یک نقص IDOR اجازه‌ی خواندن رکورد کاربران دیگر را می‌دهد، اثبات با یک رکورد ماسک‌شده یا با تعداد رکوردهای قابل دسترسی انجام می‌شود، نه با دانلود کل جدول. این تفکیک هم اخلاقی است و هم حقوقی.

نمونه: یک PoC کمینه

ساده‌ترین شکل یک PoC خوب، جفت درخواست و پاسخ به‌همراه یک جمله‌ی تفسیر است. مثال برای یک نقص کنترل دسترسی:

POST /api/v1/orders/1042/cancel HTTP/1.1
Host: app.example.com
Cookie: session=<session-of-user-B>

HTTP/1.1 200 OK
{"status":"cancelled"}

تفسیر: سفارش 1042 به کاربر A تعلق دارد، اما نشست کاربر B توانست آن را لغو کند. سرور هیچ بررسی مالکیتی روی شیء انجام نمی‌دهد. پیش‌شرط: هر دو حساب آزمایشی توسط مشتری ارائه شده‌اند و سفارش، سفارش آزمایشی است.

این PoC همه‌ی ویژگی‌های لازم را دارد: کمینه (یک درخواست)، غیرتخریبی (سفارش آزمایشی و نه واقعی)، قابل تکرار، و بدون ابهام. مقایسه کنید با اسکریپتی که همه‌ی شناسه‌ها را پیمایش و داده‌ی مشتریان واقعی را ذخیره می‌کند — آن اثبات بهتری نیست، فقط ریسک حقوقی بیشتری دارد.

PoC در برابر اکسپلویت تسلیحاتی

مرزهای قراردادی و قانونی

PoC نقطه‌ای است که آزمون از «مشاهده» به «تعامل با اثر واقعی» می‌رود، و به همین دلیل بیشترین حساسیت حقوقی را دارد. چارچوبی که این کار را حرفه‌ای می‌کند:

• مجوز کتبی و دامنه‌ی مکتوب — دارایی‌های در دامنه، حساب‌های آزمایشی، پنجره‌ی زمانی، و فهرست صریح اقدامات ممنوع. این‌ها در قرارداد تست نفوذ و قواعد اجرای آزمون ثبت می‌شوند.
• سقف اثر — تا کجا مجاز به اثبات هستید؟ مثلاً «اثبات دسترسی مجاز است، استخراج داده مجاز نیست» یا «اثبات اجرای کد با یک دستور بی‌اثر مجاز است، ایجاد پایداری ممنوع».
• مدیریت داده — هر شاهد حاوی داده‌ی واقعی باید ماسک، رمزنگاری و در پایان قرارداد حذف شود؛ نگهداری بی‌ضابطه‌ی شواهد، بدهی امنیتی شرکت آزمونگر است.
• مسیر تماس اضطراری — اگر PoC به‌طور غیرمنتظره سرویس را تحت تأثیر قرار داد، تماس فوری و مستندسازی، بخشی از تعهد حرفه‌ای است.
• پاک‌سازی — حذف فایل‌های آپلودشده، حساب‌های ساخته‌شده و رکوردهای آزمایشی، به‌همراه فهرست آن‌ها در گزارش.

در ادبیات استاندارد هم همین ساختار دیده می‌شود: راهنمای NIST SP 800-115 مرحله‌ی برنامه‌ریزی، ملاحظات حقوقی، قواعد اجرا و مدیریت داده را بخشی از فرایند ارزیابی می‌داند، نه یک تشریفات اداری.

PoC و افشای مسئولانه

اگر آسیب‌پذیری کشف‌شده در محصول یک تأمین‌کننده‌ی ثالث باشد — یک افزونه، یک کتابخانه، یک محصول تجاری — قواعد تغییر می‌کند. آنجا موضوع دیگر یک قرارداد دوطرفه نیست و چارچوب درست افشای مسئولانه است:

1. گزارش به تأمین‌کننده از مسیر رسمی امنیتی او، با جزئیات فنی کافی برای بازتولید.
2. توافق بر یک بازه‌ی زمانی معقول برای انتشار وصله.
3. دریافت شناسه‌ی CVE از CNA مربوطه، در صورت لزوم.
4. عدم انتشار عمومی PoC پیش از دسترس‌پذیری وصله. و پس از آن هم، انتشار توضیح فنی مسئولانه‌تر از انتشار اکسپلویت آماده است.

در سمت مشتری هم همین منطق برقرار است: PoC داخل گزارش می‌ماند، گزارش داده‌ی محرمانه است، و گردش آن باید محدود و قابل ردیابی باشد. این انتظام همان چیزی است که یک تست نفوذ وب حرفه‌ای را از یک اسکن و ارسال خروجی خام متمایز می‌کند؛ اگر درباره‌ی دامنه و سطح اثبات مورد نیاز برای سازمان خود سؤالی دارید، مشاوره‌ی امنیت نقطه‌ی شروع درستی است.

پرسش‌های متداول