هک اخلاقی چیست؟ از مجوز تست تا گزارش یک هکر کلاه سفید

فرض کن صاحب یک فروشگاه ازت می‌خواد امنیت سایتش رو بررسی کنی. آدرس سایت رو می‌فرسته و می‌گه: «هر مشکلی پیدا کردی خبرم کن». همین‌جا یه سؤال مهم داریم: واقعاً اجازه داری هر بخشی رو تست کنی؟ مثلاً درگاه پرداختی که مال شرکت دیگه‌ست چی؟ یا اطلاعات مشتری‌هایی که توی دیتابیس هستن؟ قبل از اینکه حتی یک ابزار باز کنی، باید جواب این سؤال‌ها معلوم باشه. هک اخلاقی از همین‌جا شروع می‌شه، نه از تایپ اولین دستور توی ترمینال.

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

هک اخلاقی چیست؟ تعریف ساده ولی دقیق

ببین، هک اخلاقی یا Ethical Hacking یعنی با دانش امنیت سراغ بررسی ضعف‌های یک سیستم بری، اما فقط وقتی مجوز معتبر داری، محدوده کارت مشخصه و هدفت کمک به برطرف کردن مشکله. این‌طور نیست که چون نیت خوبی داری، هر آزمایشی مجاز باشه. باید بدونی کدوم سرویس مال چه کسیه، چه داده‌ای ممکنه ببینی، کدوم روش ممنوعه و نتیجه رو چطور بدون آسیب گزارش بدی.

به زبان ساده، هک اخلاقی ترکیبی از مهارت فنی، اجازه روشن و مسئولیت‌پذیریه. ممکنه یک هکر کلاه سفید و یک مهاجم از نظر شناخت شبکه یا نرم‌افزار مهارت‌های مشترکی داشته باشن؛ تفاوت اصلی اینه که یکی طبق مجوز و توافق کار می‌کنه و دیگری ممکنه از این مرزها عبور کنه. درباره «هک قانونی» هم باید دقیق باشیم: مجوز قرارداد، قوانین محل فعالیت و حقوق اشخاص ثالث همگی اهمیت دارن؛ یک اصطلاح تبلیغاتی به‌تنهایی قانونی بودن کار رو ثابت نمی‌کنه.

چرا شرکت‌ها اصلاً به هکر کلاه سفید نیاز دارن؟

یه سایت ممکنه سریع باز بشه، پرداخت‌هاش موفق باشن و کاربران هم ازش راضی باشن، ولی هنوز مشکل امنیتی داشته باشه. کار کردن یک قابلیت با امن بودن اون یکی نیست. فرض کن سامانه ثبت‌نام یک کارگاه به هر شرکت‌کننده یک بلیت می‌ده. دیدن بلیت خودت طبیعیه؛ اما آیا با همون حساب می‌تونی اطلاعات بلیت نفر دیگه رو ببینی؟ هکر کلاه سفید دقیقاً چنین مرزهایی رو در محیط مجاز بررسی می‌کنه.

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

آموزش هک اخلاقی؛ ۵ سؤال قبل از هر تست امنیتی

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

Who owns the asset?
       ↓
Who authorized this test?
       ↓
What is in scope?
       ↓
Which actions are permitted?
       ↓
How do we report and stop safely?

۱. صاحب سیستم کیه و چه کسی می‌تونه اجازه بده؟

فرض کن دوستی که توی یک شرکت کار می‌کنه بهت می‌گه: «سایت ما رو تست کن». از کجا معلوم اختیار صادر کردن چنین مجوزی رو داره؟ شاید فقط مسئول محتوا باشه و اصلاً دسترسی حقوقی یا سازمانی به زیرساخت نداشته باشه. داشتن رمز پنل یا آشنایی با مدیر شرکت هم مجوز ارزیابی امنیت نیست. باید روشن بشه چه کسی از طرف مالک دارایی، با چه اختیاری و برای چه محدوده‌ای اجازه داده.

۲. مجوز تست نفوذ دقیقاً چه چیزی رو پوشش می‌ده؟

مجوز مبهمی مثل «هرچی خواستی بررسی کن» برای یک پروژه امنیتی کافی نیست. بهتره دارایی‌ها، زمان و نوع فعالیت مکتوب باشن و شرایط انجام تست هم مشخص شده باشه. مثلاً ممکنه سایت متعلق به مشتری باشه، ولی زیرساخت ابری یا درگاه پرداختش برای یک شرکت دیگه کار کنه. در چنین وضعی، مجوز تست نفوذ روی سایت اصلی الزاماً اجازه آزمون سرویس ثالث رو هم نمی‌ده. هرجا شک داشتی، قبل از شروع تأیید بگیر.

۳. داخل محدوده هستم یا خارج از محدوده؟

اصطلاح Scope یعنی چیزهایی که اجازه داری داخل اون‌ها تست انجام بدی؛ Out of Scope هم محدوده‌ایه که اجازه نداری واردش بشی یا صریحاً از برنامه کنار گذاشته شده. ممکنه محیط آزمایشی داخل محدوده باشه، اما Production و داده مشتری‌های واقعی نه. همین‌طور یک زیردامنه که اسم برند روشه، خودبه‌خود جزو دارایی‌های مجاز نیست. توی هک اخلاقی مرز رو سند مجوز تعیین می‌کنه، نه شباهت ظاهری آدرس‌ها.

۴. قوانین تست امنیت چه روش‌هایی رو مجاز می‌دونن؟

حتی وقتی یک سرور داخل Scope قرار داره، معنی‌ش این نیست که هر تستی روش آزاده. شاید بررسی دستی کنترل دسترسی مجاز باشه، اما حمله منع سرویس، آزمون فشار سنگین یا دست‌کاری داده واقعی ممنوع باشه. این محدودیت‌ها معمولاً در Rules of Engagement یا قوانین اجرای آزمون نوشته می‌شن. برای آشنایی با تعریف رسمی، واژه‌نامه NIST رو ببین. قوانین تست امنیت باید قبل از شروع روشن باشن، نه بعد از ایجاد مشکل.

۵. اگر مشکلی پیدا شد، به کی و چطور گزارش بدم؟

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

سناریوی اختصاصی : اجازه تست سامانه ثبت‌نام کارگاه

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

وسط کار می‌بینی بخشی از محیط آزمایشی به درگاه پرداخت اصلی لینک داده. آیا چون لینک رو داخل سایت دیدی، می‌تونی سرویس پرداخت رو هم تست کنی؟ نه؛ ارتباط فنی با سامانه، مجوز تازه‌ای ایجاد نمی‌کنه. اینجا باید توقف کنی و موضوع رو با مسئول پروژه در میون بذاری. اگر لازم بود، از مالک سرویس پرداخت هم اجازه جداگانه گرفته بشه. در هک اخلاقی گاهی حرفه‌ای‌ترین تصمیم اینه که فعلاً هیچ تستی انجام ندی.

حالا فرض کن با همون دو حساب ساختگی، رفتار مشکوکی در کنترل دسترسی بلیت‌ها می‌بینی. تا جایی که Scope اجازه می‌ده، شواهد همون محیط رو ثبت کن و رفتار مورد انتظار رو کنار نتیجه واقعی بذار. برای «اطمینان بیشتر» لازم نیست سراغ بلیت‌های کاربران واقعی بری. اگر بررسی بیشتر به داده حساس یا محیط خارج از محدوده می‌رسه، ادامه رو متوقف کن و هماهنگ شو. گزارش دقیق روی داده تستی، از اثبات پرخطر روی اطلاعات واقعی ارزشمندتره.

تفاوت هک اخلاقی و تست نفوذ چیست؟

اینجا یه تفاوت اصطلاحی مهم داریم. هک اخلاقی بیشتر درباره چارچوب مسئولانه استفاده از مهارت‌های امنیتیه؛ اما Penetration Testing یا تست نفوذ یک ارزیابی هدفمند و ساختارمنده که معمولاً هدف، محدوده، روش، زمان و گزارش مشخص داره. بنابراین تفاوت هک اخلاقی و تست نفوذ این نیست که یکی ابزار داره و دیگری نه؛ تفاوت بیشتر در گستردگی مفهوم و شکل تعریف پروژه‌ست. هر بررسی مجازی هم لزوماً یک تست نفوذ کامل محسوب نمی‌شه.

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

هکر کلاه سفید کیه؟ آیا هر متخصص امنیتی هکر اخلاقیه؟

وقتی می‌گیم هکر کلاه سفید یا White Hat Hacker، معمولاً منظور کسیه که از مهارت‌هاش برای پیدا کردن و رفع ضعف‌های امنیتی در چارچوب مجاز استفاده می‌کنه. ولی رنگ کلاه به‌تنهایی مدرک مجوز نیست. ممکنه کسی شبکه و نرم‌افزار رو عالی بشناسه اما بیرون از محدوده تست کنه و مرتکب کار غیرمجاز بشه. از اون طرف، یک متخصص امنیت ممکنه روی دفاع، مانیتورینگ یا پاسخ به رخداد کار کنه و اصلاً شغلش تست نفوذ نباشه.

پس قرار نیست برچسب «هکر قانونمند» یا اسم چند ابزار، جای شواهد حرفه‌ای رو بگیره. در هک اخلاقی باید بتونی توضیح بدی برای چه کاری مجوز داشتی، چه چیزی رو بررسی کردی و چطور از داده‌ها مراقبت کردی. درباره تفاوت کلاه‌سفید و کلاه‌سیاه توی درس قبلی صحبت کردیم؛ اینجا تمرکزمون روی رفتار و تصمیمیه که از یک پژوهشگر مسئول انتظار می‌ره.

آیا داشتن نیت خوب برای قانونی شدن تست کافیه؟

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

گاهی توی برنامه‌های گزارش آسیب‌پذیری عبارت Safe Harbor رو می‌بینی. این اصطلاح به سیاست‌هایی اشاره می‌کنه که سازمان برای پژوهش امنیتی با حسن نیت و مطابق قواعدش اعلام می‌کنه؛ ولی مجوز نامحدود برای تست همه دارایی‌ها نیست. مثلاً توضیح HackerOne درباره Safe Harbor صریحاً می‌گه فعال بودن چنین چارچوبی، Scope برنامه رو خودکار عوض نمی‌کنه. پس باز هم باید ببینی دقیقاً چه چیزی مجازه.

باگ بانتی چه فرقی با هک اخلاقی داره؟

باگ بانتی یا Bug Bounty برنامه‌ای برای دریافت گزارش آسیب‌پذیریه که ممکنه برای یافته معتبر پاداش هم بده. اما همه برنامه‌های افشای آسیب‌پذیری پاداش نقدی ندارن و عمومی بودن یک برنامه هم معنی‌ش اجازه تست بدون محدودیت نیست. هر برنامه فهرست دارایی‌های مجاز، روش‌های ممنوع و شیوه گزارش خودش رو داره. قبل از شروع، اول قوانین همون برنامه رو بخون؛ صرف دیدن یک فرم گزارش باگ کافی نیست.

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

نمونه واقعی : صفحه باگ‌بانتی نابغه‌ها رو چطور بخونیم؟

برای یک نمونه واقعی، بد نیست صفحه باگ‌بانتی نابغه‌ها رو بخونی. این صفحه محدوده‌های مجاز و ممنوع رو جدا توضیح داده و درباره حداقل‌سازی آسیب، داده‌های کاربران و کیفیت گزارش هم قانون داره. هدف از معرفی این صفحه این نیست که تو رو به اجرای یک آزمایش دعوت کنم؛ می‌خوام یاد بگیری قبل از هر کار فنی، سیاست یک برنامه رو چطور بخونی. قوانین روز برنامه همیشه باید از خود صفحه بررسی بشن.

مثلاً در نسخه فعلی سیاست نابغه‌ها، سرویس‌های شخص ثالث خارج از کنترل سایت و داده حساب‌های دیگران از محدوده کنار گذاشته شدن. تست‌های مختل‌کننده، مهندسی اجتماعی و تغییر اطلاعات واقعی هم ممنوعن. این دقیقاً نشون می‌ده که قوانین تست امنیت چطور یک اصل کلی رو به تصمیم عملی تبدیل می‌کنن. اگه درباره مجاز بودن یک کار شک داری، از مسیر رسمی هماهنگ کن؛ خود این مقاله به کسی مجوز تازه‌ای برای تست نابغه‌ها یا سایت دیگه نمی‌ده.

فرایند کار یک هکر اخلاقی در دنیای واقعی

کار یک ارزیاب امنیت حرفه‌ای از هماهنگی شروع می‌شه. بعد رفتار درست سیستم رو می‌فهمه، روش کم‌خطر انتخاب می‌کنه، یافته رو با شواهد مناسب بررسی می‌کنه و نتیجه رو گزارش می‌ده. راهنمای NIST SP 800-115 هم روی برنامه‌ریزی، ارزیابی فنی و تحلیل نتایج تأکید داره. البته اینجا فقط یک نقشه آموزشی کوتاه می‌بینی؛ این فهرست قرار نیست به‌تنهایی روش اجرای یک پروژه واقعی باشه.

1. Authorization & scope
2. Understand expected behavior
3. Plan low-impact checks
4. Validate findings safely
5. Record evidence and impact
6. Report to the owner
7. Verify the fix when authorized

مرحله اول : محدوده و هدف رو روشن کن

اول باید دارایی‌های داخل محدوده، هدف تست، نوع داده‌های درگیر و مسئول تماس مشخص بشن. مثلاً بررسی یک فرم آزمایشی با ارزیابی سرور Production فرق داره، حتی اگه هر دو برای یک شرکت باشن. قبل از اجرای ابزار، درباره زمان مناسب آزمون و شرایط توقف هم توافق کن. توی آموزش هک اخلاقی همین آماده‌سازی بخشی از تخصصه؛ نه یک کار اداری که بشه نادیده‌اش گرفت.

مرحله دوم : رفتار درست رو قبل از رفتار اشتباه بفهم

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

مرحله سوم : آزمایش رو به اندازه لازم نگه دار

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

مرحله چهارم : یافته رو از حدس جدا کن

فرض کن ابزار بهت هشدار می‌ده که یک Endpoint «احتمالاً ناامن»ه. این هشدار فقط نقطه شروع بررسیه، نه سند قطعی وجود ضعف. شاید تنظیمی عادی باعث هشدار شده باشه یا ابزار وضعیت ورود کاربر رو درست تشخیص نداده باشه. یافته رو تا جایی که مجوز داری با رفتار واقعی و شواهد قابل تکرار تطبیق بده؛ اگر نمی‌تونی تأییدش کنی، همون رو صادقانه گزارش کن. کیفیت تحلیل از تعداد هشدارها مهم‌تره.

مرحله پنجم : نتیجه رو به زبان قابل اقدام تحویل بده

تیم توسعه با جمله «سایتتون هک می‌شه» نمی‌تونه چیزی رو اصلاح کنه. باید بدونن کدوم کنترل درست کار نکرده، مشکل در چه شرایطی دیده شده، اثر احتمالی چیه و چه راهی برای رفع یا کاهش ریسک وجود داره. اگه مسئله رفع شد، بررسی دوباره هم باید در محدوده اجازه انجام بشه. گزارش دقیق، آخرین بخش یک آزمون نیست؛ همون چیزیه که نتیجه فنی رو به اقدام قابل استفاده تبدیل می‌کنه.

فرق کشف یک ضعف با اثبات مسئولانه اون چیه؟

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

برای همین می‌گم تصمیم گرفتن درباره «کِی ادامه بدیم و کِی متوقف بشیم» خودش یک مهارت امنیتیه. ممکنه هنوز نتونی اثر واقعی یک هشدار رو ثابت کنی؛ اشکالی نداره، همون سطح اطمینان رو بنویس. یا شاید برای مرحله بعد مجوز جدید لازم باشه؛ اون وقت باید منتظر تأیید بمونی. این مدل کار کردن باعث می‌شه هم تیم مالک به گزارش اعتماد کنه، هم تو برداشت اغراق‌آمیز از نتیجه نداشته باشی.

یک گزارش ساده امنیتی چه قسمت‌هایی داره؟

بیا گزارش فرضی بلیت کارگاه رو کمی دقیق‌تر ببینیم. ما فقط روی محیط آزمایشی و دو حساب تست کار کردیم و هیچ سامانه واقعی رو آزمایش نکردیم. توی گزارش، «چیزی که دیدیم» رو از «اثری که حدس می‌زنیم» جدا می‌کنیم. مثلاً اگر فقط یک رفتار کنترل دسترسی عجیب دیده شده، نباید بنویسیم «همه حساب‌ها قابل نفوذن». گزارش خوب باید به‌اندازه شواهدش ادعا کنه.

توی جدول بالا عمداً اثر رو «احتمالی» نوشتیم. چون هنوز نمی‌دونیم همون رفتار در محیط اصلی وجود داره یا نه و اصلاً اجازه آزمون اون محیط رو نداریم. متخصص هک اخلاقی نه خطر رو بزرگ‌تر از شواهد معرفی می‌کنه، نه بی‌دلیل کوچیکش می‌کنه. هدف اینه که تیم مسئول بتونه از روی گزارش، تصمیم فنی درست بگیره.

تمرین عملی هک اخلاقی؛ تصمیم بگیر تست مجازه یا نه

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

permission_confirmed = True
target_in_scope = True
action_allowed = False

if permission_confirmed and target_in_scope and action_allowed:
    print("Approved: proceed within the agreed limits")
else:
    print("Stop: permission, scope, or action not approved")

خروجی اجرای نمونه با این مقدارهای اولیه:

Stop: permission, scope, or action not approved

چون مقدار action_allowed برابر False است، برنامه دستور توقف رو چاپ می‌کنه؛ هرچند دو شرط دیگه درست هستن. حالا مقدارش رو به True تغییر بده و نتیجه رو دوباره اجرا کن. در اون حالت هر سه شرط برقرارن و پیام تأیید نمایش داده می‌شه. دقت کن این فقط منطق یک مثال آموزشیه: در پروژه واقعی، مجوز و Scope با سه متغیر دستی اثبات نمی‌شن و باید اسناد و شرایط معتبر بررسی بشن.

اگر حین تحقیق ناخواسته به اطلاعات خصوصی رسیدیم، چیکار کنیم؟

اگر وسط یک تحقیق مجاز ناخواسته به اطلاعات واقعی کاربر رسیدی، همون‌جا ادامه بررسی رو متوقف کن. داده بیشتری باز نکن، ازش نسخه اضافی نساز و هیچ‌چیز رو عمومی منتشر نکن. بعد طبق مسیر رسمی برنامه، با حداقل اطلاعات ضروری موضوع رو گزارش بده. اینکه چه شواهدی باید نگه داری یا حذف کنی به سیاست برنامه و شرایط حقوقی بستگی داره؛ به‌خصوص درباره اطلاعات حساس نباید خودسرانه تصمیم گرفت.

برای مثال، ممکنه تیم مالک بتونه همون مشکل رو با حساب ساختگی در محیط داخلی بازتولید کنه، بدون اینکه پژوهشگر هیچ داده شخصی دیگری ببینه. این روش هم به تأیید یافته کمک می‌کنه، هم ریسک افشای اطلاعات رو پایین میاره. اعتماد کاربران چیزی نیست که برای کامل‌تر شدن یک گزارش به خطرش بندازیم؛ به همین دلیله که حفظ حریم خصوصی جزء واقعی هک اخلاقی محسوب می‌شه.

برای یادگیری هک اخلاقی حتماً باید Kali Linux نصب کنم؟

نه، برای شروع نیازی نیست حتماً Kali Linux نصب کنی. کالی ابزارهای زیادی برای ارزیابی امنیت داره، ولی نه مجوز تست می‌ده و نه به‌جای تو شبکه، وب یا سیستم‌عامل رو می‌فهمه. اگه هنوز HTTP، DNS، مجوز فایل و رفتار برنامه‌ها رو نمی‌شناسی، خروجی ابزارها بیشتر گیجت می‌کنه. برای آموزش هک اخلاقی از مبانی شروع کن و بعد سراغ ابزار برو؛ ابزار بدون درک نتیجه، مهارت حساب نمی‌شه.

اگه می‌پرسی «از کجا شروع کنم؟»، مسیر آموزش هک از صفر رو به‌ترتیب جلو ببر. وقتی به تمرین عملی رسیدی، از آزمایشگاه شخصی یا پلتفرمی استفاده کن که شرایط تستش روشنه. قرار نیست برای یاد گرفتن امنیت، سایت‌های تصادفی اینترنت رو هدف قرار بدی. پایه شبکه، سیستم‌عامل و وب کم‌کم بهت کمک می‌کنه بفهمی هر آزمون چه چیزی رو اندازه می‌گیره.

هک اخلاقی، باگ‌بانتی و کار تیم امنیت چه مسیرهایی دارن؟

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

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

پنج اشتباه رایج موقع شروع هک اخلاقی

اشتباه اول : فکر کنیم نیت خوب جای مجوز رو می‌گیره

کمک کردن به صاحب سایت کار خوبیه، ولی نیت خوب جای اجازه رو نمی‌گیره. قبل از شروع تست، باید بدونی چه کسی بهت اختیار داده و چه کارهایی مجازن. یک عبارت مبهم مثل «برای کمک تست کردم» بعد از وقوع مشکل، محدوده مجوز رو تغییر نمی‌ده.

اشتباه دوم : هر چیزی که به یک دامنه وصل بود داخل Scope بدونیم

ممکنه سایت از یک CDN، درگاه بانکی یا سرویس پیامکی بیرونی استفاده کنه. وصل بودن اون سرویس‌ها به دامنه اصلی، اجازه ارزیابی امنیت‌شون رو به تو نمی‌ده. در قوانین تست امنیت باید این مرزها از قبل روشن باشن.

اشتباه سوم : برای اثبات ضعف، بیشتر از حد لازم جلو بریم

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

اشتباه چهارم : خروجی ابزار رو بدون تحلیل گزارش کنیم

یک هشدار اسکنر به‌تنهایی «آسیب‌پذیری تأییدشده» نیست. علت هشدار، شرایط محیط و رفتار واقعی سیستم رو بررسی کن؛ اگر نتیجه هنوز نامطمئنه، توی گزارش هم همین رو بنویس. ادعای دقیق از تیتر بزرگ و بی‌مدرک معتبرتره.

اشتباه پنجم : گزارش رو با افشای عمومی اشتباه بگیریم

تا وقتی مالک فرصت منطقی برای بررسی و رفع ضعف نداشته، انتشار عمومی جزئیات می‌تونه به کاربران آسیب بزنه. روش و زمان افشا به سیاست برنامه و توافق بستگی داره. گزارش مسئولانه با انتشار فوری همه اطلاعات یکی نیست.

خودت تصمیم بگیر : چهار موقعیت کوتاه با پاسخ

موقعیت اول : فقط اجازه تست نسخه آزمایشی رو داری

فرض کن فقط مجوز نسخه آزمایشی رو داری و وسط بررسی یک لینک به Production پیدا می‌کنی. آیا می‌تونی تست رو روی محیط اصلی ادامه بدی؟ پاسخ: نه. تا وقتی مجوز صریح برای اون محیط نگرفتی، باید متوقف بشی و موضوع رو با مسئول پروژه هماهنگ کنی. پیدا شدن لینک، Scope رو تغییر نمی‌ده.

موقعیت دوم : صاحب سایت گفته اسکن مشکلی نداره

مالک سایت گفته «اسکن مشکلی نداره»، اما قوانین مکتوب برنامه تست فشار و ایجاد اختلال رو ممنوع کرده. آیا اجرای آزمایش سنگین مجازه؟ پاسخ: نه. اجازه انجام بعضی بررسی‌ها، ممنوعیت یک روش مشخص رو لغو نمی‌کنه؛ باید روش کم‌خطر و مورد توافق رو انتخاب کنی.

موقعیت سوم : ابزاری هشدار مهم داده

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

موقعیت چهارم : به داده حساس رسیدی

در یک آزمون مجاز، ناخواسته اطلاعات یک کاربر واقعی روی صفحه ظاهر می‌شه. آیا برای اطمینان باید چند حساب دیگه رو هم باز کنی؟ پاسخ: نه. ادامه رو متوقف کن و موضوع رو از مسیر رسمی با حداقل شواهد لازم گزارش بده. این دقیقاً یکی از موقعیت‌هاییه که رعایت اصول هک اخلاقی از اجرای ابزار مهم‌تره.

سؤالات متداول درباره هک اخلاقی

منابع معتبر برای مطالعه بیشتر

برای اینکه تعریف‌ها و روش‌های این درس رو خودت هم بررسی کنی، سراغ راهنمای NIST SP 800-115 برای برنامه‌ریزی و گزارش آزمون، پروژه رسمی OWASP WSTG برای روش‌شناسی بررسی امنیت وب و راهنمای Safe Harbor در HackerOne برای محدوده مجوز پژوهش برو. مثال سامانه ثبت‌نام این درس ساختگیه و منابع برای راستی‌آزمایی مفاهیم معرفی شدن، نه اینکه متن اون‌ها بازنویسی شده باشه.

جمع‌بندی: در هک اخلاقی، اول مجوز و تحلیل، بعد ابزار

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

برای ادامه، از مسیر مبانی هک و امنیت به درس‌های بعدی برو. اگه می‌خوای درباره روش‌های ارزیابی ساختارمند بیشتر یاد بگیری، مسیر تست نفوذ رو دنبال کن. برای آموزش ویدیویی و تمرین‌های گسترده‌تر هم می‌تونی سرفصل‌ها و وضعیت فعلی پکیج متخصص تست نفوذ رو بررسی کنی. عجله‌ای برای انتخاب ابزار نیست؛ اول مطمئن شو معنی نتیجه‌ای که می‌بینی رو فهمیدی.