API Misconfigurations Can Easily Expose Sensitive Data
APIها فوق‌العاده قدرتمند هستند. آن‌ها راهی برای تعامل سیستم‌ها با یکدیگر فراهم می‌کنند و دنیایی از راهکارهای مشترک و بین‌عملکردی را باز می‌کنند. این سیستم‌ها همچنین بسیار فراگیر هستند، حتی سیستم‌های روزمره‌ای که به ظاهر بی‌ضرر هستند توسط تعاملات پیچیده‌ای تحت رابط‌های کاربری براق هدایت می‌شوند.
با قدرت زیاد، ریسک زیاد نیز ممکن است ایجاد شود. در مورد APIها، یکی از رایج‌ترین ریسک‌ها ناشی از پیکربندی نادرست است. اما پیکربندی نادرست دقیقاً چیست و این مشکل چقدر گسترده است؟
در ادامه، ما به بررسی پیکربندی‌های نادرست در فضای API پرداخته و مشکل را در زمینه خود قرار می‌دهیم. یک مثال از اینکه این نوع مشکل در مقیاس بزرگ چگونه ظاهر می‌شود را بررسی کرده و بهترین روش‌ها برای اطمینان از امنیت سیستم‌ها را استخراج می‌کنیم.
پیکربندی نادرست چیست؟
پیکربندی نادرست API اصطلاحی کلی است که به راه‌اندازی ناصحیح یا ناقص سیستم‌ها در طراحی یا فرآیند استقرار یک API اشاره دارد. این می‌تواند اشکال مختلفی داشته باشد، اما غالباً اشتباهات ساده‌ای مانند طرح‌های احراز هویت ناقص یا افشای بیش از حد داده‌ها هستند.
این پیکربندی‌های نادرست می‌توانند منجر به آسیب‌پذیری جدی در برابر حملات شوند، سطح آسیب‌پذیری یک API را افزایش دهند و اثربخشی اقدامات امنیتی را کاهش دهند. پیکربندی‌های نادرست می‌توانند در نقاط مختلف چرخه عمر API رخ دهند و در بسیاری از موارد کاملاً ناخواسته و نه عمدی یا مخرب هستند.
۷ نوع پیکربندی نادرست API
پیکربندی نادرست می‌تواند در هر نقطه‌ای از چرخه توسعه API ظاهر شود. در اینجا چند دسته‌بندی رایج آورده شده است:
۱. افشای بیش از حد داده‌ها
وقتی یک API بیش از حد مفصل است یا اطلاعات زیادی را در پاسخ به درخواست ارسال می‌کند، سیستم درگیر افشای بیش از حد داده‌ها می‌شود. این اغلب به دلیل غفلت در تعامل نقاط انتهایی با یکدیگر یا محدودیت‌های درخواست‌ها رخ می‌دهد. این نوع پیکربندی‌های نادرست می‌تواند منجر به افشای داده‌های خصوصی یا افزایش حملات در سایر حوزه‌ها شود.
۲. کنترل ناکافی داده‌ها
محدودیت نرخ (Rate limiting) و throttling برای کنترل حجم داده‌های در حال انتقال در شبکه با محدود کردن تعداد یا حجم درخواست‌ها در مقیاس طراحی شده است. هنگامی که این سیستم‌ها نادرست پیکربندی شوند، سیستم می‌تواند در معرض مشکلات بحرانی داده‌ای و نگرانی‌های overflow حافظه قرار گیرد.
۳. احراز هویت و مجوز ناکافی یا ناقص
احراز هویت (تأیید هویت کاربر) و مجوز (اطمینان از اینکه کاربر مجاز به انجام عمل موردنظر است) عناصر حیاتی امنیت هستند. پیکربندی نادرست این عناصر می‌تواند باعث دسترسی کاربران به داده‌هایی شود که نباید ببینند، ارتقای خودسرانه حقوق کاربری و مشکلات دیگر گردد.
۴. نقاط انتهایی ناامن
نقاط انتهایی که نباید در دسترس باشند، می‌توانند منجر به آسیب‌پذیری‌های بحرانی backend شوند، مانند افشای پنل‌های مدیریت، گزارش‌گیری داده‌ها و سایر کنترل‌ها. به همین ترتیب، صفحه‌بندی در نقاط انتهایی که نباید داشته باشند، می‌تواند منجر به افشای ناخواسته داده‌ها و امکان scraping شود.
۵. پیکربندی نادرست CORS
پیکربندی نادرست Cross-origin resource sharing (CORS) ممکن است به دامنه‌های غیرقابل اعتماد اجازه دسترسی به APIها یا منابع را بدهد، که باعث افشای داده‌های خصوصی و حتی امکان حملات Cross-site scripting (XSS) می‌شود.
۶. لاگ‌گیری و پایش ناکافی
لاگ‌گیری و پایش ضعیف می‌تواند تشخیص و پاسخ به نفوذ داده‌ها، دسترسی غیرمجاز و افشای اطلاعات حساس را دشوار کند.
۷. رمزنگاری ضعیف
رمزنگاری ضعیف یا عدم وجود آن در حالت rest یا transit می‌تواند APIها را در معرض حملات جمع‌آوری داده، replay یا man-in-the-middle قرار دهد و امنیت را کاملاً دور بزند، و در صورت نقض ذخیره‌سازی، داده‌های خصوصی را افشا کند.
ریسک‌های پیکربندی نادرست
پیکربندی نادرست یک مشکل خطرناک با پتانسیل آسیب جدی به سازمان، APIها و کاربران آن است. وقتی APIها نادرست پیکربندی شوند، داده‌ها راحت‌تر افشا می‌شوند و تشخیص این نفوذها سخت‌تر می‌شود. پیکربندی‌های نادرست مانند قراردادن یک در در قاب اما حذف مکانیزم قفل است حس امنیت کاذب ایجاد می‌کند.
دسترسی غیرمجاز می‌تواند به سادگی اجازه دسترسی به منابع مخفی باشد یا به شدت نگران‌کننده باشد مانند اجازه دادن به کاربر برای ارتقای خود به ادمین. پیکربندی نادرست همچنین می‌تواند کنترل‌ها در شبکه را کاهش دهد و اجازه حمله به زیرساخت و سیستم‌های پشتیبان را بدهد. این می‌تواند منجر به حمله Denial of Service شود و هم درآمد سازمان و هم کارایی برای کاربران را تحت تأثیر قرار دهد.
بعلاوه، تأثیر بر شهرت و تطابق با مقررات نیز وجود دارد. پیکربندی‌های نادرست اغلب به توجه کمی نیاز دارند تا اصلاح شوند، و اشتباه در آن می‌تواند سازمان شما را به عنوان غیرحرفه‌ای یا غفلت عمدی نشان دهد. همچنین GDPR، CPRA و دیگر مقررات حفظ حریم خصوصی مجازات‌های قانونی و مالی جدی برای افشای داده‌ها دارند، چه عمدی و چه غیر عمدی. پیکربندی نادرست می‌تواند تأثیرات اقتصادی شدیدی داشته باشد، در برخی موارد تا میلیون‌ها دلار.
مطالعه موردی: افشای داده‌های Microsoft Power Pages
در نوامبر ۲۰۲۴، گزارشی توسط Aaron Costello، رئیس تحقیقات امنیت SaaS در AppOmni منتشر شد. این گزارش نمونه‌ای واقعی از اثر پیکربندی نادرست در مقیاس بزرگ را نشان می‌دهد — یک مطالعه موردی جالب از اینکه چگونه یک مشکل کوچک می‌تواند سریعاً گسترش یابد.
هسته مسئله ساده به نظر می‌رسد. در Microsoft Power Pages، به یک کاربر ناشناس نقش Anonymous اختصاص داده می‌شود. این نقش دارای حقوق پیش‌فرض خاصی است که می‌تواند مورد سوء استفاده قرار گیرد تا به داده‌هایی دسترسی پیدا کند که کاربر معمولاً نمی‌تواند ببیند. با پیشروی، بسیاری از کاربران Anonymous می‌توانند خود ثبت‌نام کنند و از طریق پیکربندی نادرست کنترل‌های دسترسی برای جداول و ستون‌ها، میزان داده‌های قابل دسترسی خود را افزایش دهند.
Aaron Costello تأثیر این مسئله پیکربندی نادرست را اینگونه توضیح می‌دهد:
“این افشاها قابل توجه هستند — Microsoft Power Pages ماهانه توسط بیش از ۲۵۰ میلیون کاربر و همچنین سازمان‌ها و نهادهای دولتی پیشرو در صنعت استفاده می‌شود، شامل خدمات مالی، بهداشت و درمان، خودروسازی و غیره. کشف AppOmni خطرات قابل توجه ناشی از کنترل‌های دسترسی نادرست در برنامه‌های SaaS را برجسته می‌کند: اطلاعات حساس، از جمله جزئیات شخصی، افشا شده است. واضح است که سازمان‌ها باید امنیت را هنگام مدیریت وب‌سایت‌های خارجی اولویت دهند و تعادل بین سهولت استفاده و امنیت در پلتفرم‌های SaaS برقرار کنند — این‌ها برنامه‌هایی هستند که بخش عمده داده‌های محرمانه شرکت‌ها را در اختیار دارند و مهاجمان آن‌ها را به عنوان راهی برای دسترسی به شبکه‌های سازمان هدف قرار می‌دهند.”
نحوه عملکرد
این مسئله پیکربندی نادرست به دلیل برخی ویژگی‌های خاص Power Pages رخ می‌دهد. Power Pages سه نقش “out-of-the-box” دارد که تمام کاربران را در آن‌ها دسته‌بندی می‌کند، با دو نقش خاص Anonymous و Authenticated که در هسته این مشکل هستند.
علاوه بر این دو کنترل نقش، سطوح دسترسی نیز وجود دارند که دسترسی به داده‌ها را محدود می‌کنند:
-
سطح رکورد: ردیف‌های داده‌ای که کاربر می‌تواند ببیند
-
سطح ستون: ستون‌های داده‌ای که کاربر می‌تواند ببیند
-
سطح جدول: جداول داده‌ای که کاربر می‌تواند ببیند
-
سطح سایت: تنظیمات احراز هویت سایت و دسترسی جداول با Web API
این کنترل‌های دسترسی لایه‌بندی شده هستند. در واقع، اگر کاربری کنترل‌های سطح رکورد را عبور کند، سپس از طریق کنترل‌های سطح ستون و به همین ترتیب پیش می‌رود. جایی که این مشکل ظاهر می‌شود در پیکربندی مقادیر خاص برای داده‌های حساس در مقایسه با کنترل‌های هر کاربر است.
بررسی آسیب‌پذیری
بیایید از ابتدا شروع کنیم. یک توسعه‌دهنده سایتی ایجاد کرده و جدولی برای ذخیره داده‌ها ساخته است. این جدول یک ورودی allow-list برای تمام ستون‌ها دارد، که باعث می‌شود ستون‌ها به صورت پیش‌فرض از طریق Web API قابل بازیابی باشند. با ارائه داده‌ها توسط Web API (حتی اگر داده‌ها از طریق وب قابل دسترسی نباشند)، هر کاربری که وارد API شود می‌تواند آن داده‌ها را ببیند.
کاربری وارد سایت می‌شود. در حالی که صفحه ورود میزبانی نشده است، Web API به صورت پیش‌فرض برای ثبت‌نام خودکار و ورود تنظیم شده است. کاربر Anonymous که به طور پیش‌فرض دسترسی جهانی به جدول دارد، می‌تواند داده‌هایی را که می‌خواهد هدف قرار دهد شناسایی کند. از اینجا، او می‌تواند حساب خود را ثبت‌نام کرده و به کاربر Authenticated تبدیل شود.
به دلیل پیکربندی پیش‌فرض و احتمالی نادرست در سطح ستون و همچنین دسترسی جهانی برای عملیات خواندن، کاربر قادر خواهد بود یک جدول را پیدا کرده و ستون‌ها را از طریق Web API بدون توجه به کنترل‌های سطح منابع بخواند.
گزارش AppOmni برخی از علل و عوامل مشخص را تجزیه و تحلیل می‌کند. ابتدا، Web API خود ستون‌های اضافی را افشا می‌کند. در حالی که این خود مشکل مستقیمی نیست، با ثبت‌نام باز و احراز هویت خارجی در پیاده‌سازی پیش‌فرض سایت، این مسئله برجسته می‌شود. در این حالت ترکیبی، ستون‌ها به قدری افشا می‌شوند که دسترسی جهانی به جدول برای کاربران خارجی پیش‌فرض بیش از حد مفصل است و اطلاعات بیشتری نسبت به آنچه ممکن است از API بیرون دیده شود را نشان می‌دهد.
برخی مشکلات اضافی نیز به شدت این مسئله را افزایش می‌دهند. امنیت ضعیف ستون برای داده‌های حساس، ماسکینگ ضعیف یا غیر موجود و سایر مشکلات در نهایت منجر به افشای داده‌های بسیار بیشتر از آنچه مکانیزم‌های محافظتی نشان می‌دهند، می‌شوند.
شواهد در دنیای واقعی
این یک آسیب‌پذیری نظری نیست — نمونه‌های واقعی قابل مشاهده‌ای از افشای داده‌ها دارد. در آزمایش‌ها، AppOmni دریافت که این آسیب‌پذیری شایع است و بسیاری از سازمان‌ها پیکربندی‌های پیش‌فرض مشابه و مشکلاتی در کنترل دسترسی مبتنی بر نقش دارند. مشکل به قدری جدی بود که رکوردهای افشاشده در جهان به میلیون‌ها مورد رسید:
“در یک مورد، یک ارائه‌دهنده خدمات کسب‌وکار مشترک بزرگ برای NHS اطلاعات بیش از ۱.۱ میلیون کارمند NHS را فاش می‌کرد، با بخش‌های بزرگی از داده‌ها شامل آدرس ایمیل، شماره تلفن و حتی آدرس‌های خانگی کارکنان. این یافته به صورت مسئولانه گزارش شد و از آن زمان حل شده است.”
کاهش پیکربندی‌های نادرست
اگرچه این مطالعه موردی نشان می‌دهد که مشکل چقدر گسترده است، خوشبختانه حل مشکل پیکربندی نادرست API نسبتاً آسان است اگر به آن توجه کنید و به طور مناسب آن را اصلاح کنید.
اول و مهم‌تر از همه، باید بسیار دقیق باشید. Microsoft Power Pages هشدارهای کافی برای نقش Anonymous و مشاهده سایت‌های پیش‌فرض ارائه می‌دهد، اما این سیستم‌ها اغلب با پیکربندی‌های پیش‌فرض خود مستقر می‌شوند. نادیده گرفتن هشدارها در طول توسعه، تضاد با فرهنگ توسعه‌دهنده امن است. بنابراین، نیمی از راه حل مربوط به آموزش تیم و اجرای بررسی‌های استاندارد دقیق است.
گام بزرگ دیگر، حسابرسی منظم کنترل‌ها و حقوق است. پیکربندی‌های پیش‌فرض یک چیز است، اما وقتی این پیکربندی‌ها ماه‌ها یا سال‌ها پس از استقرار سایت وجود داشته باشند، نشان‌دهنده نقص عمده در فرآیند اعتبارسنجی است. نقش‌ها و کنترل‌های دسترسی شما در سطوح منابع و رکوردها باید به طور منظم حسابرسی شوند، چه با استفاده از تست خودکار و چه دستی. تنها راه اطمینان از صحت پیکربندی، بررسی آن است. این باید بخش اصلی چرخه توسعه باشد.
پایش مستمر نیز بخش عمده‌ای از راه حل است. علائم هشدار واضح وجود دارد که این مشکلات وجود دارند، مانند مشاهده کاربران Anonymous که به داده‌های جهانی دسترسی دارند. این علائم باید در سیستم شما اندازه‌گیری و پایش شوند تا بتوانید این تهدیدها را هنگام بهره‌برداری شناسایی و کاهش دهید. بدون این، تنها تکیه‌گاه شما نظریه‌ای و شبکه ایمنی فرضی خواهد بود.
در نهایت، بررسی‌های منظم طراحی باید بخشی از فرآیند شما شود. هنگام انتشار محتوا، باید پیش از استقرار مطمئن شوید که سیستم پایدار با حقوق و کنترل دسترسی مناسب دارید. اگر نمی‌توانید از صحت ساخت اطمینان حاصل کنید، نباید آن را مستقر کنید — نقطه پایان.
نتیجه‌گیری
امیدواریم این مطلب به شما کمک کرده باشد تا راه‌حلی با پیکربندی امن‌تر بسازید. APIها نیاز به توجه زیادی دارند و می‌توان به راحتی فراموش کرد که پیکربندی صحیح چقدر مهم است. در حالی که اغلب اصلاح آن آسان است، پیکربندی‌های نادرست API می‌توانند خسارات جدی ایجاد کنند و منجر به مشکلات شهرت، مالی و مقرراتی شوند.
