ارزیابی امنیتی و آزمون نفوذ برنامه کاربردی وب
ما با استفاده از متدولوژی‌های OWASP WSTG و ASVS، آسیب‌پذیری‌های امنیتی وب اپلیکیشن‌ها شامل تزریق SQL، XSS، نقص احراز هویت و پیکربندی‌های نادرست امنیتی را شناسایی و ارزیابی می‌کنیم.
خدمات ارزیابی امنیتی و آزمون نفوذ برنامه کاربردی وب
انتخاب سرویس متناسب با نیاز سازمان شما
پوشش کامل OWASP Top 10 (2021)
تست‌های ما تمام ده ریسک امنیتی برتر OWASP را پوشش می‌دهد
کنترل دسترسی شکسته
نقص‌های رمزنگاری
تزریق
طراحی ناامن
پیکربندی نادرست
کامپوننت‌های آسیب‌پذیر
نقص احراز هویت
نقص یکپارچگی
نقص ثبت وقایع
SSRF
چرا امنیت وب اپلیکیشن مهم است؟
وب اپلیکیشن‌ها اولین خط مقابله با مهاجمان هستند و نیاز به تست‌های امنیتی جامع دارند
وب اپلیکیشن از بیرون در دسترس است و همیشه روشن. برای مهاجمی که هدف مشخصی دارد، نخستین جایی است که امتحان می‌کند، چون نه به دسترسی داخلی نیاز دارد و نه به فریب یک کارمند.
تزریق SQL، XSS و احراز هویت شکسته می‌توانند داده‌های حساس مشتریان، اطلاعات مالی و اسرار تجاری را افشا کنند.
PCI-DSS، ISO 27001 و سایر مقررات نیاز به ارزیابی امنیتی منظم وب اپلیکیشن‌هایی دارند که داده‌های حساس را مدیریت می‌کنند.
آسیب‌پذیری‌های امنیتی می‌توانند منجر به اختلال سرویس، خسارات مالی و آسیب به اعتبار شوند که کسب‌وکار شما را تحت تأثیر قرار می‌دهد.
متدولوژی‌های تخصصی وب
ما از چارچوب‌های معتبر جهانی OWASP برای ارزیابی امنیت وب اپلیکیشن استفاده می‌کنیم
راهنمای جامع تست امنیت وب اپلیکیشن با ۹۱ دسته تست
برای تست جامع وب اپلیکیشناستاندارد اعتبارسنجی امنیت اپلیکیشن با ۲۸۶ کنترل
برای اعتبارسنجی امنیتیده ریسک برتر امنیتی وب اپلیکیشن (۲۰۲۱)
برای شناسایی ریسک‌های برترده ریسک برتر امنیتی API (۲۰۲۳)
برای امنیت API وبچه چیزهایی را تست می‌کنیم؟
پوشش جامع تمام جنبه‌های امنیتی وب اپلیکیشن بر اساس OWASP
- نگاشت دامنه‌ها و زیردامنه‌ها
- شناسایی فناوری و نسخه‌ها
- کشف مسیرها و فایل‌های رهاشده
- بررسی موتورهای جست‌وجو و مخازن عمومی
- هدرهای امنیتی و سیاست محتوا
- رابط‌های مدیریتی در دسترس
- فایل‌های پیکربندی و پشتیبان
- مدیریت خطا و صفحات پیش‌فرض
- پیکربندی TLS
- تعریف نقش‌ها و سطوح دسترسی
- فرایند ثبت‌نام و تأیید
- شمارش کاربران
- سیاست نام کاربری و رمز
- فرم ورود و محدودیت تلاش
- بازیابی و تغییر رمز
- ورود یکپارچه و OAuth
- تأیید دومرحله‌ای
- ذخیره‌سازی رمز
- دسترسی افقی میان کاربران هم‌سطح
- دسترسی عمودی به نقش بالاتر
- ارجاع مستقیم به شناسه‌ی اشیا
- کنترل دسترسی در لایه‌ی API
- تولید و پیش‌بینی‌پذیری توکن
- صفات کوکی و دامنه‌ی آن
- انقضا و تمدید نشست
- ابطال نشست هنگام خروج و تغییر رمز
- SQL Injection و NoSQL Injection
- Command Injection
- Server-Side Template Injection
- Path Traversal
- Server-Side Request Forgery
- افشای اطلاعات در پیام خطا
- الگوریتم و نمک‌گذاری رمزها
- رمزنگاری داده‌های حساس
- پیکربندی TLS و گواهی
- دور زدن مراحل یک فرایند
- تکرار درخواست و شرایط مسابقه
- دستکاری قیمت و تخفیف
- سوءاستفاده از محدودیت‌های کسب‌وکار
- Cross-Site Scripting و DOM
- Cross-Site Request Forgery
- Clickjacking و سیاست فریم
- CORS و منابع دامنه‌های دیگر
- APIهای REST و GraphQL
تست با چه سطحی از دسترسی انجام شود؟
هر سه سطح نتیجه‌ی متفاوتی می‌دهد. انتخاب میان آن‌ها به این بستگی دارد که می‌خواهید حمله‌ی واقعی را شبیه‌سازی کنید یا بیشترین پوشش را در زمان موجود به دست آورید.
از همان جایی شروع می‌کنیم که یک مهاجم بیرونی شروع می‌کند. این نزدیک‌ترین تصویر به حمله‌ی واقعی است، اما ممکن است بخش‌هایی از اپلیکیشن در زمان تست اصلاً دیده نشود.
در همان زمان پوشش بیشتری به دست می‌آید، چون تلاش تیم صرف تست می‌شود نه کشف. بیشتر ارزیابی‌ها را با همین سطح انجام می‌دهیم.
برای یافتن نقص‌های منطقی و مسیرهایی که از بیرون پیدا نمی‌شوند مناسب است و معمولاً کنار بازبینی کد می‌نشیند.
دامنه‌ی ارزیابی و آنچه از شما لازم است
کیفیت نتیجه بیش از هر چیز به آماده‌بودن این چند مورد بستگی دارد.
فهرست دامنه‌ها و زیردامنه‌ها، محیطی که تست روی آن انجام می‌شود، نقش‌های کاربری داخل دامنه، و مواردی که باید دست‌نخورده بماند، پیش از شروع نوشته و تأیید می‌شود.
برای هر نقش کاربری دست‌کم یک حساب لازم داریم، و برای سنجش کنترل دسترسی دو حساب هم‌سطح. بدون این حساب‌ها بخش بزرگی از اپلیکیشن آزمون‌نشده می‌ماند.
محیطی که شبیه محیط عملیاتی باشد دقیق‌ترین نتیجه را می‌دهد. اگر تست ناگزیر روی محیط عملیاتی انجام شود، ساعت کار و محدودیت‌ها را از پیش توافق می‌کنیم.
اگر WAF یا محدودکننده‌ی نرخ در مسیر باشد، برای بخشی از تست نشانی ما را در فهرست مجاز قرار می‌دهید تا آنچه می‌سنجیم خودِ اپلیکیشن باشد، نه فیلتر جلوی آن.
در هر دو طرف یک نفر مسئول ارتباط است. اگر در میانه‌ی کار یافته‌ای بحرانی پیدا شود، همان روز اطلاع می‌دهیم و منتظر گزارش نهایی نمی‌مانیم.
شدت هر یافته چطور تعیین می‌شود
عددی که پشتش روشی نباشد، به تصمیم‌گیری درباره‌ی ترتیب رفع کمکی نمی‌کند.
هر یافته با CVSS v3.1 امتیاز می‌گیرد تا زبان مشترکی با تیم فنی شما و ابزارهایی که از پیش دارید وجود داشته باشد.
یک آسیب‌پذیری روی صفحه‌ی ورود و روی یک صفحه‌ی داخلی اهمیت یکسانی ندارد. امتیاز پایه را با ارزش داده و دسترس‌پذیری آن مسیر تنظیم می‌کنیم.
هر یافته با مراحلی همراه است که آن را بازتولید می‌کند. چیزی که نتوانیم نشان دهیم، به‌عنوان یافته‌ی قطعی گزارش نمی‌شود.
گزارش ترتیب کار را پیشنهاد می‌دهد: چه چیزی باید همین هفته رفع شود و چه چیزی می‌تواند در چرخه‌ی بعدی توسعه بنشیند.
فرآیند کار ما
رویکرد ساختاریافته ما برای ارزیابی امنیت وب اپلیکیشن
معماری را ترسیم می‌کنیم، endpointها را چه آن‌هایی که در رابط کاربری دیده می‌شوند و چه آن‌هایی که پشت آن قرار دارند فهرست می‌کنیم، فناوری و نسخه‌ها را مشخص می‌کنیم، و دنبال نسخه‌های قدیمی می‌گردیم که هنوز در دسترس مانده‌اند. همین مرحله تعیین می‌کند که زمان باقی‌مانده کجا صرف شود.
دسته‌های OWASP WSTG را روی سطحی که ترسیم شده دنبال می‌کنیم. ابزارها الگوهای شناخته‌شده را سریع پوشش می‌دهند، و دسته‌هایی که ابزار درباره‌شان نمی‌تواند داوری کند، پیش از همه کنترل دسترسی و منطق کسب‌وکار، دستی و با چند حساب کاربری تست می‌شود.
هر یافته‌ی محتمل را آن‌قدر بازتولید می‌کنیم تا قطعی شود، و بررسی می‌کنیم که آیا دو ضعف کوچک با هم به یک مشکل بزرگ‌تر می‌رسند یا نه. چیزی که نتوان نشان داد کنار گذاشته می‌شود، نه اینکه با احتیاط گزارش شود.
گزارش همراه با جلسه‌ای برای مرور آن ارائه می‌شود تا مهندسانی که قرار است کار را انجام دهند هر یافته را دقیق بفهمند. پس از اصلاحات، یافته‌ها دوباره تست و گزارش به‌روز می‌شود.
تحویل‌دادنی‌های پروژه
گزارش‌های جامع و عملیاتی برای تیم‌های فنی و مدیریتی
خلاصه مدیریتی
اینکه چه چیزی تست شد، چه یافته شد، و این یافته‌ها برای کسب‌وکار چه معنایی دارد، به زبانی که خواننده‌ی غیرفنی بتواند بر اساس آن تصمیم بگیرد. دو تا سه صفحه.
گزارش فنی
هر یافته با امتیاز CVSS v3.1، مراحلی که آن را بازتولید می‌کند، درخواست و پاسخ مربوط به آن، و بخشی از سامانه که تحت تأثیر است.
راهنمای رفع
برای هر یافته یک راه‌حل مشخص، نه ارجاع به یک استاندارد. هر جا که رفع مشکل در کد است نمونه‌ی کد می‌آید، همراه با ترتیب پیشنهادی انجام کارها.
تست مجدد رایگان
پس از رفع، هر یافته دوباره تست می‌شود و یا بسته‌شدن آن تأیید می‌شود یا با توضیح اینکه چه چیزی هنوز کار می‌کند دوباره باز می‌شود، و گزارش به‌روز می‌شود.
سوالات متداول
ما همه انواع وب اپلیکیشن‌ها را تست می‌کنیم شامل اپلیکیشن‌های تک‌صفحه‌ای (SPA)، اپلیکیشن‌های وب پیشرونده (PWA)، اپ‌های سنتی سمت سرور، APIهای REST/GraphQL و سرویس‌های وب. تست ما اپلیکیشن‌های ساخته شده با هر استک فناوری از جمله React، Angular، Vue، Node.js، Python، Java، PHP و غیره را پوشش می‌دهد.
ارزیابی آسیب‌پذیری (VA) بر شناسایی و فهرست‌بندی آسیب‌پذیری‌های بالقوه از طریق اسکن و تحلیل تمرکز دارد. تست نفوذ (PT) فراتر رفته و سعی در بهره‌برداری از آسیب‌پذیری‌ها برای اثبات تأثیر واقعی دارد. سرویس VA+PT ما هر دو رویکرد را برای ارزیابی امنیتی جامع ترکیب می‌کند.
زمان‌بندی به پیچیدگی اپلیکیشن بستگی دارد. ارزیابی یک وب اپلیکیشن معمولی ۱-۲ هفته طول می‌کشد. اپلیکیشن‌های پیچیده با ویژگی‌ها، نقش‌ها و یکپارچه‌سازی‌های زیاد ممکن است ۳-۴ هفته نیاز داشته باشند. ما تخمین دامنه و زمان‌بندی دقیق را در مشاوره اولیه ارائه می‌دهیم.
ما از OWASP Web Security Testing Guide (WSTG) با ۹۱ دسته تست برای تست جامع، OWASP ASVS با ۲۸۶ کنترل برای اعتبارسنجی و OWASP Top 10 برای پوشش ریسک‌های بحرانی استفاده می‌کنیم. رویکرد ما ارزیابی سیستماتیک و کامل همراستا با استانداردهای جهانی را تضمین می‌کند.
تست‌های ما با دقت طراحی شده‌اند تا کمترین تأثیر عملیاتی را داشته باشند. قبل از تست، دامنه و قواعد تعامل مشخص می‌شود. برای سیستم‌های حساس، تست در محیط staging یا در ساعات کم‌ترافیک انجام می‌شود. در صورت کشف آسیب‌پذیری بحرانی، بلافاصله اطلاع‌رسانی می‌کنیم.
شما دریافت می‌کنید: خلاصه مدیریتی، گزارش فنی با جزئیات آسیب‌پذیری و امتیازات CVSS، مستندات PoC، راهنمای رفع با نمونه کد، ماتریس ریسک اولویت‌بندی شده، و نقشه‌برداری انطباقی با استانداردهایی مانند PCI-DSS و ISO 27001. به علاوه جلسه توضیح گزارش و تست مجدد رایگان.
تست Black-Box یک مهاجم خارجی بدون دانش قبلی را شبیه‌سازی می‌کند. تست White-Box دسترسی به کد منبع برای تحلیل عمیق‌تر فراهم می‌کند. Gray-Box ترکیبی از هر دو رویکرد است. هر کدام مزایایی دارند - Black-Box سناریوهای حمله واقعی را نشان می‌دهد در حالی که White-Box پوشش جامع در سطح کد فراهم می‌کند. بهترین رویکرد را بر اساس نیازهای شما پیشنهاد می‌دهیم.
هزینه به عوامل مختلفی بستگی دارد: پیچیدگی و اندازه اپلیکیشن، تعداد نقش‌ها و سطوح دسترسی، نیاز به بازبینی کد منبع، الزامات انطباقی و سطح گزارش‌دهی. برای مشاوره رایگان و قیمت دقیق متناسب با نیازهای خاص شما، با تیم ما تماس بگیرید.
برای یک ارزیابی استاندارد خیر. بیشتر پروژه‌ها به‌صورت جعبه‌خاکستری انجام می‌شود: حساب آزمایشی برای هر نقش و شناختی کلی از معماری. کد منبع وقتی به کار می‌آید که هدف، یافتن نقص‌های منطقی یا مسیرهایی باشد که از بیرون به آن‌ها نمی‌رسیم، و در آن حالت ارزیابی معمولاً همراه با بازبینی کد انجام می‌شود.
WAF الگوهای حمله‌ی شناخته‌شده را فیلتر می‌کند، اما ضعفی را که پشت آن‌هاست برطرف نمی‌کند. برای دسته‌ای از مشکلات هم کاری از آن برنمی‌آید؛ مشکلاتی که شبیه ترافیک عادی به نظر می‌رسند، مثل دسترسی یک کاربر به داده‌ی کاربر دیگر یا نقصی در یک جریان کسب‌وکار. به همین دلیل بخشی از تست با عبور دادن نشانی ما از WAF انجام می‌شود تا خودِ اپلیکیشن سنجیده شود، و بخش دیگر نشان می‌دهد WAF در عمل چه مقدار را متوقف می‌کند.
اسکنر بخشی از کار است، نه همه‌ی آن. الگوهای شناخته‌شده را سریع پوشش می‌دهد و در کنارش یافته‌هایی گزارش می‌کند که در عمل قابل بهره‌برداری نیستند. کنترل دسترسی میان دو کاربر، منطق کسب‌وکار، و زنجیره‌هایی که در آن دو ضعف کوچک با هم به یک یافته‌ی جدی می‌رسند، بیرون از توان داوری اسکنر است. هر یافته‌ای که گزارش می‌شود، دستی اعتبارسنجی شده است.
پس از هر تغییر مهم در اپلیکیشن، و دست‌کم سالی یک بار. PCI DSS هم برای سامانه‌های داخل دامنه‌ی خود همین را می‌گوید. در عمل، تیم‌هایی که مرتب نسخه منتشر می‌کنند از ارزیابی کوچک‌تر و پیوسته به هر انتشار مهم، بیشتر از یک تست بزرگ سالانه سود می‌برند.
اصلاحات دوباره تست می‌شود. هر یافته یا بسته‌شده تأیید می‌شود یا با توضیح اینکه چه چیزی هنوز کار می‌کند دوباره باز می‌شود، و گزارش به‌روزشده‌ای دریافت می‌کنید که می‌توانید به ممیز یا مشتری خود ارائه دهید.
مقالات مرتبط
آنچه در این حوزه نوشته‌ایم