ارزیابی ترکیبی موبایل + API

یک اپلیکیشن موبایل و بک‌اند API آن را به‌عنوان یک سامانه‌ی واحد می‌آزماید. اپلیکیشن با OWASP MASVS و MASTG، و API با OWASP API Security Top 10 تست می‌شود، و سپس جریان‌هایی که از مرز میان آن‌ها می‌گذرند؛ احراز هویت، توکن‌ها و اعمال سمت‌سرور؛ و هر یافته اثبات و رتبه‌بندی می‌شود.

آسیب‌زننده‌ترین مسائل در مرز جای دارند. واسط اپلیکیشن کنش‌ها و فیلدها را پنهان می‌کند، پس تستی که فقط اپلیکیشن را به کار می‌گیرد آن‌ها را از دست می‌دهد، اما API همچنان آن‌ها را در معرض می‌گذارد. تست هر دو با هم به ما امکان می‌دهد درخواست‌های خودِ اپلیکیشن را مستقیماً بفرستیم و بررسی کنیم که آیا سرور همان قواعدی را که اپلیکیشن به‌ظاهر اعمال می‌کند اجرا می‌کند.

مجوزدهی سطح شیء شکسته زمانی است که API بر پایه‌ی یک شناسه در درخواست، شیئی را برمی‌گرداند یا تغییر می‌دهد بدون این‌که بررسی کند فراخواننده مالک آن است. شناسه را عوض می‌کنید و به داده‌ی کسی دیگر می‌رسید. این بالاترین خطر API است، پس آن را مستقیماً با یک حساب دوم در برابر حساب اول می‌آزماییم.

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

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

همان APIی را که اپلیکیشن واقعاً به کار می‌برد می‌آزماییم، چه REST باشد، چه GraphQL و چه سبکی دیگر. خطرهای مجوزدهی و احراز هویت در API Security Top 10 در همه‌ی سبک‌ها صدق می‌کنند؛ شیوه‌ی به‌کارگیری آن‌ها با واسط سازگار می‌شود.

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

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

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