S/۰۴ · خدمات
تست نفوذ
ما نفوذ می‌کنیم تا کس دیگری نکند.
وب‌سایت، API، اپلیکیشن و شبکه‌ی شما را مثل یک مهاجم واقعی — در محدوده‌ی توافق‌شده — هدف می‌گیریم، هر یافته را همراه با راه‌حل گزارش می‌دهیم و پس از اصلاح، دوباره تست می‌کنیم.
- پوشش
- وب، API، موبایل، شبکه
- روش
- OWASP WSTG و ASVS، PTES
- شامل
- تست مجدد پس از اصلاح
- ۰۱
در آستانه‌ی راه‌اندازی هستید یا تازه راه‌اندازی کرده‌اید.
- ۰۲
مشتری، سرمایه‌گذار یا نهاد ناظر ارزیابی امنیتی می‌خواهد.
- ۰۳
با پرداخت، داده‌ی سلامت یا هر چیز ارزشمندی سروکار دارید.
- ۰۴
یک سال است کسی نگاهی نینداخته.
- D/۰۱
تعریف محدوده
پیش از هر تستی، مکتوب توافق می‌کنیم چه چیزی، چطور و کی تست شود. سند قواعد کار اهداف، چیزهای ممنوع، بازه‌های تست و فردی که باید با او تماس گرفت را مشخص می‌کند، تا هر تست مجاز باشد و هیچ چیز تیم شما را غافلگیر نکند.
شامل
- اهداف داخل محدوده، و آنچه بیرون است
- بازه‌های تست و سقف بار
- حساب آزمایشی برای هر نقش
- مخاطبان اضطراری و راهی برای توقف فوری تست
docs/rules-of-engagement.pdf قواعد کار · سامانه‌ی نوبت‌دهی کلینیک
امضاشده به دست هر دو طرف · ۱۲ شهریور
داخل محدوده
- app.staging.example.com و api.staging.example.com
- اپلیکیشن‌های iOS و Android، بیلد 2.4
خارج از محدوده
- درگاه پرداخت و سامانه‌ی پیامک.
- حمله‌ی منع سرویس، مهندسی اجتماعی و دسترسی فیزیکی.
بازه‌ها
- محیط آزمایشی در هر زمان؛ محیط واقعی شنبه تا چهارشنبه، ۱۰ تا ۱۶، فقط خواندنی.
مخاطبان
- مهندس کشیک شما، تلفنی؛ هر طرف می‌تواند تست را متوقف کند.
- D/۰۲
تست دستی
ابزارها سطح حمله را نقشه‌برداری می‌کنند و بعد آدم‌ها تست می‌کنند: با حساب یک کاربر وارد شدن و داده‌ی کاربر دیگری را خواستن، تکرار درخواست‌ها، عوض کردن قیمت وسط پرداخت. بیشتر نقص‌های جدی در منطق کسب‌وکارند، جایی که اسکنرها نمی‌بینند.
شامل
- احراز هویت، نشست‌ها و بازیابی رمز عبور
- کنترل دسترسی میان کاربران و نقش‌ها
- تزریق، آپلود فایل و درخواست‌های سمت سرور
- منطق کسب‌وکار: پرداخت، تخفیف و گردش کارها
burp · repeater $ GET /api/bookings/8812 (token: patient A)
200 OK · booking 8812 · owner patient A
$ GET /api/bookings/8813 (token: patient A)
× 200 OK · booking 8813 · owner patient B
leaks: phone, date of birth, visit notes
! ownership is not checked on booking reads
✓ logged as F-01 · evidence req-0412, req-0413
- D/۰۳
یافته‌های درجه‌بندی‌شده
هر یافته با CVSS درجه‌بندی می‌شود و شواهد پشتش است: درخواست، پاسخ، اثر و مراحل بازتولید. برنامه‌نویس‌هایتان می‌توانند پیش از شروع اصلاح، هر مشکل را خودشان تأیید کنند.
شامل
- امتیاز و بردار CVSS 3.1 برای هر یافته
- درخواست‌ها، پاسخ‌ها و تصویرها به عنوان شاهد
- مراحل بازتولید، به ترتیب
- اثر واقعی روی کسب‌وکار و کاربران شما
reports/pentest-2026-q3.pdf شناسه شدت یافته CVSS F-01 بالا هر بیمار می‌تواند نوبت‌های بیماران دیگر را ببیند ۷٫۵ F-02 بالا لینک بازیابی رمز عبور هیچ‌وقت منقضی نمی‌شود ۷٫۴ F-03 متوسط تعداد تلاش برای کد ورود محدود نیست ۶٫۵ F-04 متوسط XSS ذخیره‌شده در یادداشت‌های کلینیک ۵٫۴ F-05 پایین صفحه‌های خطا stack trace را نشان می‌دهند ۳٫۷ F-06 پایین هدرهای امنیتی وجود ندارند ۳٫۱ - D/۰۴
راهنمای اصلاح
هر یافته با راه‌حلی می‌آید که برای فناوری و کد خود شما نوشته شده. هر جا لازم باشد، کوئری اصلاح‌شده یا middlewareای که باید اضافه شود را هم می‌گذاریم، همراه با تستی که ثابت می‌کند اصلاح سر جایش می‌ماند.
شامل
- علت اصلی، در یکی دو جمله
- راه‌حل مشخص برای فریمورک و زبان شما
- تستی که پیش از اصلاح شکست می‌خورد و بعد از آن قبول می‌شود
- جاهای دیگری از کد که همین الگو را دارند
reports/fixes/F-01.md F-01 · بررسی مالک نوبت
بالا · CVSS 7.5 · AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
علت
- GetBooking نوبت را با id می‌خواند و هرگز با کاربر درخواست‌دهنده مقایسه نمی‌کند.
اصلاح
- فیلتر مالک را در خود کوئری بگذارید:
- WHERE id = $1 AND patient_id = $2
- به جای 403، پاسخ 404 بدهید تا نشود idها را حدس زد.
تست
- نوبت بیمار B را با توکن بیمار A درخواست کنید؛ پاسخ باید 404 باشد.
این‌ها را هم بررسی کنید
- GetInvoice و GetPrescription همین الگو را دارند.
- D/۰۵
خلاصه‌ی مدیریتی
یک صفحه برای کسانی که تأیید نهایی با آن‌هاست: سطح کلی ریسک، آنچه پیدا کردیم، این‌که اگر کسی از آن استفاده کند چه پیش می‌آید، و این‌که اول چه چیزی را درست کنید. به زبان ساده نوشته می‌شود تا بشود همان‌طور که هست به هیئت‌مدیره، مشتری یا نهاد ناظر داد.
شامل
- سطح کلی ریسک، در یک خط
- تعداد یافته‌ها به تفکیک شدت
- اثر روی کسب‌وکار، بدون اصطلاحات فنی
- اصلاح‌هایی که باید اول انجام شوند، به ترتیب
reports/pentest-2026-q3.pdf · page 1 ریسک کلی
بالا
با اصلاح F-01 و F-02 پایین می‌آید
یافته‌ها
۶
۲ بالا · ۲ متوسط · ۲ پایین
بحرانی
۰
هیچ یافته‌ای کنترل کامل نمی‌دهد
زمان اصلاح
~۴ روز
برآورد، برای یک برنامه‌نویس
- D/۰۶
تست مجدد
وقتی اصلاح‌ها را اعمال کردید، هر یافته را دوباره تست می‌کنیم و وضعیت تازه‌اش را در گزارش ثبت می‌کنیم. در پایان سندی دارید که نشان می‌دهد امروز کجا ایستاده‌اید و می‌توانید آن را به مشتری‌ها یا حسابرس‌ها بدهید.
شامل
- تست دوباره‌ی همه‌ی یافته‌ها، با شواهد تازه
- وضعیت هر کدام: اصلاح‌شده، نیمه‌اصلاح‌شده یا باز
- گزارش و خلاصه‌ی مدیریتی به‌روزشده
- بررسی این‌که اصلاح‌ها رخنه‌ی تازه‌ای باز نکرده باشند
reports/retest-2026-q3.pdf - F-01 · خواندن نوبت حالا مالک را بررسی می‌کنداصلاح‌شده
- F-02 · لینک بازیابی پس از ۳۰ دقیقه منقضی می‌شوداصلاح‌شده
- F-03 · کد ورود فقط برای هر IP محدود شده، نه برای هر حسابنیمه
- F-04 · یادداشت‌های کلینیک هنگام نمایش escape می‌شونداصلاح‌شده
- F-05 · صفحه‌های خطای عمومی در محیط واقعیاصلاح‌شده
- F-06 · هدرهای امنیتی روی API هنوز نیستندباز
- ۰۱
محدوده
چه چیزی داخل است، چه چیزی بیرون، کی تست می‌کنیم و اگر چیزی خراب شد با چه کسی تماس بگیریم.
- ۰۲
شناسایی
سطح حمله را نقشه‌برداری می‌کنیم: endpointها، زیردامنه‌ها، نسخه‌ها، آدم‌ها.
- ۰۳
حمله
احراز هویت، سطح دسترسی، تزریق، منطق کسب‌وکار — زنجیره‌شده همان‌طور که مهاجم‌ها می‌کنند.
- ۰۴
گزارش و تست مجدد
یافته‌ها با راه‌حل، جلسه‌ی مرور با تیمتان و تست مجدد پس از اصلاح.
تست یک وب‌اپلیکیشن همراه با APIاش معمولاً از تعریف محدوده تا گزارش دو تا سه هفته طول می‌کشد، و تست مجدد هر وقت اصلاح‌هایتان آماده بود انجام می‌شود. اگر چیز بحرانی پیدا کنیم، همان روز با شما تماس می‌گیریم و منتظر گزارش نمی‌مانیم.
- هفته‌ی ۱
جلسه‌ی تعریف محدوده، مجوز کتبی و امضای قواعد کار، و بعد ساختن حساب‌های آزمایشی.
- روز ۱ و ۲
شناسایی: endpointها، زیردامنه‌ها، نسخه‌ها و نقش‌هایی که هر بخش از اپلیکیشن پشتیبانی می‌کند.
- روز ۳ تا ۸
تست دستی احراز هویت، کنترل دسترسی، تزریق و منطق کسب‌وکار.
- روز ۹ و ۱۰
گزارش و خلاصه‌ی مدیریتی، و بعد یک جلسه‌ی مرور با برنامه‌نویس‌هایتان.
- پس از اصلاح‌ها
تست دوباره‌ی همه‌ی یافته‌ها و گزارشی به‌روز که وضعیت فعلی شما را نشان می‌دهد.
گزارش کامل
هر یافته با درجه‌ی CVSS، شواهد، اثر و مراحل بازتولید.
خلاصه‌ی مدیریتی
یک صفحه به زبان ساده برای مدیران، مشتری‌ها یا نهادهای ناظر.
راهنمای اصلاح
یک راه‌حل مشخص و یک تست برای هر یافته، نوشته‌شده برای فناوری شما.
شواهد
درخواست‌ها، پاسخ‌ها و تصویرها، بایگانی‌شده و به‌صورت امن تحویل‌شده.
گزارش تست مجدد
وضعیت هر یافته پس از اصلاح‌هایتان، با شواهد تازه.
نامه‌ی ارزیابی
نامه‌ای کوتاه و امضاشده که می‌گوید چه چیزی و کی تست شد، برای مشتری‌ها و حسابرس‌ها.
- OWASP WSTG
- OWASP ASVS
- PTES
- Burp Suite
- nmap
- ffuf
- Nuclei
- sqlmap
تست، سرویس اصلی را از کار نمی‌اندازد؟
بازه‌ها و محدودیت‌ها را از قبل توافق می‌کنیم، از اقدامات مخرب پرهیز می‌کنیم و می‌توانیم روی نسخه‌ی آزمایشی تست کنیم.
چه فرقی با اسکن خودکار دارد؟
اسکنرها الگوهای شناخته‌شده را پیدا می‌کنند. مشکلات جدی معمولاً در منطق کسب‌وکار و زنجیره شدن نقص‌های کوچک‌اند — و این کار آدم می‌خواهد.
گزارش محرمانه است؟
بله. فقط به افرادی که معرفی می‌کنید می‌رسد و می‌توانیم پیش از تعریف محدوده قرارداد عدم افشا امضا کنیم.
چقدر طول می‌کشد؟
برای یک وب‌اپلیکیشن و API معمولی دو تا سه هفته، همراه با گزارش. محدوده‌های بزرگ‌تر بیشتر طول می‌کشند، و پیش از شروع یک برنامه‌ی مشخص می‌گیرید.
از ما چه چیزی لازم دارید؟
مجوز کتبی از کسی که حق صدورش را دارد، حساب آزمایشی برای هر نقش، و فردی که در بازه‌های تست در دسترس باشد. دسترسی به کد منبع کمک می‌کند، اما اجباری نیست.
بگویید چه چیزی می‌سازید.
هر پروژه با یک جلسه‌ی مشاوره شروع می‌شود: شما ایده و هر آنچه می‌دانید را می‌آورید، ما آن را به طرحی تبدیل می‌کنیم که بشود رویش ساخت.
رزرو مشاوره