بهترین شیوه های امنیت API
معرفی
API ها برای موفقیت کسب و کار حیاتی هستند. تمرکز باید بر اطمینان از قابلیت اطمینان و امنیت آنها باشد. اکثر پاسخ دهندگان به نظرسنجی Salt Security در سال 2021 گفتند که راه اندازی یک برنامه را به دلیل تاخیر انداخته اند. امنیت API نگرانی ها.
10 خطر امنیتی برتر API ها
1. ورود به سیستم و نظارت کافی
هنگامی که یک مهاجم سعی می کند وارد یک سیستم شود، ترافیک نامنظم ایجاد می کند. آنها از روشی استفاده می‌کنند که احراز هویت شما را در مقابل ورودی‌های شما اعمال می‌کند.
2. مدیریت نامناسب دارایی
API ها نسبت به برنامه های کاربردی وب سنتی، نقاط پایانی بیشتری دارند. مستندات مناسب و به روز بسیار مهم است. برای جلوگیری از منسوخ شدن API نسخه ها و هاست های در معرض نمایش باید هاست ها و نسخه های API داده شده را مدیریت کنید. باید سعی کنید نقاط پایانی دیباگر را کاهش دهید.
3. تزریق
آسیب‌پذیری‌های تزریق مانند SQL یا تزریق‌های فرمان زمانی رخ می‌دهند که داده‌های غیرقابل اعتماد مستقیماً به عنوان بخشی از یک پرس و جو یا عبارت به یک مفسر ارسال می‌شوند. در نتیجه، مهاجمان می توانند مفسر را فریب دهند تا عبارات ناخواسته را اجرا کند یا بدون مجوز مناسب به داده ها دسترسی پیدا کند.
4. پیکربندی اشتباه امنیتی
تنظیمات امنیتی ضعیف اغلب به دلیل پیکربندی های پیش فرض ناامن است.
- پیکربندی های موقت ناقص
- فضای ذخیره سازی ابری را باز کنید
- هدرهای HTTP اشتباه پیکربندی شده است
- روش‌های HTTP غیرضروری فعال شده است
- به اشتراک گذاری منابع از منابع مختلف
- خروجی پیام های خطای دقیق حاوی امنیت مرتبط اطلاعات
5. تخصیص انبوه
تخصیص انبوه زمانی اتفاق می‌افتد که اتصال مشتری به مدل‌های داده بدون فیلتر کردن مناسب خصوصیات منجر به نگاشت انبوه شود. مهاجمان می توانند ویژگی های شی را با حدس زدن آنها تغییر دهند.
6. مجوز سطح عملکرد شکسته
مجوز سطح عملکرد شکسته زمانی می تواند اتفاق بیفتد که سیاست های کنترل دسترسی پیچیده با سلسله مراتب، گروه ها و نقش های مختلف وجود داشته باشد. جدایی نامشخص بین عملکردهای مدیر و کاربر منجر به ضعف در مجوز می شود. مهاجمان می توانند به منابع دیگر کاربران یا عملکردهای مدیریتی دسترسی پیدا کنند.
7. احراز هویت خراب کاربر
مکانیسم‌های احراز هویت اغلب به مهاجمان اجازه می‌دهد تا توکن‌های احراز هویت را به خطر بیاندازند یا از خطاهای پیاده‌سازی برای جعل هویت موقت یا دائمی دیگر کاربران سوء استفاده کنند.
8. قرار گرفتن در معرض بیش از حد داده ها
با توجه به استفاده عمومی از APIها، توسعه دهندگان تمایل دارند تمام ویژگی های شی را فاش کنند. اگر برنامه‌نویسان محرمانه بودن را در نظر نگیرند، می‌توانند ویژگی‌های شی را افشا کنند. قرار گرفتن در معرض بیش از حد داده ها می تواند با تکیه بر سمت مشتری برای فیلتر کردن داده ها قبل از نمایش به کاربر ایجاد شود.
9. کمبود منابع و نرخ محدود
می توان از مشتری یا کاربر درخواست کرد. فقدان محدودیت منابع و نرخ نه تنها می تواند بر عملکرد سرور API تأثیر بگذارد و منجر به حملات انکار سرویس شود، بلکه امکان ضعف در احراز هویت را نیز ایجاد می کند.
10. مجوز سطح شیء شکسته
APIها تمایل دارند نقاط پایانی را که شناسه‌های شی را پردازش می‌کنند، در معرض دید قرار دهند و سطح حمله بزرگی را در کنترل دسترسی ایجاد کنند. بررسی های مجوز در سطح شی باید شامل عملکردی باشد که از طریق ورودی کاربر به منبع داده دسترسی پیدا می کند.
چگونه API های SOAP را ایمن کنیم
SOAP یک مشخصات پروتکل است که با صفحات وب ارتباط برقرار می کند. این یک استاندارد صنعتی W3C، فرمت XML است. SOAP یک پیام وضعیتی را پیاده سازی می کند. SOAP با پروتکل های WS-Security ادغام می شود. SOAP می تواند یکپارچگی و محرمانه بودن تراکنش های پردازش شده را با رمزگذاری بیشتر تضمین کند. با استفاده از XML، SOAP پرمخاطب ترین سبک API است.
SOAP یک مشخصات پروتکل است که با صفحات وب ارتباط برقرار می کند. این یک استاندارد صنعتی W3C، فرمت XML است. SOAP یک پیام وضعیتی را پیاده سازی می کند. SOAP با پروتکل های WS-Security ادغام می شود. SOAP می تواند یکپارچگی و محرمانه بودن تراکنش های پردازش شده را با رمزگذاری بیشتر تضمین کند. با استفاده از XML، SOAP پرمخاطب ترین سبک API است.
چگونه API های Rest را ایمن کنیم
REST یک سبک از معماری API است. REST یک رابط ساده برای انتقال اطلاعات است. هنگام ارسال داده، مرحله تبدیل وجود ندارد. اطلاعات ارسال شده در فرم اصلی تأثیر مفیدی بر بار مشتری دارد. داده ها در فرمت های JSON یا XML هستند.
الزامات معماری RESTful:
- فاقد حالت (بی تابعیت)
- ذخیره سازی
- رابط مشترک: این امکان یک تعامل منسجم و مستقل از برنامه را با وب سرور فراهم می کند.
در REST، تمام ارتباطات از روش‌های HTTP استفاده می‌کنند: GET، POST، PUT، PATCH و DELETE. REST به عنوان یک API مدیریت برای CRUD (ایجاد، خواندن، به‌روزرسانی و حذف) استفاده می‌شود. تعامل با منابع را در سرویس های مقیاس پذیر سبک وزن نصب کنید. یک منبع معمولاً یک شی مدل داده است.
ایجاد API های امن RESTful نیز الزامات استاندارد خاصی را تحمیل می کند:
- استفاده از پروتکل HTTPS: عملیات رمزنگاری یکپارچگی داده های ارسال شده را تضمین می کند.
- Rate-limits: بررسی بار روی API ضروری است. حذف درخواست ها در صورت اضافه بار
- احراز هویت: شناسایی کاربر / برنامه / دستگاه.
- گزارش حسابرسی: ثبت اقدامات با ایجاد یک ورودی در فایل گزارش.
- کنترل حقوق دسترسی: تعیین حقوق دسترسی برای کار با منابع.
- دسترسی به منطق تجاری برنامه
طبق طراحی REST API هیچ رکوردی را نگه نمی دارد. محدودیتی برای دسترسی از طریق نقاط پایانی محلی وجود دارد. هنگام کار با معماری REST. مرسوم است که دو سطح امنیت را متمایز می کنند:
- سطح اول - دسترسی به API
- سطح دوم - دسترسی به برنامه
نحوه ایمن سازی API ها
برای اطمینان از امنیت API، سازمان ها باید به موارد زیر توجه زیادی داشته باشند.
- کنترل دسترسی
- حفاظت API
- محافظت در برابر تهدید
الگوی دروازه API
بهترین روش امنیتی این است که مسئولیت های امنیتی را به یک دروازه API تخلیه کنید. دروازه API بین باطن API و مصرف کنندگان قرار دارد. تمام درخواست های مصرف کنندگان را رهگیری می کند و جنبه های امنیتی را مدیریت می کند.
توسعه دهندگان API می توانند بر روی توابع API منطق تجاری تمرکز کنند. دروازه API امنیت و کنترل دسترسی را مدیریت می کند.
کنترل دسترسی API
کنترل دسترسی API به فرآیند تعیین اینکه چه کسی به کدام API دسترسی دارد اشاره دارد. چه عملکردی از آن API ها توسط سایر برنامه ها استفاده می شود.
تصدیق در مورد شناسایی نهاد درخواست کننده دسترسی به API است. شناسایی یا تایید این است که آیا کاربر رمز عبور را می داند یا خیر.
احراز هویت اساسی
این روش از فرآیند احراز هویت HTTP استفاده می کند. اعتبار کاربر با استفاده از الگوریتم base64 کدگذاری می شود. هدر HTTP هنگام ارسال درخواست پیوست می شود.
احراز هویت اولیه برای محافظت از APIها در برابر همه حملات امنیتی پیچیده کافی نیست. حداقل دو نفر باید نام کاربری و رمز عبور را به اشتراک بگذارند. شخص ثالث می تواند با دسترسی به اعتبارنامه به یک سرویس ایمن دسترسی پیدا کند. OAuth این آسیب پذیری ها را برطرف می کند.
توکن OAuth
OAuth تأیید از یک نشانه دسترسی استفاده می کند. اعتبارنامه ها به صورت مستقیم به اشتراک گذاشته نمی شوند. این توکن مادام العمر دارد. این بدان معنی است که حتی آن نشانه همیشگی نیست. این امر خطر سرقت را کاهش می دهد. توکن از محدوده استفاده می کند. دسترسی به منابع بر اساس نقش های اختصاص داده شده به کاربر. از این رو، OAuth برای ایمن سازی API ها بسیار ایمن تر از رمز عبور است.
احراز هویت مبتنی بر OIDC
OIDC – OpenID Connect این احراز هویت برای تأیید هویت کاربر نهایی است. این بر اساس احراز هویت انجام شده توسط سرور مجوز است. با استفاده از مکانیزم REST مانند جزئیات نمایه کاربر را به دست می آورد.
احراز هویت مبتنی بر کلید API
کلید API یک مقدار رشته ای است که توسط یک برنامه مشتری به دروازه APIM ارسال می شود. کلید مشتری اطلاعات را در پایگاه داده برنامه ذخیره می کند. سرور هویت مشتری را تأیید می کند. هنگامی که یک کاربر ثبت نام می کند، برنامه یک کلید تولید می کند.
این استراتژی در برابر دسترسی ناخواسته دفاع می کند. برای محدود کردن تعداد درخواست های API. کلید API چندین راه دارد، از جمله به عنوان پارامتر پرس و جو، در هدر پرس و جو و به عنوان مقدار کوکی.
احراز هویت مبتنی بر کوکی
روشی برای بررسی محتوای کوکی ها، تمام اطلاعات مربوط به جلسه را حفظ می کند. کاربر درخواست ورود را آغاز می کند. پس از وارد شدن کاربر، پاسخی را ارسال می کند. در سربرگ این پاسخ، یک فیلد Set-Cookies وجود دارد. این فیلد حاوی اطلاعاتی در مورد:
- نام فیلد کوکی
- مقدار فیلد کوکی
- کوکی چقدر دوام می آورد
دفعه بعد که کاربر نیاز به دسترسی به API دارد. او مقدار فیلد کوکی ذخیره شده JSESSIONID را با کلید "Cookie" در هدر درخواست ارسال می کند.
احراز هویت مبتنی بر توکن
سپس این توکن به سرور داخل هدر درخواست مجوز ارسال می شود. پس از دریافت رمز، سرور آن را تایید می کند. سرور خود توکن هایی را برای کاربران جدید تولید می کند. کلید، برخلاف توکن‌ها، تنها می‌تواند اجازه دسترسی به تماس‌های API را بدون توانایی دریافت داده‌های کاربر بدهد.
JSON Web Tokens (JWT)
مکانیزم احراز هویت مبتنی بر استفاده از نوع خاصی از توکن. این یک ساختار داده JSON است. یک نشانه از این نوع دارای یک سربرگ حاوی اطلاعات کلی است. یک بدنه حاوی یک بار (شناسه کاربر، گروه، داده) و یک امضای رمزنگاری است.
این رویکرد بهترین راه برای محدود کردن دسترسی REST API است. این یکی از امن ترین مکانیسم ها برای ارسال داده بین دو طرف است.
J.W.T. تکنیک کنترل دسترسی اولیه برای برنامه ایجاد شده است. این سرویس به منابع شخص ثالث متکی نیست. استفاده از توکن ها ساده است و دارای فرمت توصیف داده مناسب است.
استفاده از پروتکل HTTPS در ترکیب با امضای رمزنگاری سطح بالایی از امنیت را فراهم می کند.
هنگام ایمن سازی یک وب سرویس، کنترل ورودی سزاوار توجه ویژه است. باید اطمینان حاصل کنید که هر داده ای که برنامه روی آن کار می کند، استاندارد API را برآورده می کند.
جامعه توسعه‌دهنده توصیه‌هایی را هنگام اعتبارسنجی داده‌های ورودی ارائه کرده است:
- برای انجام اعتبارسنجی داده ها هم در سمت مشتری و هم در سمت سرور
- برای قرار دادن لیست های مجاز سرور، باید از توابع داخلی استفاده کنید
- همیشه بررسی نوع محتوا، اندازه و طول پرس و جو ضروری است
- از پرس و جوهای پارامتری به جای پرس و جوهای دستی در پایگاه داده در باطن استفاده کنید
- برای استفاده از لیست های اجازه سرور
- برای نگه داشتن گزارش خطاها و نظارت بر تلاش برای مبهم کردن ورودی داده ها
اجازه
هدف از مجوز تعیین سطوح دسترسی است.
کنترل دسترسی مبتنی بر XACML
XACML یک زبان سیاست کنترل دسترسی اعلامی مبتنی بر XML است که بر اساس XML است. می تواند یک روش استاندارد برای تأیید درخواست های مجوز ارائه دهد. سیاست های کنترل دسترسی را تعریف می کند.
Open Policy Agent OPA
OPA یک موتور خط مشی متن باز و همه منظوره است. OPA سیاست به‌عنوان کد و APIهای ساده را برای بارگذاری تصمیم‌گیری خط‌مشی مشخص می‌کند. تصمیمات خط مشی با ارزیابی ورودی پرس و جو و در مقابل داده ها ایجاد می شود. این تصمیمات خط مشی تعیین می کند که کدام کاربران می توانند به منابع دسترسی داشته باشند.
Speedle+
Speedle+ یک پروژه منبع باز برای رسیدگی به الزامات کنترل دسترسی است. با استفاده از مکانیزم کنترل دسترسی، منطق کنترل دسترسی را به یک موتور سیاست خارجی تبدیل کنید.
محدودکردن سرعت
اجازه دسترسی نامحدود به APIها عمل خوبی نیست. بهترین راه حل این است که یک مکانیسم محدود کننده نرخ داشته باشید.
محدود کردن نرخ برای محافظت از API ها به روش های زیر مفید خواهد بود:
- جلوگیری از حملات DDoS - جلوگیری از نفوذ مهاجمان به شبکه ای با ترافیک زیاد.
- برنامه های استفاده از API را در جای خود قرار دهید - این در هنگام کسب درآمد از API ها سودمند خواهد بود.
- سیاست های استفاده منصفانه را اعمال کنید - هیچ کس نمی تواند تمام منابع یا پهنای باند اختصاص داده شده را مصرف کند.
- جلوگیری از استفاده بیش از حد از سیستم - با محدود کردن نرخ مناسب. محافظت از API ها و بک اند در برابر استفاده بیش از حد ناگهانی و افزایش درخواست ها امکان پذیر است.
نتیجه
APIها در حال حاضر در توسعه اینترنت مدرن و برنامه های دیجیتال ضروری هستند. برنامه‌ها، سرویس‌ها و پلتفرم‌های نرم‌افزاری می‌توانند از آنها برای ترتیب دادن تعاملات استفاده کنند. RESTinterfaces بیش از 80٪ از تمام APIهای عمومی و اختصاصی را تشکیل می دهد. مقاله ما در مورد API چیست را بخوانید تا درک بهتری از تفاوت‌های مهم بین REST و SOAP API داشته باشید.
