ارزیابی امنیت PWA

ارزیابی امنیت اپلیکیشن‌های وب پیشرونده (PWA) شامل service workers و قابلیت‌های آفلاین

درباره این سرویس

ارزیابی امنیت PWA ما یک اپلیکیشن وب پیشرونده را با کل راهنمای OWASP WSTG می‌آزماید و سپس سطحی را می‌افزاید که یک PWA افزون بر یک وب‌اپ معمولی می‌سازد: یک service worker که میان صفحه و شبکه می‌نشیند، یک Cache Storage و IndexedDB که داده را برای استفاده‌ی آفلاین روی دستگاه نگه می‌دارند، یک web app manifest، و push و background sync. یک PWA همچنان همه‌ی خطرهای یک وب‌اپ را دارد، مانند تزریق، احراز هویت شکسته، کنترل دسترسی شکسته و اسکریپت میان‌سایتی، و این ویژگی‌های سمت‌کاربر چند خطر دیگر هم می‌افزایند. هر یافته را تا یک اثبات عملی دنبال می‌کنیم، در کنار اثر واقعی‌اش با CVSS رتبه می‌دهیم و همراه با یک رفع مشخص می‌نویسیم.

چه چیزی شامل می‌شود

تست کامل وب‌اپلیکیشن بر پایه‌ی OWASP WSTG: احراز هویت، مدیریت session، کنترل دسترسی، اعتبارسنجی ورودی، تزریق، XSS و CSRF

امنیت service worker: دامنه‌ی ثبت، سازوکار به‌روزرسانی، و شیوه‌ی رهگیری و پاسخ‌دهی به درخواست‌ها

مسموم‌سازی کش و داده‌ی حساس یا کهنه که از Cache Storage سرو می‌شود

داده‌ی آفلاین در حالت سکون در IndexedDB و local storage، و این‌که اصلاً باید آن‌جا باشد یا نه

بازبینی web app manifest: نشانی شروع، scope، مجوزها و اپلیکیشن‌های مرتبط

زمینه‌ی امن و اجبار HTTPS، و مسائل mixed-content

سوءاستفاده از push notification و background sync

منطق سمت‌کاربر و secretهای افشاشده در بسته‌ی جاوااسکریپت

سیاست امنیت محتوا (CSP) و دیگر هدرهای امنیتی پاسخ

اسکریپت‌های شخص ثالث و ریسک زنجیره‌ی تأمین سمت‌کاربر

چگونه کار می‌کند

1
دامنه‌گذاری و دسترسی
محدوده و معیار موفقیت را توافق می‌کنیم و عمق تست را تعیین می‌کنیم: جعبه‌سیاه از بیرون، جعبه‌خاکستری با حساب‌های آزمایشی برای هر نقش، یا جعبه‌سفید با دسترسی به کد برای عمیق‌ترین پوشش. نقش‌ها، ویژگی‌های آفلاینِ در حال استفاده و هر چیزی را که باید کنار گذاشته شود مشخص می‌کنیم.
2
تست وب‌اپلیکیشن
اپلیکیشن را همان‌طور که OWASP WSTG دسته‌بندی می‌کند می‌آزماییم: احراز هویت و session، کنترل دسترسی، مدیریت ورودی و تزریق، اسکریپت میان‌سایتی و منطق کسب‌وکار؛ چون یک PWA پیش از هر چیز یک وب‌اپ است و بیشتر یافته‌های واقعی همین‌جا هستند.
3
تست service worker و آفلاین
service worker را بررسی می‌کنیم: scope و مسیر به‌روزرسانی آن، شیوه‌ی کش و سرو پاسخ‌ها، و این‌که آیا می‌توان آن را وادار کرد محتوای مسموم یا کهنه سرو کند. بررسی می‌کنیم اپلیکیشن چه داده‌ای را به‌صورت آفلاین در Cache Storage و IndexedDB نگه می‌دارد و آیا آن داده حساس است.
4
ذخیره‌سازی سمت‌کاربر، manifest و هدرها
manifest، زمینه‌ی امن و اجبار HTTPS، سیاست امنیت محتوا و دیگر هدرهای امنیتی، push و background sync، و هر secret یا منطق حساسی که در بسته‌ی سمت‌کاربر افشا شده را بازبینی می‌کنیم.
5
اعتبارسنجی، گزارش‌دهی و تست مجدد
هر یافته با یک اثبات مفهوم تکرارپذیر تأیید می‌شود، با CVSS و اثر واقعی کسب‌وکار رتبه می‌گیرد و همراه با مسیر رفع اولویت‌دار نوشته می‌شود. پس از رفع، دوباره تست می‌کنیم تا مطمئن شویم رفع‌ها پابرجا هستند.
خروجی‌ها
  • خلاصه‌ی اجرایی با نمای کلی ریسک برای تصمیم‌گیرندگان
  • گزارش فنی تفصیلی، هر یافته با اثبات مفهوم تکرارپذیر
  • یافته‌های وب‌اپلیکیشن با نگاشت به OWASP WSTG
  • یافته‌های service worker و ذخیره‌سازی آفلاینِ ویژه‌ی PWA
  • بازبینی manifest، زمینه‌ی امن و هدرهای امنیتی
  • شدت CVSS و اثر کسب‌وکار برای هر یافته
  • نقشه‌ی راه رفع با اولویت
  • تست مجدد پس از رفع

چرا وادی ایمن حافظ

عمق PWA و وب
کل اپلیکیشن را می‌آزماییم، نه فقط ویژگی‌های چشمگیر را؛ وب‌اپ زیرین جایی است که بیشتر ریسک واقعی در آن است و لایه‌ی PWA جایی که بقیه در آن پنهان می‌شود.
تخصص service worker و آفلاین
می‌دانیم service worker چگونه ترافیک را رهگیری می‌کند و ذخیره‌سازی آفلاین چگونه داده را روی دستگاه نگه می‌دارد، پس خطرهایی را می‌یابیم که یک اسکنر عمومی وب هرگز به سراغشان نمی‌رود.
پوشش استانداردمحور
تست وب از OWASP WSTG پیروی می‌کند، پس پوشش به‌جای سلیقه‌ای بودن، روشن و قابل بررسی است.
یافته‌های قابل اجرا و اولویت‌دار
راهنمایی روشن و اولویت‌بندی‌شده بر پایه‌ی ریسک، با اثبات مفهوم تکرارپذیر و یک رفع مشخص برای هر یافته.

سوالات متداول

ارزیابی امنیت PWA چیست؟

یک اپلیکیشن وب پیشرونده را با استفاده از OWASP WSTG برای بخش وب، به‌علاوه‌ی سطح افزوده‌ای که PWA می‌سازد (service worker، ذخیره‌سازی آفلاین، manifest، push و background sync) برای ضعف‌های امنیتی می‌آزماید، و هر یافته اثبات و رتبه‌بندی می‌شود.

تست یک PWA با تست یک وب‌اپلیکیشن معمولی چه تفاوتی دارد؟

یک PWA پیش از هر چیز یک وب‌اپ است، پس به تست کامل وب نیاز دارد. افزون بر آن، service worker، کش‌های آفلاین و ذخیره‌سازی روی دستگاه خطرهایی می‌افزایند که یک تست معمولی وب به آن‌ها نگاه نمی‌کند: کش‌های مسموم، داده‌ی حساسِ نگه‌داشته‌شده به‌صورت آفلاین، و service workerی با scope بیش از حد باز.

از چه استانداردهایی پیروی می‌کنید؟

راهنمای OWASP WSTG برای بخش وب، و راهنمای به‌روز امنیت PWA برای service worker، ذخیره‌سازی، manifest و ویژگی‌های زمینه‌ی امن.

چه دسترسی‌ای لازم دارید و آیا تست جعبه‌سفید ارائه می‌دهید؟

می‌توانیم جعبه‌سیاه از بیرون، جعبه‌خاکستری با یک حساب آزمایشی برای هر نقش، یا جعبه‌سفید با دسترسی به کد کار کنیم. انتخاب معمول جعبه‌خاکستری است؛ جعبه‌سفید با کد، عمیق‌ترین پوشش را از منطق سمت‌کاربر و service worker می‌دهد. پیش از شروع، عمق و دامنه را توافق می‌کنیم.

خطر امنیتی یک service worker چیست؟

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

آیا داده‌ای که آفلاین نگه داشته می‌شود یک خطر است؟

می‌تواند باشد. داده‌ی ذخیره‌شده در Cache Storage، IndexedDB یا local storage روی دستگاه می‌ماند و برای هر اسکریپتی که در همان مبدأ اجرا شود خواندنی است، و روی یک دستگاه مشترک یا گم‌شده، برای هرکسی که آن را در دست دارد. بررسی می‌کنیم چه چیزی ذخیره می‌شود، آیا لازم است، و آیا محافظت شده است.

آیا سیاست امنیت محتوا و هدرهای امنیتی را بازبینی می‌کنید؟

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

شدت یافته‌ها چگونه تعیین می‌شود؟

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

آیا تست مجدد پس از رفع انجام می‌شود و چقدر طول می‌کشد؟

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

آماده شروع هستید؟
با تیم ما تماس بگیرید تا در مورد نیازهای ارزیابی امنیتی شما صحبت کنیم