ارزیابی امنیت GraphQL، این APIها را هم در برابر OWASP API Security Top 10 می‌سنجد — همان ضعف‌های کنترل دسترسی و منطق کسب‌وکار که غالبِ رخنه‌های APIاند — و هم در برابر ریسک‌های ویژه‌ی خودِ GraphQL: introspectionِ schema که کل نقشه را به مهاجم می‌دهد، عمق و پیچیدگی و batchingِ query که یک درخواست را به منع سرویس تبدیل می‌کند، و مجوزدهی‌ای که به‌جای هر endpoint در هر resolver اعمال می‌شود. چون یک endpoint واحدِ GraphQL کل گراف را در معرض می‌گذارد، نبود یک بررسی روی یک field می‌تواند داده‌ی کاربر دیگر را افشا کند. کار را با رفتار واقعی API می‌سنجیم، هر یافته را تا اثبات عملی دنبال می‌کنیم و شدت آن را با CVSS در کنار اثر واقعی بر کسب‌وکار تعیین می‌کنیم.
چه چیزی شامل می‌شود
مجوزدهی سطح field و شیء (BOLA/BFLA) در queryها و mutationها
افشای introspection و آنچه schema در محیط تولید آشکار می‌کند
محدودیت عمق، پیچیدگی و هزینه‌ی query — منع سرویس با queryهای تو در تو
سوءاستفاده از batching و aliasing، از جمله حمله‌ی جست‌وجوی فراگیر در یک درخواست
احراز هویت شکسته در queryها، mutationها و subscriptionها
تزریق که از راه resolver به پایگاه‌داده و سرویس‌های پایین‌دست می‌رسد
افشای بیش از حد داده و mass assignment از راه input typeها
مدیریت خطا و افشای اطلاعات در پاسخ‌ها
کنترل‌های محدودیت نرخ و مصرف منابع
بازبینی schema در برابر رفتار واقعی API
چگونه کار می‌کند
- خلاصه‌ی اجرایی با نمای کلی ریسک برای تصمیم‌گیرندگان
- گزارش فنی تفصیلی، هر یافته با اثبات مفهوم تکرارپذیر
- نگاشت یافته‌ها به OWASP API Security Top 10 و ریسک‌های خاص GraphQL
- شدت CVSS و اثر کسب‌وکار برای هر یافته
- توصیه‌های پیچیدگی و عمق query و محدودیت نرخ
- راهنمای سخت‌سازی schema و resolver
- نقشه‌ی راه رفع با اولویت و گام‌های مشخص
- تست مجدد پس از رفع
چرا وادی ایمن حافظ
سوالات متداول
ارزیابی امنیت GraphQL، یک GraphQL API را برای ضعف‌های امنیتی می‌سنجد: نقص‌های مجوزدهی سطح field و شیء، افشای introspection، منع سرویس با پیچیدگی query و batching، تزریق از راه resolver و افشای اطلاعات؛ در برابر OWASP API Security Top 10 و راهنمای OWASP برای GraphQL، و هر یافته اثبات و رتبه‌بندی می‌شود.
یک REST API چند endpoint در معرض می‌گذارد؛ یک GraphQL API معمولاً یک endpoint که کل گراف از راه آن در دسترس است. مجوزدهی به‌جای هر مسیر در هر resolver اعمال می‌شود، پس یک بررسیِ جاافتاده یک field را هر جا که ظاهر شود افشا می‌کند، و موتور query ریسک‌هایی می‌افزاید که تست REST ندارد: introspection، عمق و پیچیدگی query و batching. استاندارد مرجع همچنان OWASP API Security Top 10 است که بر گراف اعمال می‌شود.
introspection توانایی درونی GraphQL برای توصیف schema خودش است — هر type، field و آرگومان. در توسعه مفید است اما در تولید یک نقشه‌ی کامل از API را به مهاجم می‌دهد. غیرفعال‌کردن آن در تولید کار را سخت‌تر می‌کند؛ اما جایگزین اعمال مجوزدهی نیست، چون گراف را همچنان می‌توان با حدس‌زدن کاوید، و به همین دلیل هر دو را تست می‌کنیم.
GraphQL به کلاینت اجازه می‌دهد داده‌ی عمیقاً تو در تو و مرتبط را در یک درخواست بخواهد. بدون محدودیت عمق، پیچیدگی یا هزینه، یک queryِ ساخته‌شده — یا چند queryِ aliasشده که با هم batch شده‌اند — می‌تواند سرور را به کار سنگین وادارد و از پا درآورد. می‌سنجیم که این محدودیت‌ها هستند و پابرجا می‌مانند، و آستانه‌های مشخص پیشنهاد می‌دهیم.
نشانی endpoint و محیط GraphQL، schema یا دسترسی introspection در صورت وجود، و حساب‌های آزمایشی برای هر نقش (دست‌کم دو کاربر در هر نقش تا دسترسی میان‌کاربری را بسنجیم). یک محیط staging که آینه‌ی تولید باشد بهترین حالت است. پیش از شروع، دامنه و هر mutationی را که باید کنار گذاشته شود توافق می‌کنیم.
جعبه‌سیاه یعنی بدون دانش درونی تست می‌کنیم؛ جعبه‌سفید یعنی schema، مستندات و گاه کد منبع را هم داریم؛ جعبه‌خاکستری میان این دو است و معمولاً با اعتبارنامه و schema انجام می‌شود. برای GraphQL معمولاً جعبه‌خاکستری را پیشنهاد می‌کنیم: با در دست داشتن نقش‌ها و schema، ضعف‌های مجوزدهی در هر resolver را بسیار کامل‌تر و در زمان کمتری نسبت به تست کور پوشش می‌دهیم.
هر یافته یک امتیاز CVSS برای یک مبنای مشترک می‌گیرد که با اثر واقعی کسب‌وکار در بافت شما تعدیل می‌شود: چه داده یا عملیاتی را افشا می‌کند، چقدر آسان به آن می‌رسند و مهاجم چه به دست می‌آورد. به همین دلیل دو مسئله با CVSS یکسان ممکن است اولویت متفاوت بگیرند.
ترجیح ما محیط staging است که آینه‌ی تولید باشد. اگر تست ناچار روی تولید انجام شود، محدودیت‌ها را از پیش توافق می‌کنیم: بدون mutationهای مخرب، احتیاط در آزمون‌های پیچیدگی و batching که می‌توانند سرور را بار کنند، و یک نقطه‌ی تماس در سمت شما برای توقف فوری اگر چیزی نادرست به نظر رسید.
به اندازه‌ی schema، تعداد نقش‌ها و پیچیدگی منطق کسب‌وکار بستگی دارد؛ یک ارزیابی معمول حدود دو تا سه هفته طول می‌کشد. پس از دامنه‌گذاری و روشن‌شدن schema و تعداد نقش، برآورد دقیق می‌دهیم.
سرویس‌های مرتبط
خدمات تکمیلی که ممکن است برای شما مفید باشند