چرا Burp Suite Community Edition؟
Burp Suite Community Edition مجموعه ابزارهای اصلی تست دستی امنیت وب را در اختیار می‌گذارد؛ از Proxy و HTTP history تا Repeater، Decoder و Sequencer. Installer رسمی روی Windows، macOS و Linux ارائه می‌شود. تست تهاجمی باید در Scope و با اجازه روشن انجام شود.
دریافت امن
برای دانلود از دکمه «دانلود رسمی» همین صفحه استفاده کنید. IROSG فایل installer این نرم‌افزار را mirror نمی‌کند تا کاربر همیشه به نسخه و signature رسمی سازنده دسترسی داشته باشد.
استفاده مسئولانه
در ابزارهای تحلیل، اسکن و Penetration Testing، Scope و مجوز روشن بخشی از کار فنی است. تنظیمات و رفتار ابزار را ابتدا در Lab بررسی کنید و سپس در محیط Production به‌کار ببرید.
جایگاه نسخه Community در فرایند بررسی وب
نسخه Community برای مشاهده و آزمون دستی رفتار برنامه وب مناسب است. ارزش اصلی آن این است که درخواست واقعی مرورگر را می‌بینید، اجزای آن را می‌فهمید و یک فرضیه محدود را با تغییر کنترل‌شده بررسی می‌کنید. این فرایند با اجرای خودکار همه آزمون‌های امنیتی یکسان نیست. امکانات و محدودیت نسخه‌ها باید از صفحه رسمی همان انتشار بررسی شوند؛ نباید راهنمای نسخه حرفه‌ای را بدون توجه به برچسب قابلیت‌ها به نسخه رایگان تعمیم داد.
برای شروع، یک برنامه محلی یا آزمایشگاه آموزشی مجاز انتخاب کنید و هدف را روشن بنویسید. نمونه مناسب این است که کاربر خواننده نباید بتواند تنظیمات حساب آزمایشی را تغییر دهد. چنین هدفی به یک مجموعه درخواست و پاسخ مشخص منتهی می‌شود. هدف مبهم «پیدا کردن همه آسیب‌پذیری‌ها» نه زمان لازم را روشن می‌کند و نه معیار پایان دارد. ابزار زمانی مفیدتر می‌شود که سؤال دقیق پیش از کلیک کردن و تغییر درخواست وجود داشته باشد.
محدوده آزمایش را در خود جریان کار منعکس کنید
نام دامنه، مسیرها، حساب‌های آزمایشی و عملیات مجاز را مشخص کنید. صفحه‌ای که روی دامنه شما باز می‌شود ممکن است درخواست‌هایی به تحلیل‌گر، پرداخت یا خدمات بیرونی بفرستد. وجود این درخواست‌ها در تاریخچه، مجوز آزمون آنها را ایجاد نمی‌کند. فیلتر و محدوده هدف را طوری تنظیم کنید که تمرکز روی دارایی مجاز بماند. همچنین عملیات دارای اثر واقعی مانند ارسال پیام یا تغییر سفارش را با داده و حساب آزمایشی جایگزین کنید.
پیش از تکرار یک درخواست، اثر آن را بفهمید. درخواست خواندن یک صفحه معمولاً با درخواست ایجاد پرداخت یا حذف فایل یکسان نیست. حتی یک درخواست ظاهراً ساده ممکن است در سمت سرور رویداد ثبت کند یا اعلان بفرستد. در آزمایشگاه، داده قابل بازنشانی داشته باشید و تعداد تکرار را محدود نگه دارید. این توجه به معنا، کیفیت آزمون را نیز بالا می‌برد؛ نتیجه‌ای که از تغییرات کنترل‌نشده محیط به دست آمده باشد سخت‌تر قابل تفسیر است.
Proxy چگونه میان مرورگر و سرور قرار می‌گیرد؟
مرورگر درخواست را از مسیر پراکسی عبور می‌دهد و ابزار امکان مشاهده یا توقف آن را فراهم می‌کند. اگر حالت توقف فعال باشد، صفحه ممکن است منتظر بماند تا درخواست آزاد شود. این رفتار را با کندی سرور اشتباه نگیرید. برای یادگیری، ابتدا درخواست را فقط مشاهده کنید و سپس توقف یک درخواست مشخص را امتحان کنید. دیدن صف درخواست‌های متوقف‌شده، یکی از نخستین بررسی‌ها هنگام «باز نشدن سایت» در محیط آزمایش است.
برای HTTPS، مرورگر باید به مرجع گواهی ابزار در محیط آزمایش اعتماد کند تا ارتباط قابل بررسی شود. این اعتماد را در پروفایل یا مرورگر مخصوص کار نگه دارید و آن را بی‌دلیل به محیط روزمره گسترش ندهید. گواهی و کلید مرتبط با پراکسی حساس‌اند، زیرا بخشی از مرز اعتماد آزمایش را می‌سازند. اگر برنامه از روش‌های ویژه اعتبارسنجی گواهی استفاده می‌کند، رفتار آن ممکن است متفاوت باشد و باید با روش آزمایش مجاز همان برنامه بررسی شود.
تاریخچه HTTP را به نقشه رفتار تبدیل کنید
تاریخچه تنها فهرست نشانی‌ها نیست. روش درخواست، کد پاسخ، نوع محتوا، کوکی و ترتیب فراخوانی‌ها نشان می‌دهند برنامه چگونه کار می‌کند. یک مسیر کاربری کوتاه، مانند ورود و مشاهده یک رکورد آزمایشی، را اجرا کنید و درخواست‌های مربوط را جدا کنید. سپس مشخص کنید کدام درخواست داده اصلی را می‌گیرد و کدام فقط فایل ایستا یا گزارش جانبی است. این تفکیک از آزمون بی‌هدف روی درخواست‌های نامرتبط جلوگیری می‌کند.
پاسخ موفق HTTP الزاماً موفقیت تجاری نیست و پاسخ خطا نیز همیشه نقص امنیتی نیست. ممکن است برنامه با وضعیت موفق، پیام خطای کاربردی برگرداند یا برای کار غیرمجاز پاسخ استانداردی بدهد. بدنه و اثر واقعی را بررسی کنید. اگر درخواست تغییر داده است، نتیجه را از مسیر مستقل خواندن مشاهده کنید. تکیه بر یک کد وضعیت بدون بررسی اثر، می‌تواند هم گزارش مثبت کاذب و هم از دست دادن مسئله واقعی ایجاد کند.
Repeater برای آزمون یک فرضیه در هر بار
در آزمون دستی، یک درخواست شاهد سالم را نگه دارید و فقط یک متغیر را تغییر دهید. اگر هم‌زمان شناسه، کوکی، روش و بدنه عوض شوند، علت تفاوت پاسخ روشن نخواهد بود. برای بررسی کنترل دسترسی در آزمایشگاه، دو حساب متعلق به خودتان با نقش متفاوت داشته باشید و رفتار هر کدام را روی رکوردهای آزمایشی مقایسه کنید. هدف، اثبات مرز نقش است؛ نیازی به جمع‌آوری داده کاربران واقعی وجود ندارد.
توکن‌های کوتاه‌عمر و مقادیر یک‌بارمصرف می‌توانند آزمون را تحت تأثیر قرار دهند. اگر درخواست تکرارشده شکست می‌خورد، ابتدا بررسی کنید آیا هنوز نشست معتبر و داده لازم تازه است. شکست ناشی از انقضای نشست را به عنوان موفقیت کنترل مجوز گزارش نکنید. در مقابل، اگر سرور درخواستی را پذیرفت، اثر آن را تأیید کنید. مقایسه درخواست شاهد تازه با نمونه تغییرکرده، نتیجه را از عوامل زمانی و نشست جدا می‌کند.
نشست، کوکی و نقش‌های متفاوت
برای مقایسه دو کاربر، محیط مرورگر و کوکی‌های آنها را جدا نگه دارید. مخلوط شدن نشست‌ها یکی از علت‌های رایج نتیجه‌گیری اشتباه است. نام تب در ابزار به تنهایی هویت درخواست را تعیین نمی‌کند؛ باید کوکی یا روش احراز هویت واقعی آن را بدانید. در یادداشت آزمون، حساب و نقش را با نام مستعار مشخص کنید و راز کامل را ثبت نکنید. این روش هم بازتولید را آسان می‌کند و هم خطر انتشار اعتبارنامه را کاهش می‌دهد.
خروج از برنامه را نیز بررسی کنید، اما قرارداد آن را روشن کنید. خروج مرورگر، لغو نشست سمت سرور و انقضای همه توکن‌ها الزاماً یک عملیات واحد نیستند. در محیط مجاز، درخواست قبل و بعد از خروج را مقایسه کنید و رفتار را با طراحی برنامه بسنجید. اگر یافته‌ای وجود دارد، دقیقاً بگویید کدام اعتبارنامه و تا چه زمانی قابل استفاده بوده است. عبارت کلی «خروج امن نیست» بدون جزئیات کافی، برای اصلاح توسعه‌دهنده مناسب نیست.
Decoder و تفاوت کدگذاری با رمزنگاری
داده درخواست ممکن است برای انتقال در نشانی، فرم یا ساختار دیگر کدگذاری شده باشد. رمزگشایی کدگذاری به فهم محتوا کمک می‌کند، اما وجود رشته ناخوانا به معنی رمزنگاری نیست. همچنین تغییر کدگذاری می‌تواند معنای ورودی را برای سرور عوض کند. هنگام بررسی، نسخه خام و نسخه خوانا را کنار هم نگه دارید تا معلوم باشد دقیقاً چه بایت‌هایی ارسال شده‌اند. این موضوع به‌ویژه در تحلیل تفاوت میان لایه‌های پردازش مهم است.
اگر ابزار مقدار را خودکار تغییر می‌دهد یا طول بدنه را اصلاح می‌کند، این رفتار را در نظر بگیرید. گزارش بازتولید باید به درخواست واقعی ارسال‌شده اشاره کند، نه فقط متنی که کاربر ابتدا تایپ کرده است. برای آزمون آموزشی، از داده ساده و بی‌خطر شروع کنید و مسیر تبدیل را دنبال کنید. فهم این تبدیل‌ها از جمع‌آوری فهرستی از رشته‌های آزمایشی بدون دانستن معنای آنها مفیدتر است و به تشخیص خطاهای ناشی از خود آزمون کمک می‌کند.
شواهدی که توسعه‌دهنده بتواند بازتولید کند
یک گزارش خوب شامل پیش‌شرط، نقش حساب، درخواست لازم، پاسخ و اثر مشاهده‌شده است. داده حساس را حذف یا با مقدار آزمایشی جایگزین کنید، ولی ساختار لازم برای فهم مشکل را نگه دارید. اگر نتیجه فقط در ترتیب خاصی رخ می‌دهد، آن ترتیب را بنویسید. تصویر صفحه به تنهایی معمولاً برای تشخیص علت کافی نیست؛ درخواست و پاسخ خلاصه‌شده با زمان و شناسه آزمایش ارزش بیشتری دارند.
شدت را از اثر واقعی نتیجه بگیرید، نه از نام ابزار یا شباهت ظاهری به یک دسته آسیب‌پذیری. اگر فقط یک پیام خطای متفاوت دیده‌اید، همان مشاهده و محدودیت آن را بیان کنید. برای اثبات بیشتر، کوچک‌ترین آزمون مجاز و غیرمخرب را انتخاب کنید. پس از اصلاح، همان درخواست شاهد و نمونه نامجاز را دوباره اجرا کنید تا مشخص شود مشکل رفع شده و مسیر مجاز همچنان کار می‌کند. این آزمون بازگشتی می‌تواند به بخشی از مجموعه آزمون برنامه تبدیل شود.
افزونه‌ها و داده پروژه
افزونه می‌تواند رفتار ابزار و دسترسی آن به داده‌ها را گسترش دهد. پیش از نصب، منبع، مجوزهای لازم و کاربرد واقعی را بررسی کنید. افزونه‌ای که به همه درخواست‌ها دسترسی دارد ممکن است کوکی و داده حساس آزمایش را ببیند. تعداد افزونه‌های بیشتر الزاماً کیفیت آزمون را بالا نمی‌برد و می‌تواند تشخیص کندی یا تغییر ناخواسته را دشوار کند. برای شروع، مجموعه کوچک و شناخته‌شده‌ای داشته باشید و هر افزونه را جدا ارزیابی کنید.
داده پروژه، تاریخچه و خروجی گزارش را متناسب با حساسیت نگه دارید. فایل‌های آزمون ممکن است حاوی اعتبارنامه یا اطلاعات داخلی باشند حتی اگر عنوان آنها عمومی به نظر برسد. قبل از اشتراک با تیم، نسخه پاک‌سازی‌شده بسازید و مطمئن شوید حذف ظاهری متن، مقدار را در بخش دیگری باقی نگذاشته است. پس از پایان کار، پروفایل مرورگر، گواهی آزمایشی و اعتبارنامه‌های موقت را مطابق برنامه پاک‌سازی کنید تا محیط آزمایش با فعالیت روزمره مخلوط نماند.
مقایسه منصفانه پیش و پس از اصلاح
برای تأیید یک اصلاح، شرایط حساب و داده را ثابت نگه دارید و درخواست شاهد را تازه دریافت کنید. اگر نشست منقضی شده یا رکورد آزمایشی حذف شده باشد، شکست درخواست ممکن است به اصلاح مربوط نباشد. ابتدا مسیر مجاز را موفق اجرا کنید و سپس همان تغییر محدود نامجاز را تکرار کنید. این ترتیب نشان می‌دهد برنامه هنوز کار می‌کند و کنترل مشخص نیز اعمال شده است.
در گزارش بازبینی، نسخه برنامه، زمان آزمون و تفاوت رفتار را بنویسید. اگر بخشی از سناریو قابل تکرار نبود، آن را جدا اعلام کنید و نتیجه کامل برای کل برنامه صادر نکنید. چنین گزارش کوتاه و دقیق، برای توسعه‌دهنده از تعداد زیادی تصویر بدون زمینه مفیدتر است و امکان تبدیل یافته به آزمون خودکار آینده را فراهم می‌کند.
