ارزیابی امنیتی و آزمون نفوذ API

ما با استفاده از OWASP API Security Top 10، آسیب‌پذیری‌های REST API و GraphQL شامل BOLA/IDOR، احراز هویت شکسته، افشای داده و نقص‌های Rate Limiting را شناسایی و ارزیابی می‌کنیم.

OWASP API Top 10OWASP ASVSREST & GraphQLCVSS Scoring
OpenAPI
بازبینی مشخصات API
۱۰ از ۱۰
ریسک OWASP API Top 10
۲۸۶
کنترل OWASP ASVS
۴
متدولوژی مرجع

پوشش کامل OWASP API Security Top 10 (2023)

تست‌های ما تمام ده ریسک امنیتی برتر OWASP برای APIها را پوشش می‌دهد

API1

شکست مجوز سطح شیء

API2

احراز هویت شکسته

API3

شکست مجوز سطح ویژگی

API4

مصرف منابع نامحدود

API5

شکست مجوز سطح تابع

API6

دسترسی نامحدود به جریان‌های حساس

API7

جعل درخواست سمت سرور

API8

پیکربندی نادرست امنیتی

API9

مدیریت نادرست فهرست

API10

مصرف ناامن APIها

چرا امنیت API مهم است؟

APIها قلب اپلیکیشن‌های مدرن هستند و دسترسی مستقیم به داده‌های حساس فراهم می‌کنند

APIها همه جا هستند

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

دسترسی مستقیم به داده

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

ریسک‌های BOLA/IDOR

شکست مجوز سطح شیء (BOLA) ریسک شماره ۱ API است. مهاجمان می‌توانند با دستکاری ID اشیاء در درخواست‌های API به داده‌های کاربران دیگر دسترسی پیدا کنند.

سطح حمله پنهان

APIها اغلب endpointهای مستندنشده، ویژگی‌های دیباگ یا نسخه‌های قدیمی را افشا می‌کنند. این endpointهای پنهان اغلب هدف مهاجمان هستند.

پوشش انواع API

تست‌های تخصصی برای REST API و GraphQL

REST API
  • احراز هویت و مجوزدهی
  • تست BOLA/IDOR
  • Rate Limiting و Throttling
  • Input Validation
  • Mass Assignment
  • نشت اطلاعات حساس
  • HTTP Method Tampering
  • CORS Configuration
GraphQL
  • Introspection Security
  • Query Depth Limiting
  • Query Complexity Analysis
  • Field-level Authorization
  • Batching Attacks
  • Alias-based DoS
  • Injection در Queries
  • Schema Exposure

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

پوشش جامع تمام جنبه‌های امنیتی API بر اساس OWASP API Security Top 10

احراز هویت
اینکه فراخوان چطور هویتش را ثابت می‌کند، و وقتی آن اثبات قدیمی، کپی‌شده یا جعلی باشد چه اتفاقی می‌افتد.
  • JWT Security
  • OAuth 2.0 Flows
  • API Keys
  • Token Expiration
  • Refresh Token Security
مجوزدهی در سطح شیء
نخستین مورد در OWASP API Top 10. با دو حساب هم‌سطح تست می‌شود، چون یک حساب به‌تنهایی نشان نمی‌دهد که آیا به داده‌ی حساب دیگر می‌رسد یا نه.
  • BOLA / IDOR
  • Predictable identifiers
  • Ownership checks
  • Nested resources
مجوزدهی در سطح عملیات و فیلد
اینکه آیا فراخوانی با دسترسی پایین می‌تواند به عملیات مدیریتی برسد، و آیا می‌تواند فیلدی را بنویسد که فقط باید بخواند.
  • Admin endpoints
  • HTTP method tampering
  • Mass assignment
  • Read-only field writes
اعتبارسنجی ورودی
هر جایی که مقداری از درخواست به یک مفسر، یک تجزیه‌گر یا یک مسیر فایل می‌رسد.
  • SQL / NoSQL injection
  • Command injection
  • XXE
  • Deserialization
  • Parameter pollution
مصرف منابع
اینکه یک فراخوان چقدر می‌تواند سرویس را به خرج بیندازد: پردازنده، حافظه، هزینه‌ی سرویس‌های طرف سوم، و پیام‌هایی که به نام شما فرستاده می‌شود.
  • Rate limit bypass
  • Oversized payloads
  • Expensive queries
  • Costly third-party calls
جریان‌های حساس کسب‌وکار
یک عملیات می‌تواند کاملاً درست باشد و باز هم وقتی خودکار اجرا شود سوءاستفاده‌پذیر باشد: خرید انبوه، رزرو انبوه، ثبت‌نام انبوه.
  • Automation abuse
  • Workflow step skipping
  • Race conditions
  • Business limits
جعل درخواست سمت سرور
جایی که API نشانی‌ای را که فراخوان داده واکشی می‌کند، و اینکه در آن لحظه از داخل شبکه‌ی شما به چه چیزی می‌رسد.
  • URL parameters
  • Webhooks
  • Import from link
  • Cloud metadata endpoints
افشای داده
اینکه پاسخ فراتر از آنچه صفحه نمایش می‌دهد چه چیزی حمل می‌کند، و خطاها چه چیزی از درون سامانه فاش می‌کنند.
  • Excessive data in responses
  • Error and stack traces
  • Debug endpoints
  • Sensitive headers
پیکربندی
تنظیمات پیرامون API و نه کد آن: چه کسی از کجا، روی چه چیزی و با کدام متدها می‌تواند آن را صدا بزند.
  • CORS policy
  • TLS configuration
  • HTTP headers
  • Verb tampering
  • Documentation exposure
فهرست نسخه‌ها و APIهای طرف سوم
نسخه‌های قدیمی که هنوز پاسخ می‌دهند، میزبان‌های آزمایشی که از بیرون در دسترس‌اند، و APIهایی که API شما بدون بررسی به آن‌ها اعتماد می‌کند.
  • Deprecated versions
  • Undocumented endpoints
  • Non-production hosts
  • Unvalidated upstream responses

تست با چه چیزی شروع شود؟

هرچه تیم زودتر بداند چه چیزی وجود دارد، زمان بیشتری صرف سنجیدن آن می‌شود.

بدون مشخصات
کشف endpointها از بیرون

نزدیک‌ترین حالت به مهاجم بیرونی، و تنها راه فهمیدن اینکه چه چیزی بدون مستندسازی در دسترس است. زمانی صرف کشف می‌شود که می‌توانست صرف تست شود.

مشخصات و حساب کاربری
OpenAPI یا مجموعه‌ی درخواست‌ها، به‌همراه یک حساب برای هر نقش

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

مشخصات، حساب و کد
همه‌ی موارد بالا، به‌همراه کد

برای منطقی که از بیرون قابل استنتاج نیست، و برای اطمینان از اینکه اصلاً بررسی مجوز وجود دارد یا نه، به‌جای حدس زدن از روی پاسخ‌ها.

دامنه‌ی ارزیابی و آنچه از شما لازم است

کیفیت نتیجه بیش از هر چیز به آماده‌بودن این چند مورد بستگی دارد.

مشخصات API، یا خود درخواست‌ها

یک فایل OpenAPI یا Swagger، یا مجموعه‌ای در Postman، یا نمونه‌ای از ترافیک واقعی. بدون یکی از این‌ها، روزهای نخست صرف کشف چیزی می‌شود که وجود دارد.

برای هر سطح، دو حساب

مجوزدهی در سطح شیء نخستین مورد OWASP API Top 10 است و با یک حساب قابل آزمون نیست. برای هر نقش دو حساب هم‌سطح، و برای هر سطح دسترسی یک حساب.

محیطی که بار را تحمل کند

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

دروازه‌ای که اجازه‌ی عبور بدهد

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

مسیری برای گزارش فوری

در هر دو طرف یک نفر مسئول ارتباط. endpoint مدیریتیِ در معرض دید، همان روزی که پیدا شود گزارش می‌شود، نه در گزارش نهایی.

شدت هر یافته چطور تعیین می‌شود

عددی که پشتش روشی نباشد، به تصمیم‌گیری درباره‌ی ترتیب رفع کمکی نمی‌کند.

امتیاز CVSS نقطه‌ی شروع است

هر یافته با CVSS v3.1 امتیاز می‌گیرد تا زبان مشترکی با تیم فنی شما و ابزارهایی که از پیش دارید وجود داشته باشد.

سپس آنچه آن endpoint به آن می‌رسد

یک ضعف روی endpointی که فقط جست‌وجو می‌کند با همان ضعف روی endpointی که پول جابه‌جا می‌کند یک یافته نیست. امتیاز پایه با داده و عملیاتی که پشت آن است تنظیم می‌شود.

اثبات‌شده، نه حدس

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

ترتیب رفع

گزارش ترتیب کار را پیشنهاد می‌دهد: چه چیزی باید پیش از انتشار بعدی رفع شود و چه چیزی می‌تواند برای نسخه‌ی بعد از آن بماند.

فرآیند کار ما

رویکرد ساختاریافته ما برای ارزیابی امنیت API

1
کشف API

ما تمام endpointهای API را با استفاده از مستندات، تحلیل ترافیک و fuzzing ترسیم می‌کنیم. endpointهای پنهان، نسخه‌های منسوخ و ویژگی‌های مستندنشده را شناسایی می‌کنیم.

2
اسکن خودکار

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

3
تست دستی

تست دستی تخصصی برای نقص‌های منطق تجاری، BOLA/IDOR، دور زدن مجوز و زنجیره‌های حمله پیچیده که ابزارهای خودکار از دست می‌دهند.

4
گزارش‌دهی و تست مجدد

گزارش دقیق با امتیازات CVSS، رفع خاص API، کالکشن‌های Postman/Swagger و تست مجدد رایگان پس از اصلاحات.

تحویل‌دادنی‌های پروژه

گزارش‌های جامع و عملیاتی برای تیم‌های فنی و مدیریتی

خلاصه مدیریتی

اینکه چه چیزی تست شد، چه یافته شد، و این یافته‌ها برای کسب‌وکار چه معنایی دارد، به زبانی که خواننده‌ی غیرفنی بتواند بر اساس آن تصمیم بگیرد.

گزارش فنی

هر یافته با امتیاز CVSS v3.1، همان درخواست و پاسخی که آن را نشان می‌دهد، و endpoint و متدی که تحت تأثیر است.

کالکشن API

مجموعه‌ای در Postman از درخواست‌هایی که هر یافته را بازتولید می‌کنند، تا مهندسان شما بدون منتظر ماندن برای ما بتوانند رفع مشکل را بررسی کنند.

تست مجدد رایگان

پس از رفع، هر یافته دوباره تست می‌شود و یا بسته‌شدن آن تأیید می‌شود یا با توضیح اینکه چه چیزی هنوز کار می‌کند دوباره باز می‌شود، و گزارش به‌روز می‌شود.

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

چه نوع APIهایی را تست می‌کنید؟
BOLA چیست و چرا ریسک شماره ۱ API است؟
تست امنیت GraphQL چه تفاوتی با تست REST API دارد؟
آیا برای انجام تست به مستندات API نیاز دارید؟
ارزیابی امنیتی API چقدر زمان می‌برد؟
از چه ابزارهایی برای تست امنیت API استفاده می‌کنید؟
آیا می‌توانید APIهایی با احراز هویت پیچیده مانند OAuth 2.0 را تست کنید؟
پس از ارزیابی API چه تحویل‌دادنی‌هایی دریافت می‌کنیم؟
آیا APIهای داخلی/میکروسرویس را تست می‌کنید؟
هزینه تست نفوذ API چقدر است؟
آیا به فایل OpenAPI ما نیاز دارید؟
چرا برای هر سطح دو حساب می‌خواهید؟
ما دروازه‌ی API با محدودیت نرخ داریم. کافی است؟
آیا می‌توان تست را روی محیط عملیاتی اجرا کرد؟
آیا APIهای شما امن هستند؟
با تیم متخصص ما تماس بگیرید تا ارزیابی امنیتی جامع APIهای شما را انجام دهیم