خیلی از عزیزانی که تو حوزه تست نفوذ مشغول فعالیت هستن، با حوزه های تست نفوذ وب و موبایل آشنایی کافی دارن ولی وقتی اسم تست نفوذ API میاد، ممکنه که تصویر واضحی تو ذهنشون نقش نبنده. توی این پست میخوایم این تصویر رو واضح‌تر کنیم و منابعی رو معرفی میکنیم که میتونین مطالعه کنین تا تو این حوزه به مهارت خوبی دست پیدا کنید.
اول از همه همونطور که همه میدونین، بنیاد OWASP که برای حوزه‌های وب و موبایل لیست TOP10 خطرناکترین آسیب‌پذیری‌ها رو داره، تو سال ۲۰۱۹ برای API هم مستندی ۴۰ صفحه ای منتشر کرده که توی اون خطرناکترین آسیب‌پذیری‌های مربوط به API رو ذکر کرده که میتونید این داکیومنت رو از اینجا دانلود کنید. اما تو این پست نمی‌خوایم درباره این آسیب‌پذیری‌ها توضیح بدیم. هدف ما از این پست اینه که با تقسیم بندی یک سری نکات، شما رو در بهتر تست کردن API راهنمایی کنیم.
ترفند ۱: معمولا API که سامانه برای استفاده عمومی ازش استفاده میکنه، جدیدترین و به روزترین نسخه‌ای هست که برنامه‌نویس‌های back-end اونها رو نوشتن. اما نسخه‌های قدیمی‌تر هم ممکنه مورد استفاده قرار بگیرن که احتمال داره اون نسخه های قدیمی دارای آسیب‌پذیری باشن. برای پیدا کردن نسخه‌های قدیمی‌تر میتونین از ماهیت قابل حدس APIهای از نوع REST استفاده کنید. به عنوان مثال اگر API مورد نظرتون درخواست ها رو با URI مثل api/v3/login ارسال میکنه، ممکنه با تست api/v1/login به آسیب‌پذیری‌های بیشتری دست پیدا کنید.
ترفند ۲: آیا یادتون میاد که تقریبا ۵ تا ۱۰ سال قبل از هر وب سایتی میشد باگ SQLi گرفت و اطلاعات اون سازمان رو به سرقت برد؟! امروزه آسیب‌پذیری BOLA (که یه نوع آسیب پذیری از نوع IDOR هست) تو دنیای APIها اپیدمی شده. اگر خودتون رو پنتستر میدونین، شدیدا توصیه میکنیم که جزییات این آسیب پذیری رو از اینجا مطالعه کنین.
ترفند ۳: آسیب‌پذیری SSRF کشف کردین؟ میتونین از این آسیب‌پذیری برای انجام internal port scanning یا پیدا کردن سرویس ابری مورد استفاده (مثلا آدرس IP) یا دانلود فایل خیلی سنگین (حمله از نوع منع خدمت یا DoS) استفاده کنید!
ترفند ۴: واگذاری انبوه یا Mass Assignment نکته بسیار مهمی هست. فریم‌ورک‌های مدرن developerها را ترغیب می کنن بدون استفاده از پیامدهای امنیتی از MA استفاده کنن. با استفاده از درخواست از نوع GET که بتونه همه propertyها رو نشون بده، میتونین از این آسیب‌پذیری بهره برداری کنید!
ترفند ۵: درحال پنتست بر روی API از نوع REST هستید؟ این رو در نظر بگیرین که API احتمال داره از SOAP هم پشتیبانی کنه. فقط کافیه header مربوطه که Content-Type هست رو به مقدار application/xml تغییر بدین و یک XML ساده در بدنه درخواستتون اضافه کنین. احتمال داره در Response نکات جالبی رو مشاهده کنین. این نکته هم حائز اهمیت هست که امکان داره بعضی وقتا مکانیزم احراز هویت توی APIهای از نوع REST و SOAP به اشتراک گذاشته بشن. یعنی این امکان وجود داره که APIهای از نوع SOAP از JWT هم پشتیبانی کنن ! در هرصورت اگر پاسخ API به صورت stack trace بود، شما احتمالا آسیب‌پذیری پیدا کردین.
ترفند ۶: به نظر شما کدام قابلیت های API ممکن هست که آسیب‌پذیر باشن؟ به شخصه از این قسمت‌ها شروع میکنم :
– سیستم های مدیریت کاربران سازمانی
– انجام عملیات export به فایل های csv یا pdf یا html
– viewهای سفارشی از داشبورد
– اشتراک گذاری اشیاء (مثل عکس، پست یا غیره)
ترفند ۷: یک صفحه با درخواستی شبیه به api/news?limit=100 پیدا کردین؟ احتمال داره که این صفحه نسبت به حمله منع خدمت یا DoS در لایه ۷ آسیب پذیر باشه. اقدام به ارسال مقدار بزرگ کنید مثل limit=99999999 و پاسخ دریافتی را مشاهده کنید.
ترفند ۸: APIها اجزای اصلی اپلیکیشن را در معرض نمایش قرار می‌دهند. پنتسترها باید از این واقعیت بهره ببرند. میتوان رابطه بین کاربران و Roleها و منابع و ارتباطات بین آن ها را بهتر شناخت تا آسیب‌پذیری‌های جالب تر یافت شوند. همیشه دربرابر پاسخ های API کنجکاو باشید و به راحتی از آن عبور نکنید.
ترفند ۹: راهی پیدا کردین برای دانلود فایلهای دلخواه از وب سرور؟ به راحتی میتونین تست جعبه سیاه رو تبدیل به تست جعبه سفید کنید و فایل های اصلی و source ها رو دانلود کنید و دنبال باگ های جدید باشید.
ترفند ۱۰: اگر APIهای AuthN رو تست میکنین، و اگر صفحات مربوط به محصولات رو تست میکنین، احتمال بالایی وجود داره که endpointهای AuthN از مکانیزم هایی برای جلوگیری از brute force استفاده کنن. بهرحال توسعه دهنده ها ترجیح میدن که rate limiting بر روی محیط هایی که محصول در اونها وجود نداره، غیر فعال کنن. این درخواست ها رو هم از یاد نبرین.
ترفند ۱۱ : برای هر API که از فرمت json/xml استفاده می کند، با تغییر extension به JSONP در صورت تنظیمات اشتباه در API احتمالا اطلاعات جدیدی در قالب JSONP دریافت خواهید کرد.
ترفند ۱۲ : اگر یک endpoint که مربوط به uploading هست رو پیدا کردین، سعی کنین که URL رو با هدف SSRF تغییر بدین. خیلی از وقت ها این عملیات منجر میشه به یک SSRF کامل!
ترفند ۱۳ : میتونید هدر Content-Type رو به application/xml تغییر بدین (مطمئن بشین که سرور روی درخواستتون پردازش انجام میده). اگر پردازش انجام شد، میتونین فرآیند تست رو با رویکرد XXE ادامه بدین.
ترفند ۱۴ : معمولا JSON API ها نسبت به حمله CSRF آسیب پذیر هستن. کافیه فقط Content-Type رو به text/plain تغییر بدین و نتیجه رو مشاهده کنین.
ترفند ۱۵ : معمولا APIها نسبت به حملات از نوع سرقت cross-site مثل CSRF یا CORS مقاوم نیستن. پس وقتی شروع به تست کردین، این نکته تو ذهنتون باشه.
ترفند ۱۶ : روی APIهای third party هم تمرکز کنین. بجای تمرکز بر روی تست‌های معمولی که با هدف privilege escalation صورت میگیره، روی یادگیری و تست scope permissions تمرکز کنید.
ترفند ۱۷ : برای پیدا کردن یه باگ با impact بالا دنبال متودهایی باشین که توسط API پیاده‌سازی شدن اما توی اپلیکیشن ازشون استفاده ای نمیشه. بعضی از این endpointها میتونن توی فایل های جاوا اسکریپت سرور و یا مهندسی معکوس روی اپلیکیشن های موبایل یافت بشن.
در آخر این رو هم باید اضافه کنم که راهنمای موجود که مشاهده میکنین کامل نیست و اگر نکته خاص دیگه ای مدنظرتون هست که توی این ترفندها ذکر نشده، توی بخش کامنت ها بهمون اطلاع بدین تا در ویرایش‌های بعدی این نوشته، اصلاح بشه.
این مطالب هم برای اطلاع بیشتر راجع به آزمون نفوذ API بدرد می‌خورن (اضافه شده توسط یاشار شاهین‌زاده):
https://rhinosecuritylabs.com/application-security/simplifying-api-pentesting-swagger-files/
https://medium.com/datadriveninvestor/api-security-testing-part-1-b0fc38228b93
https://medium.com/@saumyaprakashrana_51250/api-security-testing-part-2-67ae9fb9c12
ازونجایی که همه میدونن، معمولا اونایی که تو شریف درس خوندن، انسان های شریفی نمیشن! اما برعکس، کسایی که تو تربیت مدرس درس خوندن، حتما مدرس های خوبی میشن ;) سعی میکنم هر سه ماه یک دوره عمومی رو تو حوزه موبایل برگزار کنم و اگه خواستین خبر دار بشین، از طریق توییتر منو با thisismoreti پیدا میکنید.
[…] تو پست اول توی مموری لیکز بیشتر دربارش توضیح دادماینم لینکش […]