OWASP API Security Top 10: 0xa3 broken object property level authorization

# API3:2023 نقض مجوزدهی در سطح ویژگی‌های شیء

| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد |
|---------|--------------------|------------|
| خاص API / قابلیت بهره‌برداری: آسان |  میزان شیوع: متداول/ قابلیت تشخیص: آسان              | پیامد فنی: متوسط / خاص کسب و کار     |
| APIها معمولاً اطلاعات تمام ویژگی‌های شیء درخواستی را به کاربر ارائه می‌دهند. این ویژگی در APIهای REST بسیار رایج است. در مقابل، در پروتکل‌های دیگر مانند GraphQL، شما می‌توانید درخواست‌های دقیق‌تری برای بازگشت ویژگی‌های خاص از یک شیء ارسال کنید. درنتیجه کنترل دقیق‌تری بر روی داده‌های دریافتی خواهید داشت. آگاهی از اینکه کدام ویژگی شیء، اضافی است دشوار است؛ زیرا ویژگی‌های اضافی ممکن است بسته به شرایط، تغییر کنند، اما ابزارهای خودکاری نیز وجود دارند که به تشخیص و مدیریت این ویژگی‌ها کمک می‌کنند. | بررسی پاسخ‌های API، روشی برای شناسایی اطلاعات حساس می‌باشد که از طریق این شناسایی می‌توان ویژگی‌های اضافی و پنهان را کشف کرد. از تکنیک‌هایی مانند فازینگ برای شناسایی ویژگی‌های اضافی استفاده می‌شود. اگر می‌خواهید بفهمید که آیا این ویژگی‌ها قابل تغییر هستند یا نه، باید درخواست‌های API خاصی را ارسال کرده و پس از تجزیه و تحلیل پاسخ‌های دریافتی درباره حساسیت اطلاعات موجود در آن، تصمیم بگیرید. در صورتی که ویژگی مورد نظر در پاسخ API نباشد، ممکن است نیاز به تحلیل اثرات جانبی داشته باشید تا بتوانید ویژگی مورد نظر را شناسایی و کنترل کنید.| دسترسی غیرمجاز به ویژگی‌های حساس یا خصوصی شیء، ممکن است منجر به افشا، از دست دادن یا خرابی داده شود. در شرایط خاص، دسترسی غیرمجاز به ویژگی‌های شیء می‌تواند به ارتقاء سطح دسترسی یا تصاحب جزئی/کامل حساب کاربری منجر شود.|

## آیا API از نظر نقض مجوزدهی در سطح ویژگی‌های شیء ‌آسیب‌پذیر است؟

هنگامی که از طریق یک endpoint به یک کاربر اجازه دسترسی به یک شیء می‌دهید، دقت کنید که کاربر تنها به ویژگی‌های مجاز دسترسی داشته باشد.  
endpoint آسیب‌پذیر است اگر:

1. ویژگی‌های حساس یک شیء را به کاربر غیرمجاز، افشا ‌کند (این مورد قبلاً با نام "افشای مفرط داده" نامگذاری شده بود).
2. به کاربر اجازه ‌دهد که مقدار یک ویژگی حساس شیء را که کاربر نباید به آن دسترسی داشته باشد، تغییر داده، اضافه یا حذف کند (این مورد قبلاً با نام "تخصیص جمعی" نامگذاری شده بود).

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

### سناریو #1

یک برنامه دوستیابی به کاربر این امکان را می‌دهد که رفتار نامناسب دیگر کاربران را گزارش کند. در این فرآیند، کاربر روی دکمه "گزارش" کلیک کرده و API زیر را فراخوانی می‌کند:

```
POST /graphql
{
  "operationName":"reportUser"
  "variables":{
    "userId": 313
    "reason":["offensive behavior"]
  }
  "query":"mutation reportUser($userId: ID! $reason: String!) {
    reportUser(userId: $userId reason: $reason) {
      status
      message
      reportedUser {
        id
        fullName
        recentLocation
      }
    }
  }"
}
```

### سناریو #2

یک پلتفرم اجاره اقامتگاه آنلاین را در نظر بگیرید که در آن به کاربران میزبان اجازه می‌دهد که آپارتمان خود را به کاربران مهمان اجاره دهند. میزبان می‌بایست پیش از اقدام به پرداخت مهمان، درخواست رزرو وی را تأیید کند.
`
```
{
  "approved": true
  "comment": "Check-in is after 3pm"
}
```

میزبان می‌تواند درخواست معتبر را تکرار کرده و پیام‌های مخرب زیر را اضافه کند:
`
```
{
  "approved": true
  "comment": "Check-in is after 3pm"
  "total_stay_price": "$1000000"
}
```

### سناریو #3

یک شبکه اجتماعی که برای نمایش ویدیوهای کوتاه ساخته شده است، اقدام به اعمال فیلترینگ محتوا و سانسور محتوای کاربران می‌نماید. حتی اگر ویدیوی آپلود شده مسدود شود، کاربر می‌تواند توضیحات ویدیو را با استفاده از درخواست API زیر تغییر دهد:

```
PUT /api/video/update_video

{
  "description": "a funny video about cats"
}
```

یک کاربر ناراضی می‌تواند درخواست معتبر را تکرار کرده و پیام‌های مخرب زیر را به درخواست اضافه کند:

```
{
  "description": "a funny video about cats"
  "blocked": false
}
```

## چگونه از ‌آسیب‌پذیری نقض مجوزدهی در سطح ویژگی‌های شیء پیشگیری کنیم؟

- هنگام ارائه یک شیء از طریق endpoint، همیشه اطمینان حاصل کنید که کاربر از قبل به ویژگی‌های ارائه شده، دسترسی داشته باشد.
- اجتناب از استفاده از متدهای عمومی `to_json` و `to_string` و در عوض شناسایی کردن تک تک ویژگی‌ها و مشخصه‌هایی که برای پاسخ ضروری هستند.
- در صورت امکان، از توابعی که به طور خودکار ورودی کاربر را به متغیرهای کد، اشیاء داخلی یا ویژگی‌های شیء متصل می‌کنند ("تخصیص جمعی") استفاده نکنید.
- کاربر تنها بتواند ویژگی‌های مشخص و مجاز شیء را بروزرسانی کند.
- بکارگیری یک مکانیزم اعتبارسنجی الگومحور برای بررسی اعتبار پاسخ‌ها بعنوان یک لایه امنیتی دیگر و همچنین تعریف و اعمال این مکانیزم بر روی داده بازگردانده شده تمامی APIها از جمله خطاها.
- بر اساس نیازهای متد درخواستی، ساختارهای داده بازگردانده شده را در حداقل مقدار ممکن نگه دارید.

## مراجع

- [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1]
- [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2]
- [Mass Assignment Cheat Sheet][3]

### خارجی

- [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4]
- [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5]

[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/
[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/
[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html
[4]: https://cwe.mitre.org/data/definitions/213.html
[5]: https://cwe.mitre.org/data/definitions/915.html