امنیت API چگونه تضمین می‌شود؟

API (رابط برنامه نویسی) چیست؟

برای فهم و شناخت بیشتر لازم است که قبل از آشنایی با امنیت API، با خود API یا رابط برنامه نویسی برنامه آشنا شویم. همانطور که در مقاله رابط برنامه نویسی برنامه (API) چیست؟ گفتیم، پیاده‌سازی امنیت رابط برنامه نویسی برنامه (API)، براساس نیازمندی و نوع API (Application programming interface) ، یکی از مسایل حائز اهمیت در حوزه امنیت است. این فرآیند شامل حسابرسی، نظارت، و آزمایش API ها است که به منظور مطابقت آن‌ها با استانداردهای امنیتی و همینطور ایمن‌تر کردن آن‌ها، انجام می‌شود.

تاریخچه API

در دهه ۱۹۷۰، API‌ها اولین پیشرفت بزرگ خود را تجربه کردند. روش‌هایی ایجاد شدند که از طریق بسته‌بندی اطلاعات، به کامپیوترها اجازه دسترسی از راه دور را می‌دادند. یکی دیگر از پیشرفت‌های بزرگ در این دوره، پیدایش میان‌افزار مبتنی بر پیام بود که برای کسب‌وکارها روشی برای یکپارچه‌سازی برنامه‌هایشان در سیستم قدیمیشان ارائه می‌داد. شاید براتان جالب باشد که بدانید اولین بار، API توسظ چه کسی معرفی شد؟؟

API توسط چه کسی معرفی شده است؟

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

امنیت API چیست؟

بر اساس نوع نیازمندی‌ها، می‌توان ازAPI ها در سبک‌های مختلف استفاده کرد. سبک API انتخاب شده که می‌تواند  REST، SOAP، GraphQL، gRPC، WebSocket یاWebhooks  باشد، تصمیم می‌گیرد که چگونه امنیت API باید اعمال و پیاده‌سازی شود. قبل از ایجاد وب API ها، از کلید API، در وب سرویس SOAP استفاده میشد. در عصر وب سرویس با معماری سرویس‌گرا، XML از سال 2000 تا 2010، به طور گسترده مورد استفاده قرار گرفته است.

احراز هویت API

احراز هویت مشخص کننده‌ی هویت یک کاربر نهایی است. در REST API، احراز هویت پایه را می‌توان با استفاده از پروتکل TLS پیاده‌سازی کرد، اما OAuth 2 و OpenID Connect جایگزین‌های امن‌تری هستند.

مجوز:

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

مقایسه پروتکل API

بررسی اجمالی پروتکل‌ها

Use caseها	از لحاظ سازماندهی	قالب	پروتکل
محیط‌های سازمانی بزرگ- راهکار CRM- درگاه پرداخت- مدیریت هویت- خدمات بهداشتی، مالی و مخابراتی- پشتیبانی از سیستم قدیمی	ساختار پیام به صورت پاکت نامه	فقطXML	SOAP
اتصال کامپیوترها- اتصال انواع مختلف محیط‌ها- ایجاد رابط‌های نرم‌افزاری باز	با قابلیت خواندن و نوشتن توسط انسان، استاندارد اسکریپت  قابل Parsing برای درخواست‌ها و پاسخ‌های مبتنی بر HTTP	XML, HTTP	XML-RPC
زیرساخت‌های IoT و IIoT- ارتباط ماشین به ماشین (M2M).- خودرو،  نسل چهارم صنعت، حمل و نقل و سرگرمی	باز کردن پیام	پروتکل مبتنی بر باینری	MQTT
برنامه‌های پیام‌رسانی فوری- اینترنت اشیا (IoT)- بازی آنلاین- اجتماعی- WebRTC، پیوند داده‌ها	پیام‌های فوری (IM)، اطلاعات حضور و نگهداری لیست مخاطبین	XML	XMPP
API عمومی- برنامه های ساده مبتنی بر منابع	با شش محدودیت معماری	JSON, XML, HTML, plain text	REST
تبادل سریع و قابل اعتماد اطلاعات- در اتریوم استفاده می شود	ارسال فراخوان چندگانه به سمت سرور	JSON	JSON-RPC
اتصال بین برنامه‌ها- بازاریابی ایمیلی (Email _ Marketing)- راهکار‌های CRM	“user-defined HTTP callbacks”	JSON، HTTP	Webhooks
موبایل، ساعت‌های هوشمند و IoT API- سیستم پیچیده- خدمات میکرو- ایجاد یک طرح داده	طرح و نوع سیستم	JSON	GraphQL
زیرساخت اینترنت اشیا- کاربردهای ماشین به ماشین (M2M) مانند انرژی هوشمند و اتوماسیون ساختمان	پشتیبانی multicast ، برای تبدیل ساده به HTTP	باینری ساده	CoAP
APIهای دستوری و عملگرا- D2D و D2C برای سیستم‌های تعبیه شده- ارتباطات با کارایی بالا در سیستم میکرو سرویس‌های کلان و محیط ابری- IPC یکپارچه و ارتباط از راه دور	فراخوان رویه محلی	JSON, XML, Protobuf Thrift, Flatbuffers	gRPC

لایه‌های امنیت API

امنیت API بسیار متنوع و شامل چندین لایه است. تمرکز هر لایه بر روی امنیت یک API خاص است و برای رسیدن به یک سطح حفاظتی قوی طراحی شده است.

تشخیص API

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

نسخه‌های قدیمی فراموش شده:

• سیلوی API
• Shadow API
• API های سازمان

روش‌های احراز هویت API:

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

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

احراز هویت مبتنی بر میزبان (Host-based Authentication):

روش احراز هویت مبتنی بر میزبان، به طور گسترده برای دستگاه‌های IOT و احراز هویت شبکه خام استفاده می‌شود. این روش احراز هویت، برای فناوری‌های وب توصیه نمی‌شود زیرا می‌توان با جعل (spoofing) آن را دور زد. این فرآیند شامل تأیید میزبان یا سرور است تا فقط کاربران تأیید شده بتوانند به منابع مستقر در سرورها دسترسی داشته باشند. برای شروع فرآیند به هیچ کلید یا ابزار دیگری نیاز ندارد. با این حال، سرور باید قابلیت تصدیق کلیدهای ورود به سیستم را داشته باشد تا حوادث جعل DNS، جعل مسیریابی و جعل IP را تحت کنترل نگه دارد.

این موضوع از نظر فرآیند و روش، بسیار شبیه به الگوریتم رمزنگاری RSA است. آرگومان مورد استفاده در اینجا با بله یا خیر است. به طور پیش فرض، هیچ آرگومانی تنظیم نشده است. یک Administrator با ایجاد یک کلید خصوصی برای localhost یا استخراج کلید عمومی استفاده شده برای localhost می‌تواند اعتبارسنجی کاربران مبتنی بر میزبان را انجام دهد.

احراز هویت پایه (Basic authentication) در امنیت API:

یکی از ساده‌ترین تمهیدات احراز هویت API ، احراز هویت پایه (Basic authentication) است. تأیید هویت در این روش با استفاده از فرآیند و پروتکل HTTP ایجاد می‌شود. سرویس گیرنده یک درخواست HTTP را با یک header از پیش ساخته شده (برای تأیید صحت و اعتبارنامه مانند رمز عبور حساب و نام کاربری) ارسال می‌کند. این بررسی پایه‌ای در محیطی با مرورگر انجام می‌شود.

پشتیبانی شدن توسط هر مرورگر و سرور، باعث شده است این روش رایج‌ترین روش احراز هویت شناخته شود. جزئیات اعتبارنامه (credential) از طریق شبکه به شکل متن واضح (cleartext) به اشتراک گذاشته می‌شود و با استفاده از base64 کدگذاری می‌شود. جزئیات اعتبارنامه به صورت پیش‌فرض، در قالب متن واضح (یا base64) در شبکه به اشتراک گذاشته می‌شود، امر نادرستی است زیرا موجب حمله مرد میانی (MITM) می‌شود. روش درست این است که اعتبارنامه‌ها را با استفاده از الگوریتم‌هایی مانند RSA، SHA-256 یا حتی الگوریتم‌های سفارشی رمزگذاری کنند.

این روش، بر روی سرورهای پروکسی کار می‌کند و به منابعی که در سرورهای IIS میزبانی نشده‌اند دسترسی می‌دهد. از آنجایی که رمزگذاری را اضافه نمی‌کند، نمی‌توان امنیت زیادی از آن انتظار داشت. همچنین، بیشتر مستعد تکرار حملات است.

روش OAuth در امنیت API:

OAuth روش تایید هویت به صورت باز است. این روش، یک تکنیک تأیید اعتبار رابط یرنامه نویسی برنامه (API) مرسوم است که تأیید هویت کاربران و تعیین معیارهای مجوز را پوشش می‌دهد. این پروتکل به طور گسترده برای اجازه دادن به برنامه‌ها، برای مجوز دادن به کاربران خود بر اساس توکن‌هایی که از سرور OAuth (مانند Google) منتشر شده‌اند، استفاده می‌شود.

هنگامی که شخصی سعی می‌کند وارد سیستم شود، نیاز به یک توکن دارد. توکن در اینجا به عنوان وسیله‌ای برای بررسی و تأیید هویت کاربر عمل می‌کند. شخص یا request-creator باید درخواست را برای دسترسی به منبع، به سرور احراز هویت ارسال کند. بر اساس نتیجه تایید هویت، سرور می‌تواند درخواست را بپذیرد یا رد کند. 

از آنجایی که روش OAuth  امن‌تر و مطمئن‌تر از سایر فرآیندها است، اولین انتخاب بسیاری از افراد است. سه عنصر کلیدی OAuth عبارتند از  provider OAuth،  که گوگل و فیسبوک موارد رایج‌ترین آنها هستند، OAuth Client،  که به وب سایت یا صفحه دارای اطلاعات اشاره دارد و owner، شناسایی کننده‌ی درخواست دسترسی کاربر است.

• 1.کاربر به منابع دسترسی پیدا می‌کند.
• 2. سرویس گیرنده مجوز را درخواست میکند، معمولا با یک log در صفحه
• 3.کاربر اعتبارنامه را قرار می‌دهد.
• 4. سرویس گیرنده اعتبارنامه کاربر را به همراه کلید‌های OAuth انتقال می‌دهد
• 5. سرور مجوزدهی، توکن دسترسی را می‌دهد
• 6. توکن دسترسی انتقال داده می‌شود
• 7. دسترسی به منابع داده می‌شود
• 8. در نهایت کاربر می‌تواند به برنامه کاربردی دسترسی داشته باشد.

روش OAuth 2.0 در امنیت API:

OAuth 2.0 یک پروتکل پرکاربرد برای مدیریت دسترسی API، و نسخه به روز شده OAuth است. عملکرد آن شامل محدود نگه داشتن دسترسی سرویس گیرنده API با استفاده از سرویس‌های HTTP، برای فعال کردن برنامه سرویس گیرنده است. برخی از سرویس‌های HTTP که برای این نوع پروتکل مورد نیاز است،  GitHub و Facebook هستند. برای تأیید هویت از یک کد کمک می‌گیرد و اعتبارنامه کاربر را نمی‌خواهد.

سه عامل کلیدی که در OAuth 2.0 دخیل اند، عبارتند از:

• کاربر، کسی که داده‌ها را در اختیار دارد
• برنامه کاربردی
• رابط برنامه نویسی برنامه (API)

با استفاده از این روش برای تایید هویت، تفسیر داده‌های کاربر با استفاده از منابع مختلف آسان است.  این روش می‌تواند برای تأیید برنامه‌ها / دستگاه‌های مبتنی بر وب، مبتنی بر تلفن همراه، و مبتنی بر دسکتاپ، deploy شود.

OAuth 1.0

• 1. واکشی توکن درخواست
• 2. صدور توکن درخواست
• 3. هدایت کاربر به ارائه‌دهنده برای مجوز
• 4. کاربر مجوز را اعطا می‌کند
• 5. هدایت کاربر به برنامه کاربردی
• 6. تبادل برای اعطای دسترسی
• 7. اعطای توکن دسترسی
• 8. ایجاد ارتباط

OAuth 2.0

• 1. هدایت کاربر به ارائه‌دهنده برای مجوز
• 2. کاربر مجوز را اعطا می‌کند
• 3. هدایت کاربر به برنامه کاربردی
• 4. تبادل برای اعطای دسترسی
• 5. اعطای توکن دسترسی
• 6. ایجاد ارتباط

روش SAML در امنیت API:

SAML مخفف عبارت Security Assertion Markup Language است و یک فرآیند API استاندارد برای تأیید هویت، با استفاده از فناوری سرویس احراز هویت یکپارچه (Single Sign-On) است. این روش کاربر را طبق جزئیات ارائه شده، تایید می‌کند. پس از تکمیل فرآیند و تأیید کاربر، دسترسی به برنامه‌ها / منابع مختلف اعطا می‌شود. در حال حاضر، نسخه SAML 20 آن در حال اجرا است. خیلی شبیه ID است. فقط ارزیابی هویت کاربر با کمک آن انجام می‌شود.

آسیب‌پذیری‌های متداول:

شکستن مجوز در سطح شیء (Broken Object-Level Authorization):

رابط برنامه نویسی برنامه (API)ها اغلب شناسه‌های شی مورد استفاده برای دسترسی به منابع را در معرض افشا قرار می‌دهند.  هنگامی که کنترل دسترسی به درستی در این نقاط پایانی اجرا نمی‌شود، مهاجمان می‌توانند منابعی را که نباید به آنها دسترسی داشته باشند، مشاهده کرده یا بر روی آن‌ها عملیاتی انجام دهند. این آسیب‌پذیری تمام انواع معماری‌های API از جمله SOAP، REST و GraphQL را تحت تاثیر قرار می‌دهد.

به عنوان مثال، یک API را در نظر بگیرید که به کاربران اجازه می‌دهد تا جزئیات مربوط به روش‌های پرداخت خود را بر اساس شناسه کاربری (user ID) خود بازیابی کنند:

در اینجا اگر برنامه، یک مرحله‌ی اضافی برای اثبات هویت در فراخوانی API نداشته باشد و به سادگی داده‌های درخواستی را به هر کسی بازگرداند، اطلاعات حساس در معرض افشا به مهاجمان قرار می‌گیرند. مهاجمان می‌توانند از طریق حدس زدن یا نفوذ با استفاده از حمله brute force شناسه قربانی را پیدا کنند و اطلاعات پرداخت قربانی را از طریق نقطه پایانی API به سرقت ببرند.

گاهی برنامه‌ها به کاربران اجازه می‌دهند تا به جای شناسه‌های کاربری (user ID) خود، بر اساس شناسه شیء(object ID) به اشیاء داده دسترسی داشته باشند و در واقع، پیام‌ها با استفاده از شناسه‌های عددی ارجاع می شوند اگر سرور، کنترل دسترسی را در این نقطه پایانی پیاده‌سازی نکند، مهاجمان می‌توانند این شناسه‌های عددی را با استفاده از حمله brute force پیدا کرده و پیام‌های کاربران را بازیابی کنند. به عنوان مثال، یک مشکل رایج در پیاده‌سازی GraphQL این است که API به کاربران غیرمجاز اجازه می‌دهد تا با تغییر شناسه در درخواست‌ها، داده‌ها را ویرایش کنند.

• کد آسیب پذیر(NET.)
• پیشگیری (NET.)
• کد آسیب پذیر (جاوا)
• پیشگیری (جاوا)

شکستن احراز هویت کاربر (Broken User Authentication):

احراز هویت برای APIها امری دشوار است. معمولا درخواست اعتبارنامه (credentials) کاربر یا استفاده از احراز هویت چند عاملی (multi-factor authentication)، در طول فراخوان‌های API امکان پذیر نیست. به همین دلیل، احراز هویت در سیستم‌های API ، اغلب با استفاده از توکن‌های دسترسی تعبیه‌شده در فراخوان‌های API منحصر به فرد، برای احراز هویت کاربر اجرا می‌شود. اگر احراز هویت به درستی پیاده‌سازی نشود، مهاجمان می‌توانند از این پیکربندی‌های نادرست، برای نشان دادن خود به عنوان شخص دیگری سوء استفاده کنند.

امنیت API بدون احراز هویت:

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

پیاده‌سازی معیوب احراز هویت:

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

یکی از اشتباهات رایج، تولید توکن‌های دسترسی به شیوه‌ای نادرست است. نخست، اگر توکن‌ها، کوتاه، ساده یا قابل پیش‌بینی باشند، مهاجمان ممکن است بتوانند آنها را با استفاده از حمله brute force پیدا کنند. این امر زمانی اتفاق می‌افتد که توکن‌ها با آنتروپی ناکافی تولید شوند یا از اطلاعات کاربر، با استفاده از رمزگذاری یا الگوریتم‌های hash ضعیف، گرفته شده باشند.

به عنوان مثال، مشکل توکن API زیر چیست؟

access_token=aGFkZXNz : این توکن کاربر، با نام کاربری  “hadess”  با استفاده از کدگذاری الگوریتم base64 است. APIهایی که از یک رشته توکن دسترسی ساده استفاده نمی‌کنند، می‌توانند ناامن باشند.

 به عنوان مثال، JSON Web Tokens (JWTs) نیز می‌تواند به‌طور نامناسب امضا شده باشد یا به طور کلی امضا نداشته باشد. این مشکل به ویژه در صورتی خطرناک است که توکن‌های ناامن، برای احراز هویت مدیران یا افراد دارای امتیازات ویژه در API استفاده شوند.

توکن با عمر طولانی:

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

امکان افشای توکن ها:

گاهی اوقات توسعه‌دهندگان، توکن‌های دسترسی را به‌طور ناامن منتقل می‌کنند، به طور مثال، آنها  را از طریق URL‌ها یا ترافیک رمزگذاری نشده، انتقال می‌دهند. اگر یک توکن از طریق یک URL منتقل شود، هر کسی که از طریق  افزونه‌های مرورگر یا تاریخچه مرورگر به URL دسترسی داشته باشد، می‌تواند توکن را سرقت کند. برای سرقت یک توکن API که از طریق ترافیک رمزگذاری نشده منتقل می‌شود، مهاجمان می‌توانند یک حمله مرد میانی (MITM) را ترتیب داده و ترافیک قربانی را رهگیری کنند.

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