API ها، تهدید جدید | امنیت حرفه ای

مصاحبه کردیم کالین تانکارد، مدیرعامل شرکت امنیت سایبری و رمزگذاری داده ها مسیرهای دیجیتال، تصویر، در نسخه چاپی ماه جولای ما. در اینجا او از APIها به عنوان تهدید جدید می نویسد.

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

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

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

علاوه بر این، افزایش تمرکز نظارتی بر نشت داده‌های حساس بر سودآوری تأثیر می‌گذارد و عموم مردم به آن توجه می‌کنند. طراحی ضعیف API و شیوه‌های امنیتی اغلب ریشه نشت داده‌های حساس PII است. نقض Experian را در نظر بگیرید، در اینجا یک نقص در یک API، که برای ارزیابی ارزش اعتباری یک فرد طراحی شده بود، مورد سوء استفاده قرار گرفت. API بر اساس اطلاعاتی که برای شناسایی تماس‌گیرنده API و داده‌های شخصی که در پاسخ ارائه می‌کرد، لو رفت. اطلاعات اعتباری بازگردانده شده توسط Experian API شامل امتیازات Fair Isaac Corporation (FICO) و عوامل خطری است که بر سابقه اعتباری فرد تأثیر می گذارد، مانند نسبت موجودی به اعتبار، تعداد حساب ها و مدت زمان باز شدن حساب ها. این اطلاعات نباید خارج از Experian به اشتراک گذاشته می شد، اما نمونه ای از این بود که چگونه می توان از یک API برای بازیابی اطلاعات بیشتر از آنچه که باید استفاده کرد، استفاده کرد.

گارتنر در مورد امنیت API در گزارشی با عنوان «پیش‌بینی‌های 2022: APIها امنیت و مدیریت بهبود یافته می‌خواهند» گزارش داده است که خطرات را ترسیم می‌کند و حتی پیش‌بینی می‌کند که امنیت API بهترین سوء استفاده در سال 2022 خواهد بود.

این گزارش دارای آخرین روندها و بینش های کلیدی در مورد اقداماتی است که رهبران امنیتی و مهندسی می توانند برای محافظت فعالانه از API ها انجام دهند. گارتنر توصیه می کند که رهبران مهندسی نرم افزار که مسئول فناوری های API هستند، باید:

با سرمایه‌گذاری در کشف، فهرست‌نویسی و اعتبارسنجی خودکار و با استفاده از رویکرد حاکمیت تطبیقی ​​برای مدیریت طیف وسیعی از موارد استفاده و انواع API، همه APIها را مدیریت و اداره کنید.
وضعیت امنیتی API را با توسعه یک استراتژی امنیتی برای محافظت از تهدید، تست امنیت API و کنترل دسترسی API که از رویکردهای جدیدتر و راه حل های فروشنده استفاده می کند، بهبود بخشید.
“با مدیریت فعال مصرف APIها – یعنی استفاده از APIهای داخلی و APIهای شخص ثالث، انعطاف پذیری معماری را بهبود بخشید.”

چه متوجه شوید یا نه، API ها همه جا هستند، و داده های بسیار حساس را به طور مداوم رد و بدل می کنند و آنها را به یک هدف غنی برای مهاجمان تبدیل می کند، که توضیح می دهد که چرا در سال های اخیر شاهد افزایش قابل توجهی در حملاتی که API ها را هدف قرار می دهند، بوده ایم.

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

ابزارها و راه حل های زیادی برای تست API وجود دارد، اما نقاط شروع عبارتند از:

تست دستکاری پارامترها

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

تست برای Command Injection

برای آزمایش اینکه آیا API شما در برابر حملات تزریق فرمان آسیب پذیر است، دستورات سیستم عامل را در ورودی های API تزریق کنید. از دستورات سیستم عامل متناسب با سیستم عاملی که سرور API شما را اجرا می کند استفاده کنید.

تست Fuzzing ورودی API

Fuzzing به معنای ارائه داده های تصادفی به API است تا زمانی که یک مشکل عملکردی یا امنیتی را کشف کنید. شما باید به دنبال نشانه هایی باشید که نشان می دهد API یک خطا را نشان داده است، ورودی ها را اشتباه پردازش کرده یا از کار افتاده است.

روش‌های HTTP کنترل نشده را آزمایش کنید

برنامه های کاربردی وب که با استفاده از API ها ارتباط برقرار می کنند ممکن است از روش های مختلف HTTP استفاده کنند. آزمایش اینکه آیا روش‌های HTTP در سمت سرور پشتیبانی می‌شوند، با درخواست HEAD به نقطه پایانی API که نیاز به احراز هویت دارد، آسان است. همه روش‌های رایج HTTP را امتحان کنید – POST، GET، PUT، PATCH، DELETE، و غیره. اگر روش HTTP در سمت سرور پشتیبانی نمی‌شود، این یک آسیب‌پذیری امنیتی در API ایجاد می‌کند.

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