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
خارج از محدوده
- درگاه پرداخت و سامانه‌ی پیامک.
- حمله‌ی DoS، مهندسی اجتماعی و دسترسی فیزیکی.
بازه‌ها
- محیط آزمایشی در هر زمان؛ محیط واقعی شنبه تا چهارشنبه، ۱۰ تا ۱۶، فقط خواندنی.
رابط‌ها
- مهندس کشیک شما، از طریق تلفن؛ هر دو طرف می‌توانند تست را متوقف کنند.
- 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 معمولی دو تا سه هفته، همراه با گزارش. محدوده‌های بزرگ‌تر بیشتر طول می‌کشند، و پیش از شروع، برنامه‌ای مشخص در دستتان است.
از ما چه چیزی لازم دارید؟
مجوز کتبی از کسی که حق صدورش را دارد، حساب آزمایشی برای هر نقش، و فردی که در بازه‌های تست در دسترس باشد. دسترسی به کد منبع کمک می‌کند، اما اجباری نیست.
بگویید چه چیزی می‌سازید.
هر پروژه با یک مشاوره شروع می‌شود: شما ایده و هر چه می‌دانید را می‌آورید و ما از دلش طرحی درمی‌آوریم که بشود رویش ساخت.
رزرو مشاوره