API6:2019 - تخصیص جمعی
| عوامل تهدید/مسیر حمله | ضعف امنیتی | پیامد |
|---|---|---|
| API خاص: قابلیت بهره‌برداری2 | میزان شیوع2 : قابلیت تشخیص2 | پیامد فنی2 : خاص کسب و کار |
| بهره برداری از این آسیب‌پذیری غالبا نیاز به فهم منطق تجاری، روابط مابین اشیا و ساختار API از سوی مهاجم دارد. بهره برداری از مقوله تخصیص جمعی در APIها ساده تر است چرا که در مرحله طراحی، پیاده‌سازی زیرین اپلیکیشن به همراه نام ویژگیهای اشیا افشا می‌شود و در معرض دید عموم قرار می‌گیرد. | چارچوبهای جدید غالبا توسعه دهندگان را به استفاده از توابعی تشویق می‌کنند که بطور خودکار، ورودی‌های دریافتی از کلاینت را به متغیرهای کد و اشیاء داخلی آن پیوند می‌دهند. مهاجمین با سواستفاده از این متدلوژی می‌توانند به گونه ای اقدام به بروزرسانی یا بازنویسی ویژگیهای اشیاء (داده) حساس نمایند که توسعه دهنده هیچگاه قصد افشای آن ویژگیها را نداشته است. | بهره برداری از این آسیب‌پذیری می‌تواند منجر به افزایش سطح دسترسی، دستکاری داده، عبور از مکانیزم‌های امنیتی و ... شود. |
آیا API از نظر تخصیص جمعی آسیب‌پذیر است؟
اشیا در اپلیکیشن‌‌‌های مدرن می‌توانند ویژگیهای متعددی داشته باشند. برخی از این ویژگیها بایستی مستقیما توسط کلاینت قابل بروزرسانی باشند (مثلا user.first_name یا user.address) در حالی که کلاینت نباید بتواند سایر ویژگیها را دستکاری نماید (مثلا پرچم user.is_vip).
یک تابع درAPI اگر بطور خودکار پارامترهای کلاینت را بدون لحاظ کردن حساسیت و سطح افشای ویژگیهای آن، مستقیما تبدیل به ویژگیهای اشیای داخلی نماید، از منظر تخصیص جمعی آسیب‌پذیر خواهد بود. این آسیب‌پذیری به مهاجم اجازه می‌دهد تا بتواند ویژگی‌‌‌هایی از اشیا را که نباید به آنها دسترسی داشته باشد، بروزرسانی نماید.
نمونه‌‌‌هایی از «ویژگیهای حساس» عبارتند از:
- ویژگیهای مرتبط با مجوزها: پرچم‌‌‌هایی نظیر
user.is_adminوuser.is_vipفقط بایستی توسط ادمین‌‌‌ها تنظیم شوند. - ویژگیهای وابسته به فرایند:
user.cashفقط باید بصورت داخلی و پس از تایید پرداخت بروزرسانی شود. - ویژگیهای داخلی:
article.created_timeفقط باید بصورت داخلی و توسط اپلیکیشن تنظیم گردد.
مثال‌‌‌هایی از سناریوهای حمله
سناریو #1
یک اپلیکیشن هم‌سفری به کاربر امکان ویرایش اطلاعات پایه‌ای پروفایل خود را می‌دهد. در خلال این فرایند، یک فراخوانی API به PUT /api/v1/users/me با شی مجاز JSON زیر فرستاده می‌شود:
{"user_name":"inons","age":24}
اما درخواست GET /api/v1/users/me ویژگی اضافی credit_balance را نیز در خود دارد:
{"user_name":"inons","age":24,"credit_balance":10}
در اینجا مهاجم درخواست اول را با محتوای مخرب زیر بازارسال می‌نماید:
{"user_name":"attacker","age":60,"credit_balance":99999}
به دلیل وجود آسیب‌پذیری تخصیص جمعی در endpoint، مهاجم می‌تواند بدون انجام پرداخت اعتبار دریافت کند.
سناریو #2
یک پلتفرم اشتراک‌گذاری ویدئو به کاربران خود اجازه دانلود محتوا با فرمت‌‌‌های مختلفی را می‌دهد. مهاجم که در حال بررسی API است، در می‌یابد که GET /api/v1/videos/{video_id}/meta_data یک شیء JSON با ویژگیهای ویدئو را باز می‌گرداند. یکی از این ویژگیها، "mp4_conversion_params”:”-v codec h264" است که نشان می‌دهد اپلیکیشن از یک دستور Shell برای تبدیل ویدئو بهره می‌برد.
همچنین مهاجم متوجه می‌شود که POST /api/v1/videos/new در برابر تخصیص جمعی آسیب‌پذیر بوده و به کلاینت اجازه می‌دهد که هریک از ویژگیهای شیءویدئو را با به صورت دلخواه تنظیم نماید. در نتیجه مهاجم مقدار مخربی را به صورت "mp4_conversion_params":"-v codec h264 && format C:/" در قست ویژگی ویدئو وارد می‌کند که در نتیجه آن با دانلود ویدئو با فرمت MP4 توسط مهاجم حمله تزریق دستور Shell اجرا خواهد شد.
چگونه از آسیب‌پذیری تخصیص جمعی پیشگیری کنیم؟
- در صورت امکان، از بکارگیری توابعی که ورودی کلاینت را بصورت خودکار تبدیل به متغیرهای کد یا اشیای داخلی اپلیکیشن می کنند خودداری شود.
- تنها ویژگیهای ضروری که باید توسط کلاینت بروزرسانی شوند در لیست سفید قرار گیرد.
- از قابلیت‌‌‌های تعبیه شده در اپلیکیشن‌‌‌ها برای قراردادن ویژگی‌‌‌هایی که تغییر آنها برای کلاینت غیرمجاز است در لیست سیاه استفاده شود.
- در صورت امکان، الگوهای واضح و بدون ابهام برای داده ورودی تعریف و اعمال شود.