ارزیابی امنیتی و آزمون نفوذ API
ما با استفاده از OWASP API Security Top 10، آسیبپذیریهای REST API و GraphQL شامل BOLA/IDOR، احراز هویت شکسته، افشای داده و نقصهای Rate Limiting را شناسایی و ارزیابی میکنیم.
خدمات ارزیابی امنیتی و آزمون نفوذ API
انتخاب سرویس متناسب با نوع API سازمان شما
پوشش کامل OWASP API Security Top 10 (2023)
تستهای ما تمام ده ریسک امنیتی برتر OWASP برای APIها را پوشش میدهد
شکست مجوز سطح شیء
احراز هویت شکسته
شکست مجوز سطح ویژگی
مصرف منابع نامحدود
شکست مجوز سطح تابع
دسترسی نامحدود به جریانهای حساس
جعل درخواست سمت سرور
پیکربندی نادرست امنیتی
مدیریت نادرست فهرست
مصرف ناامن APIها
چرا امنیت API مهم است؟
APIها قلب اپلیکیشنهای مدرن هستند و دسترسی مستقیم به دادههای حساس فراهم میکنند
اپلیکیشنهای مدرن به شدت به APIها وابسته هستند. اپهای موبایل، SPAها، میکروسرویسها و دستگاههای IoT همه از طریق API ارتباط برقرار میکنند و آنها را به اهداف حمله بحرانی تبدیل میکند.
APIها دسترسی مستقیم به دادههای بکاند و منطق تجاری فراهم میکنند. یک آسیبپذیری میتواند میلیونها رکورد را افشا کند یا اقدامات غیرمجاز را ممکن سازد.
شکست مجوز سطح شیء (BOLA) ریسک شماره ۱ API است. مهاجمان میتوانند با دستکاری ID اشیاء در درخواستهای API به دادههای کاربران دیگر دسترسی پیدا کنند.
APIها اغلب endpointهای مستندنشده، ویژگیهای دیباگ یا نسخههای قدیمی را افشا میکنند. این endpointهای پنهان اغلب هدف مهاجمان هستند.
پوشش انواع API
تستهای تخصصی برای REST API و GraphQL
- احراز هویت و مجوزدهی
- تست BOLA/IDOR
- Rate Limiting و Throttling
- Input Validation
- Mass Assignment
- نشت اطلاعات حساس
- HTTP Method Tampering
- CORS Configuration
- Introspection Security
- Query Depth Limiting
- Query Complexity Analysis
- Field-level Authorization
- Batching Attacks
- Alias-based DoS
- Injection در Queries
- Schema Exposure
متدولوژیهای تخصصی API
ما از چارچوبهای معتبر جهانی برای ارزیابی امنیت API استفاده میکنیم
ده ریسک برتر امنیتی API (۲۰۲۳) - استاندارد صنعتی
برای شناسایی ریسکهای APIاستاندارد اعتبارسنجی امنیت اپلیکیشن - بخش API
برای اعتبارسنجی امنیتیراهنمای تست امنیت وب - بخش تست API
برای تست جامع APIبررسی امنیتی اسناد OpenAPI/Swagger
برای ارزیابی مستندات APIچه چیزهایی را تست میکنیم؟
پوشش جامع تمام جنبههای امنیتی API بر اساس OWASP API Security Top 10
- JWT Security
- OAuth 2.0 Flows
- API Keys
- Token Expiration
- Refresh Token Security
- 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
- URL parameters
- Webhooks
- Import from link
- Cloud metadata endpoints
- Excessive data in responses
- Error and stack traces
- Debug endpoints
- Sensitive headers
- CORS policy
- TLS configuration
- HTTP headers
- Verb tampering
- Documentation exposure
- Deprecated versions
- Undocumented endpoints
- Non-production hosts
- Unvalidated upstream responses
تست با چه چیزی شروع شود؟
هرچه تیم زودتر بداند چه چیزی وجود دارد، زمان بیشتری صرف سنجیدن آن میشود.
نزدیکترین حالت به مهاجم بیرونی، و تنها راه فهمیدن اینکه چه چیزی بدون مستندسازی در دسترس است. زمانی صرف کشف میشود که میتوانست صرف تست شود.
انتخاب معمول. در همان زمان پوشش بسیار بیشتری به دست میآید و مجوزدهی درست سنجیده میشود، چون چند فراخوان برای مقایسه وجود دارد.
برای منطقی که از بیرون قابل استنتاج نیست، و برای اطمینان از اینکه اصلاً بررسی مجوز وجود دارد یا نه، بهجای حدس زدن از روی پاسخها.
دامنهی ارزیابی و آنچه از شما لازم است
کیفیت نتیجه بیش از هر چیز به آمادهبودن این چند مورد بستگی دارد.
یک فایل OpenAPI یا Swagger، یا مجموعهای در Postman، یا نمونهای از ترافیک واقعی. بدون یکی از اینها، روزهای نخست صرف کشف چیزی میشود که وجود دارد.
مجوزدهی در سطح شیء نخستین مورد OWASP API Top 10 است و با یک حساب قابل آزمون نیست. برای هر نقش دو حساب همسطح، و برای هر سطح دسترسی یک حساب.
آزمون محدودیت منابع یعنی فرستادن ترافیکی که شبیه سوءاستفاده است. روی محیط عملیاتی این کار ساعت توافقشده میخواهد و روی محیط آزمایشی، دادهای که شبیه دادهی واقعی باشد.
اگر دروازهی API یا WAF بر اساس نشانی محدودیت نرخ اعمال میکند، برای بخشی از تست نشانی ما مجاز میشود تا آنچه سنجیده میشود خود API باشد نه دروازه.
در هر دو طرف یک نفر مسئول ارتباط. endpoint مدیریتیِ در معرض دید، همان روزی که پیدا شود گزارش میشود، نه در گزارش نهایی.
شدت هر یافته چطور تعیین میشود
عددی که پشتش روشی نباشد، به تصمیمگیری دربارهی ترتیب رفع کمکی نمیکند.
هر یافته با CVSS v3.1 امتیاز میگیرد تا زبان مشترکی با تیم فنی شما و ابزارهایی که از پیش دارید وجود داشته باشد.
یک ضعف روی endpointی که فقط جستوجو میکند با همان ضعف روی endpointی که پول جابهجا میکند یک یافته نیست. امتیاز پایه با داده و عملیاتی که پشت آن است تنظیم میشود.
هر یافته با درخواست و پاسخی همراه است که آن را نشان میدهد. چیزی که بازتولید نشود، بهعنوان یافتهی قطعی گزارش نمیشود.
گزارش ترتیب کار را پیشنهاد میدهد: چه چیزی باید پیش از انتشار بعدی رفع شود و چه چیزی میتواند برای نسخهی بعد از آن بماند.
فرآیند کار ما
رویکرد ساختاریافته ما برای ارزیابی امنیت API
ما تمام endpointهای API را با استفاده از مستندات، تحلیل ترافیک و fuzzing ترسیم میکنیم. endpointهای پنهان، نسخههای منسوخ و ویژگیهای مستندنشده را شناسایی میکنیم.
با استفاده از ابزارهای تخصصی امنیت API، تست خودکار برای آسیبپذیریهای رایج، محدودسازی نرخ و مشکلات احراز هویت انجام میدهیم.
تست دستی تخصصی برای نقصهای منطق تجاری، BOLA/IDOR، دور زدن مجوز و زنجیرههای حمله پیچیده که ابزارهای خودکار از دست میدهند.
گزارش دقیق با امتیازات CVSS، رفع خاص API، کالکشنهای Postman/Swagger و تست مجدد رایگان پس از اصلاحات.
تحویلدادنیهای پروژه
گزارشهای جامع و عملیاتی برای تیمهای فنی و مدیریتی
خلاصه مدیریتی
اینکه چه چیزی تست شد، چه یافته شد، و این یافتهها برای کسبوکار چه معنایی دارد، به زبانی که خوانندهی غیرفنی بتواند بر اساس آن تصمیم بگیرد.
گزارش فنی
هر یافته با امتیاز CVSS v3.1، همان درخواست و پاسخی که آن را نشان میدهد، و endpoint و متدی که تحت تأثیر است.
کالکشن API
مجموعهای در Postman از درخواستهایی که هر یافته را بازتولید میکنند، تا مهندسان شما بدون منتظر ماندن برای ما بتوانند رفع مشکل را بررسی کنند.
تست مجدد رایگان
پس از رفع، هر یافته دوباره تست میشود و یا بستهشدن آن تأیید میشود یا با توضیح اینکه چه چیزی هنوز کار میکند دوباره باز میشود، و گزارش بهروز میشود.
سوالات متداول
ما همه انواع APIها را تست میکنیم شامل REST API، GraphQL API، سرویسهای وب SOAP/XML، gRPC API، WebSocket API و پیادهسازیهای webhook. تست ما هم APIهای عمومی و هم APIهای داخلی/میکروسرویس را پوشش میدهد. ما با هر API بدون توجه به استک فناوری یا فریمورک استفاده شده کار میکنیم.
BOLA (شکست مجوز سطح شیء) که به IDOR هم معروف است، زمانی رخ میدهد که API به درستی تأیید نمیکند که کاربر درخواستکننده مجوز دسترسی به یک شیء خاص را دارد. مثلاً تغییر /api/users/123 به /api/users/456 برای دسترسی به دادههای کاربر دیگر. این ریسک شماره ۱ است چون بسیار رایج، آسان برای سوءاستفاده و میتواند منجر به نقض داده گسترده شود.
GraphQL نگرانیهای امنیتی منحصربهفردی دارد: کوئریهای introspection میتوانند کل schema را افشا کنند، کوئریهای تودرتو میتوانند از طریق حملات پیچیدگی DoS ایجاد کنند، batching حملات brute-force را ممکن میسازد و مجوزدهی سطح فیلد اغلب نادیده گرفته میشود. ما برای آسیبپذیریهای خاص GraphQL شامل حملات عمق کوئری، DoS مبتنی بر alias و mutationها بدون مجوز مناسب تست میکنیم.
مستندات (OpenAPI/Swagger، کالکشنهای Postman) به تسریع تست کمک میکند، اما الزامی نیست. ما میتوانیم endpointهای API را از طریق تحلیل ترافیک، مهندسی معکوس اپ موبایل یا بررسی وب اپلیکیشن کشف کنیم. ما اغلب endpointهای مستندنشده را پیدا میکنیم که در مستندات رسمی نیستند اما همچنان قابل دسترسی هستند.
زمانبندی به پیچیدگی و دامنه API بستگی دارد. ارزیابی یک REST API معمولی با ۲۰-۵۰ endpoint حدود ۱-۲ هفته طول میکشد. APIهای پیچیده با روشهای احراز هویت متعدد، منطق تجاری گسترده یا GraphQL حدود ۲-۳ هفته نیاز دارند. معماریهای میکروسرویس بزرگ ممکن است ۴+ هفته نیاز داشته باشند. ما تخمین دامنه دقیق را در مشاوره اولیه ارائه میدهیم.
ما از ابزارهای پیشرو صنعت استفاده میکنیم شامل Burp Suite با افزونههای خاص API، Postman برای تعامل با API، OWASP ZAP برای اسکن خودکار، اسکریپتهای سفارشی Python/Go برای fuzzing، ابزارهای خاص GraphQL مانند InQL و GraphQL Voyager و ابزارهای تخصصی برای تست JWT و تحلیل rate limit.
بله، ما تجربه گستردهای در تست جریانهای OAuth 2.0 (Authorization Code، PKCE، Client Credentials)، OpenID Connect، احراز هویت مبتنی بر JWT، طرحهای API key و مکانیزمهای احراز هویت سفارشی داریم. ما برای نشت توکن، اعتبارسنجی نادرست توکن، دور زدن scope و سایر آسیبپذیریهای احراز هویت تست میکنیم.
شما دریافت میکنید: خلاصه مدیریتی، گزارش فنی با امتیازات CVSS و درخواستهای PoC، راهنمای رفع با نمونه کد، کالکشن Postman/Swagger تمام endpointهای تست شده، فهرست API با رتبهبندی ریسک و نقشهبرداری انطباقی. به علاوه جلسه توضیح گزارش و تست مجدد رایگان.
بله، ما هم APIهای خارجی و هم داخلی را تست میکنیم. APIهای داخلی اغلب فاقد احراز هویت مناسب هستند با این فرض که "فقط داخلی" هستند، اما مهاجمانی که محیط را نقض میکنند میتوانند از اینها سوءاستفاده کنند. ما میتوانیم با دسترسی VPN، محیطهای تست یا API gatewayها برای ارزیابی امنیت API داخلی شما کار کنیم.
هزینه به این عوامل بستگی دارد: تعداد endpointها، پیچیدگی API (REST در برابر GraphQL در برابر gRPC)، مکانیزمهای احراز هویت، نیاز به تست منطق تجاری و الزامات انطباقی. ارزیابی پایه REST API از یک نقطه قیمت شروع میشود، در حالی که تست جامع معماریهای میکروسرویس پیچیده هزینه بیشتری دارد. برای مشاوره رایگان و قیمت دقیق با ما تماس بگیرید.
الزامی نیست، اما تعیین میکند که زمان صرف چه چیزی شود. با فایل مشخصات، مجموعهای در Postman یا نمونهای از ترافیک واقعی، کار از همان ابتدا روی تست شروع میشود. بدون آن، بخش نخست پروژه صرف کشف چیزی میشود که وجود دارد، و هر endpoint مستندنشدهای که پیدا نکنیم آزموننشده میماند.
چون مجوزدهی شکسته در سطح شیء نخستین مورد OWASP API Top 10 است و با یک حساب نمیتوان آن را نشان داد. آزمون این است که آیا کاربر الف میتواند دادهی کاربر ب را بخواند یا تغییر دهد، و برای این کار به یک «ب» واقعی نیاز است.
دروازه تعیین میکند چیزی با چه سرعتی صدا زده شود، اما تصمیم نمیگیرد که آن فراخوان اصلاً مجاز بوده است یا نه. مجوزدهی، منطق کسبوکار و دادهای که در پاسخ برمیگردد پشت دروازه مینشینند و از آن تأثیر نمیگیرند. به همین دلیل بخشی از تست با عبور دادن نشانی ما انجام میشود تا خودِ API سنجیده شود نه دروازهی جلوی آن.
بله، با ساعتها و محدودیتهایی که از پیش توافق شده باشد. دو بخش دقت میخواهد: آزمون محدودیت منابع یعنی فرستادن ترافیکی که شبیه سوءاستفاده است، و هر عملیاتی که چیزی مینویسد نیاز به توافق دارد دربارهی اینکه چه چیزی ساخته شود و بعد چطور پاک شود.