رابط برنامه‌نویسی کاربردی (API) روشی است که به یک نرم‌افزار اجازه تعامل با نرم‌افزارهای دیگر می‌دهد. با API، کاربران خارجی می‌توانند از یک برنامه یا اپلیکیشن درخواست‌های متفاوتی داشته باشند.
امنیت API فرایند محافظت از APIها است. همان‌طور که برنامه‌ها، شبکه‌ها و سرورها ممکن است هدف حملات قرار بگیرند، APIها نیز می‌توانند به شیوه‌های مختلف در خطر باشند.
امنیت API جز اصلی امنیت برنامه‌های وب است. بیشتر برنامه‌های وب مدرن به عملکرد APIها وابسته هستند و این APIها با اجازه‌دادن به طرف‌های خارجی برای دسترسی به برنامه، ریسک محیط آن را اضافه می‌کنند. به‌عنوان‌مثال، می‌توان یک کسب‌وکار را در نظر گرفت که دفتر خود را برای عموم مردم باز می‌کند؛ حضور افراد بیشتر در محل، برخی از آن‌ها که ممکن است برای کارکنان کسب‌وکار ناشناخته باشند، ریسک بیشتری به همراه دارد. به همین ترتیب، یک API به افراد خارج از سازمان اجازه می‌دهد تا از یک برنامه استفاده کنند و این امر خطرات بیشتری را برای زیرساخت خدمات API به همراه دارد.
ریسک‌های رایج امنیت API
- سوءاستفاده از آسیب‌پذیری‌ها: سوءاستفاده از آسیب‌پذیری زمانی است که یک مهاجم داده‌های خاصی را به هدف ارسال می‌کند که از یک نقص در ساختار هدف، سوءاستفاده می‌کند. این نقص‌ها که به عنوان “آسیب‌پذیری‌ها” شناخته می‌شوند، می‌توانند دسترسی‌های ناخواسته‌ای به API یا برنامه مربوط آن را به مهاجم بدهند. اگر آسیب‌پذیری که قبلاً ناشناخته بوده است، هدف قرار گیرد، به آن تهدید روز صفر گفته می‌شود که به‌سختی حل می‌شود.
- حملات مبتنی بر تأیید هویت: مشتریان باید قبل از ارسال درخواست‌های API تأیید هویت شوند تا سرور API درخواست‌هایی از منابع ناشناخته یا غیرمعتبر نپذیرد. راه‌های مختلفی برای انجام این کار وجود دارد، اما هر روش ممکن است در معرض خطر قرار گیرد. به‌عنوان مثال، یک مهاجم می‌تواند اعتبارنامه‌های یک مشتری معتبر را به دست آورد، یک کلید API بدزدد یا یک توکن تأیید هویت را ره‌گیری و استفاده کند.
- خطاهای مجوز: مجوز تعیین می‌کند که هر کاربر چه سطحی از دسترسی دارد. اگر مجوز به‌طور دقیق مدیریت نشود، یک مشتری API ممکن است به داده‌هایی غیرمجاز دسترسی پیدا کند و این امر احتمال نقض داده‌ها را افزایش می‌دهد.
- حملات DoS و DDoS: درخواست‌های بیش از حدی که به یک API ارسال می‌شود، می‌تواند خدمات را برای سایر مشتریان کند یا متوقف کند. برخی از مهاجمان عمداً تعداد زیادی درخواست به یک API ارسال می‌کنند که به آن حمله انکار خدمات (DoS) یا حمله انکار خدمات توزیع‌شده (DDoS) گفته می‌شود.
استراتژی‌های امنیت API می‌توانند به این ریسک‌ها کمک کنند.
اقدامات قوی در زمینه تأیید هویت و مجوز به عدم نشت داده‌ها کمک می‌کند تا فقط مشتریان مجاز درخواست‌های API را ارسال کنند. حفاظت در برابر DDoS و محدودیت نرخ می‌تواند حملات DDoS را متوقف کند. اعتبارسنجی ساختار و استفاده از یک فایروال برنامه وب (WAF) می‌تواند سواستفاده از آسیب‌پذیری‌ها را مسدود کند.
کاربرد محدودیت نرخ و کاهش DDoS چگونه در محافظت از APIها
محدودیت نرخ سقفی بر تعداد دفعاتی که یک نفر می‌تواند در یک بازه زمانی خاص عملی را تکرار کند، قرار می‌دهد. اگر یک مشتری API تعداد درخواست‌های مجاز را تجاوز کند، محدودیت نرخ درخواست‌های اضافی را برای مدت‌زمان مشخصی رد یا مسدود می‌کند.
کاهش DDoS به متوقف کردن حملات DoS و DDoS کمک می‌کند. در یک حمله DDoS، یک مهاجم سعی دارد یک API را با تعداد زیادی درخواست در مدت‌زمان کوتاه تحت‌فشار قرار دهد. معمولاً این درخواست‌ها از چندین منبع مختلف می‌آیند.
محدودیت نرخ و کاهش DDoS برای API ها به چند دلیل ضروری هستند:
- متوقف کردن حملات DoS و DDoS: با مسدودکردن یا رد درخواست‌های اضافی، محدودیت نرخ و کاهش DDoS از تحت‌فشار قرارگرفتن API جلوگیری می‌کند. محدودیت نرخ به‌تنهایی ممکن است حملات DDoS کم‌سرعت و کُند را متوقف نکند، اما کاهش DDoS می‌تواند ترافیک اضافی را جذب کند.
- فراتر از حملات عمدی، برخی مشتریان ممکن است به‌سادگی از یک API بیش از حد استفاده کنند. این موضوع هزینه‌هایی برای خدمات API از نظر قدرت پردازش به همراه دارد و می‌تواند خدمات را برای سایر مشتریان کند، کند. محدودیت نرخ به جلوگیری از بارگذاری بیش از حد سرور API کمک می‌کند.
مسدود کردن سواستفاده از آسیب‌پذیری‌ها
چند روش وجود دارد که توسعه‌دهندگان API می‌توانند این درخواست‌های مخرب را مسدود کنند. دو مورد از مهم‌ترین آن‌ها عبارت‌اند از:
- اعتبارسنجی ساختار
ساختار API رفتار مورد انتظار API را توصیف می‌کند: نوع درخواست‌هایی که باید دریافت کند و نوع پاسخ‌هایی که باید ارائه دهد. درخواست‌های نامعتبر که با این ساختار مطابقت ندارند می‌توانند باعث شوند که API به شیوه‌های غیرمنتظره عمل کند و احتمالاً منجر به نشت داده شود. اعتبارسنجی ساختار درخواست‌ها و پاسخ‌های نامعتبر را شناسایی می‌کند. با مسدودکردن پاسخ‌های نامعتبر، توسعه‌دهندگان API می‌توانند از برخی انواع حملات جلوگیری کرده و به پیشگیری از نشت داده‌ها کمک کنند. - قوانین WAF
یک WAF مانند یک فایروال سنتی عمل می‌کند و برخی از درخواست‌ها و پاسخ‌های شبکه را مسدود کرده و اجازه می‌دهد بقیه اطلاعات عبور کنند که بر اساس مجموعه‌ای از قوانین انجام می‌شود: اگر یک درخواست یا پاسخ قانونی نقض شود یا با یک قانون مطابقت داشته باشد، مسدود می‌شود .WAF بر یک API یا برنامه وب مستقر می‌شود و ترافیک HTTP را نظارت می‌کند.
امکان تنظیم قوانین WAF وجود دارد که الگوهای درخواست و پاسخ را که هدف یک آسیب‌پذیری هستند، مسدود کند. قوانین WAF همچنین می‌توانند درخواست‌ها را از آدرس‌های IP خاص مسدود کنند که به توقف حملات ربات و دیگر مهاجمان کمک می‌کند.
اهمیت تأیید هویت و مجوز برای امنیت API
تأیید هویت تضمین می‌کند که درخواست‌های API از یک منبع معتبر می‌آیند. مجوز به سرور API اجازه می‌دهد بداند که آیا مشتری درخواست‌کننده مجاز به دریافت داده‌های درخواست‌شده است یا خیر.
به‌عنوان مثال، فرض کنید آلیس یک API طراحی می‌کند و باب یک برنامه وب می‌سازد که از API آلیس استفاده می‌کند. زمانی که برنامه باب یک درخواست API به API آلیس ارسال می‌کند، او برچسبی به درخواست می‌چسباند که می‌گوید “از طرف باب”. این برچسب درخواست باب را تأیید می‌کند تا سرور API آلیس بداند که درخواست را به‌عنوان درخواستی معتبر در نظر بگیرد.
سرور API آلیس امتیازات باب را هم بررسی می‌کند. اگر درخواست باب برای داده‌ای باشد که API آلیس آن را “قابل‌مشاهده به‌وسیله باب” برچسب‌گذاری کرده است، سرور درخواست را انجام می‌دهد. با این حال، API آلیس ممکن است بخشی از داده‌ها را با برچسب “غیرمجاز برای باب” داشته باشد و سرور نباید درخواستی برای آن داده را زمانی که باب درخواست‌کننده است، انجام دهد. به همین دلیل است که مجوز مهم است. در واقع، باب یک کلید یا نوع دیگری از تأیید هویت را به درخواست‌های API پیوست می‌کند.
چندین روش تأیید هویت برای API ها وجود دارد. رایج‌ترین آن‌ها عبارت‌اند از:
۱. کلید API
به مشتری یک کلید اختصاص داده می‌شود – یک رشته منحصربه‌فرد از کاراکترها که فقط آن‌ها و سرویس API آن را می‌دانند. این کلید به هر درخواست API پیوست می‌شود. سرور API هنگام دریافت یک درخواست API، کلید را بررسی می‌کند تا مطمئن شود که از یک مشتری تأییدشده است.
معایب این روش تأیید هویت این است که اگر کلید دزدیده شود، یک مهاجم می‌تواند از آن برای جعل هویت یک مشتری معتبر استفاده کند و انواع مختلفی از حملات را انجام دهد. مهم است که درخواست‌ها و پاسخ‌ها به و از یک API را با استفاده از پروتکل رمزگذاری مانند TLS رمزگذاری کرد تا کلید به‌صورت متن ساده در حین عبور از اینترنت افشا نشود.
۲. نام کاربری و رمز عبور
درخواست‌های API می‌توانند از اعتبارنامه‌های معمول نام کاربری و رمز عبور برای تأیید هویت از طریق روشی به نام تأیید هویت HTTP استفاده کنند. در تأیید هویت HTTP، نام کاربری و رمز عبور رمزگذاری شده و برای تمام درخواست‌های API اضافه می‌شوند. سرور می‌تواند این اعتبارنامه‌ها را با اعتبارنامه‌های مشتریان مجاز بررسی کند تا درخواست‌ها را تأیید کند.
این رویکرد با تمام چالش‌های معمول مرتبط با رمزهای عبور همراه است: رمزهای عبور می‌توانند گم شوند، نشت کنند، دزدیده شوند، حدس زده شوند یا با طرف‌های غیرقابل‌اعتماد به اشتراک گذاشته شوند. همچنین رمزهای عبور در معرض حملات پر کردن اعتبارنامه و حملات brute force قرار دارند.
۳. توکن OAuth
به‌جای اینکه تأیید هویت مستقیماً از مشتری درخواست شود، سرور API می‌تواند یک توکن تأیید هویت از یک سرور تأیید هویت معتبر با استفاده از پروتکل OAuth دریافت کند. برای استفاده از API، کاربر به‌جای اینکه مستقیماً به API وارد شود، به یک سرویس واسط وارد می‌شود. مانند روش نام کاربری و رمز عبور، این روش تأیید هویت نیز در معرض حملات پر کردن اعتبارنامه و دیگر حملات است.
۴. mTLS
TLS پروتکل رمزگذاری است که TLS آن را در یک اتصال رمزگذاری شده و تأییدشده بین مشتری و سرور هنگام بارگذاری صفحات وب ایجاد می‌کند . همچنین می‌تواند هر دو طرف یک اتصال API را تأیید و تصدیق کند.
در mTLS، هم مشتری و هم سرور دارای یک گواهی TLS هستند. آن‌ها با استفاده از این گواهی‌ها یکدیگر را تأیید می‌کنند و اطمینان حاصل می‌کنند که هویت هر دو، بدون نیاز به اتکا به رمزهای عبور یا دیگر روش‌های تأیید هویتُ واقعی است. بااین‌حال، پیاده‌سازی mTLS می‌تواند چالش‌برانگیز باشد: تمام API نقاط پایانی و کاربران نیاز به گواهی‌های معتبر TLS دارند که اجرا و نگهداری آن‌ها می‌تواند سخت باشد.
