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

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

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

رابط برنامه نویسی اپلیکیشن (API) توسط چه کسی معرفی شده است؟

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

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

امنیت رابط برنامه نویسی برنامه (API) چگونه تضمین می‌شود؟

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

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

نظارت و تجزیه و تحلیل	کنترل دسترسی	صحت سنجی محتوا	محدودیت نرخ
تشخیص ناهنجاری	مجوز OAuth / سرور منبع	صحت سنجی محتوای ورودی / خروجی	Rate Limits, quotas
بررسی توالی فراخوانی رابط برنامه نویسی اپلیکیشن (API)	تعریف و الزامات قوانین دسترسی	قوانین الگو	حفاظت  Spike
Decoys	مدیریت و الزامات موافقت	تشخیص تهدید مبتنی بر Signature
ارزیابی Geo-fencing و Geo-velocity

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

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

روش‌های احراز هویت رابط برنامه نویسی اپلیکیشن (API)

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

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

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

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

برای شروع فرآیند به هیچ کلید یا ابزار دیگری نیاز ندارد. با این حال، سرور باید قابلیت تصدیق کلیدهای ورود به سیستم را داشته باشد تا حوادث جعل DNS، جعل مسیریابی و جعل IP را تحت کنترل نگه دارد. این موضوع از نظر فرآیند و روش، بسیار شبیه به الگوریتم رمزنگاری RSA است. آرگومان مورد استفاده در اینجا با بله یا خیر است. به طور پیش فرض، هیچ آرگومانی تنظیم نشده است.

یک Administrator با ایجاد یک کلید خصوصی برای localhost یا استخراج کلید عمومی استفاده شده برای localhost می‌تواند اعتبارسنجی کاربران مبتنی بر میزبان را انجام دهد.

احراز هویت پایه (Basic Authentication)

یکی از ساده‌ترین تمهیدات احراز هویت رابط برنامه نویسی اپلیکیشن (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

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 است. فقط ارزیابی هویت کاربر با کمک آن انجام می‌شود.

مجوز

مشخص کننده‌ی منابعی است که یک کاربر تایید شده می‌تواند به آن دسترسی داشته باشد. یک رابط برنامه نویسی اپلیکیشن (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)

1. ابزار Burp Scanner

ابزار Burp Scanner می‌تواند تعاریف API را تجزیه یا به عبارتی parse کند. این ویژگی که بسیاری از اسکنرهای آسیب‌پذیری وب قادر به انجام آن نیستند، باعث می‌شود تا این ابزار بتواند نقاط پایانی (endpoint) رابط برنامه نویسی اپلیکیشن (API) را شناسایی و تست کند.

Burp Scanner با تجزیه (parse) خودکار API ها می‌تواند برای کشف حمله احتمالی کمک کننده باشد. این فرآیند به این ابزار اجازه می‌دهد تا بسیاری از رابط برنامه نویسی اپلیکیشن (API) که حتی برای مرورگرهای وب در نظر گرفته نشده‌اند، را شناسایی و ارزیابی کند.

2. ابزار Postman برای بررسی امنیت API

Postman، توسعه و مدیریت در رابط برنامه نویسی اپلیکیشن (API) خود را به صورت رایگان در اختیار تیم‌های کوچک و توسعه دهندگان مستقل قرار می‌دهد. رده‌های بالاتر  (Postman Pro) و (Postman Enterprise)  از مدیریت رابط برنامه نویسی اپلیکیشن (API) ، همکاری تیمی، پشتیبانی گسترده و سایر موارد پیشرفته پشتیبانی می‌کنند.

3. ابزار SoapUI

SoapUI یک ابزار ارزیابی API و به صورت منبع باز است که توسط کمپانی SmartBear پشتیبانی می‌شود. این ابزار عملکرد و کارایی APIها را مورد تست قرار می‌دهد.

4. ابزار Apigee Sense

 Apigee Sense  که توسط Google در اواخر سال 2016 خریداری شد، APIها را در برابر ترافیک ریکوئست ناخواسته، از جمله حملات کلاینت‌های مخرب محافظت می‌کند. این ابزار ترافیک ریکوئست‌های API را مورد تجزیه و تحلیل قرار می‌دهد و الگوهایی را که ممکن است نشان دهنده‌ی ریکوئست‌های ناخواسته باشد، شناسایی می‌کند.

5. ابزار Wallarm

Wallarm پلتفرمی است که توسط تیم‌های Dev ، Sec و Ops برای ساخت ایمن برنامه‌های کاربردی ابر بومی، نظارت بر تهدیدات مدرن و دریافت هشدار هنگام بروز تهدید استفاده می‌شود.

6. ابزار Cequence Security

Cequence Security یک شرکت نرم‌افزاری امنیت سایبری است که در سال 2015 تأسیس شده و در کالیفرنیا مستقر است. ماموریت آن تبدیل امنیت برنامه‌های کاربردی با ادغام چندین عملکرد امنیتی، به یک پلتفرم نرم‌افزاری باز و مبتنی بر هوش مصنوعی است که از APIهای مشتریان و مبتنی بر وب محافظت می‌کند.

آسیب‌پذیری‌های متداول در رابط برنامه نویسی اپلیکیشن (API)

آسیب‌پذیری کنترل دسترسی

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

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

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

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

به عنوان مثال، یک مشکل رایج در پیاده‌سازی GraphQL این است که API به کاربران غیرمجاز اجازه می‌دهد تا با تغییر شناسه در درخواست‌ها، داده‌ها را ویرایش کنند. در آسیب‌پذیری کنترل دسترسی (Broken Object Level Authorization)، مهاجم می‌تواند به داده‌های محافظت شده دسترسی پیدا کند. کنترل دسترسی شامل چند بخش است که عبارتند از:

• احراز هویت یا Authentication
• مجوز دسترسی یا Authorization
• وظایف یا Accountability

نقص در هر یک از بخش‌های بالا، باعث این آسیب‌پذیری می‌شود. ویژگی‌های شناسایی این آسیب‌پذیری را می‌توان به صورت زیر مشخص نمود:

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

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

2. Excessive Data Exposure

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

• ارسال درخواست با دسترسی مدیر سیستم
• ایجاد، ویرایش و یا حذف سایر کاربران

3. Lack of Resources and Rate Limiting

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

4. Broken Function Level Authorization

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

5. Mass Assignment

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

 آسیب‌پذیری از این نوع دسته‌بندی بر اثر تنظیم نادرست و یا ناقص موارد امنیتی به وجود می‌آید. برخی از این موارد عبارتنند از:

• کلمه عبور های پیش فرض یکسان برای کاربران
• موارد راهنمای نصب

6. عدم تنظیم هدرها

برای مثال فرض کنید در صفحه‌ای، از دستوری مانند sleep برای تاخیر در عملیات استفاده می‌شود. اگر به درستی از این نوع دستورات استفاده نشود، می‌تواند در نهایت منجر به حملات DOS شود.

7. تزریق یا Injection

در این نوع از آسیب‌پذیری‌ها، مهاجم می‌تواند payload خود را در قسمت‌های مختلف برنامه، تزریق کند. از انواع آسیب‌پذیری‌های injection می‌توان به تزریق SQL و یا تزریق command اشاره کرد. زبان پرس و جو SQL راهی برای مدیریت داده‌های ذخیره شده، در پایگاه داده‌های رابطه‌ای است.

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

8. مدیریت نامناسب دارایی‌ها

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

9. عدم نظارت و ثبت log

نرم‌افزارهای مختلف برای اطلاع‌رسانی خود و سایر استفاده کنندگان نرم افزار، از log استفاده می‌کنند. برای مثال پس از ورود کاربر جدید به سیستم و احراز هویت با نام کاربری و کلمه عبور، نرم‌افزار نام کاربری و کلمه عبور را به صورت log نمایش می‌هد. در مثال دیگر نرم‌افزار، پس از ارسال پیام خصوصی به کاربران، پیام را به صورت log نمایش دهد.

چک لیست امنیت API

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

1. احراز هویت در رابط برنامه نویسی اپلیکیشن (API)

• به جای استفاده از Basic Auth از احراز هویت استاندارد استفاده کنید. به عنوان مثال: JWT، OAuth.
• برای احراز هویت، تولید توکن و ذخیره رمز عبور از استانداردها استفاده کنید.
• از ویژگی‌های محدودیت تعدا بیشینه (MAX) تلاش مجدد و تعداد دفعات ورود برای Login استفاده کنید.
• تمامی داده‌های حساس رمزگذاری را رمزگزاری کنید..

2. JWT (JSON Web Token)

• از یک کلید پیچیده تصادفی (JWT Secret) برای سخت کردن حمله  brute force توکن استفاده کنید.
• الگوریتم را از هدر استخراج نکنید. الگوریتم در backend انجام شود. (RS256) یا ( HS256)
• انقضای توکن (TTL, RTTL) را تا حد امکان کوتاه کنید.
• داده‌های حساس را در JWT peyload ذخیره نکنید زیرا می‌توان آن را به راحتی رمزگشایی کرد.
• از ذخیره بیش از حد داده‌ها خودداری کنید. JWT معمولاً در هدرها به اشتراک گذاشته می‌شود و محدودیت اندازه دارند.

3. OAuth

• همیشه redirect_uri سمت سرور را اعتبار سنجی کنید تا فقط بهURLهای لیست سفید اجازه داده شود.
• همیشه سعی کنید کد را مبادله کنید. توکن را مبادله نکنید. (answer_type=token) اجازه داده نشود.
• از پارامتر state با hash تصادفی برای جلوگیری از CSRF در فرآیند احراز هویت OAuth استفاده کنید.
• Scope پیش فرض را تعریف کنید و پارامترهای Scope  برای هر برنامه کاربردی اعتبارسنجی شود.

4. دسترسی در رابط برنامه نویسی اپلیکیشن (API)

• درخواست‌ها (Requests) را محدود کنید تا از حملات DDoS / brute-force جلوگیری شود(Throttling).
• در سمت سرور از HTTPS با TLS 1.2+ و رمزهای امن استفاده کنید تا حملات مرد میانی(MITM) جلوگیری شود.
• از هدر HSTS با SSL برای جلوگیری از حملات SSL Strip استفاده کنید.
• لیست‌های دایرکتوری را خاموش کنید.
• برای APIهای خصوصی، فقط IPهای میزبان‌های لیست سفید، اجازه دسترسی داشته باشند.

5. ورودی

از متد HTTP مناسب با توجه به نوع عملیات استفاده کنید: GET برای خواندن، POST برای ایجاد کردن، PUT/PATCH برای جایگزین یا بروزرسانی و DELETE برای حذف یک رکورد، و در صورتیکه متد ریکوئستی برای منبع درخواست‌ شده مناسب نیست، با 405 Method Not Allowed پاسخ داده شود.

مقدار content-type در هدر Accept ریکوئست (مذاکره محتوا یا Content Negotiation) صحت سنجی شود تا فقط به فرمت‌های مورد پشتیبانی اجازه داده شود. به عنوان مثال :  application/xml، application/json. در صورت عدم مطابقت با 406 Not Acceptable  پاسخ داده شود. مقدار content-type در داده‌ی پست‌شده صحت سنجی شود.(به عنوان مثال: application/x-www-form-urlencoded، multipart/form-data، application/json).

ورودی کاربر صحت سنجی شود تا از آسیب‌پذیری‌های رایج مانند:  XSS، SQL-Injection، Remote Code     Execution جلوگیری شود. از هیچ داده‌ی حساسی مثل (داده‌های اعتبارسنجی، رمزهای عبور، توکن‌های امنیتی یا کلید‌های API)  داخل URL استفاده نشود و از هدر Authorization استاندارد استفاده شود. فقط از رمزگذاری سمت سرور استفاده شود.

از یک سرویس API Gateway برای فعال کردن cache و خط‌مشی‌های Rate Limit استفاده شود. (مثل، Quota ، Spike Arrest یا Concurrent Rate Limit) و منابع رابط برنامه نویسی اپلیکیشن (API) به صورت پویا استقرار (deploy) شود.

6. پردازش

• بررسی کنید که آیا تمامی endpointها توسط احراز هویت محافظت می‌شوند تا از شکستن فرآیند احراز هویت جلوگیری کنید.
• از resource ID خود کاربر باید اجتناب شود. به جای /user/654321/orders از /me/orders استفاده شود.
• به جای افزایش شماره شناسه‌ها به صورت خودکار، از UUID استفاده کنید.
• هنگام تجزیه کردن (parsing) داده‌های XML ، اطمینان حاصل کنید که entity  parsing فعال نیست تا از XXE (حمله (XML xternal entity)) جلوگیری شود.
• هنگام تجزیه کردن (parsing) XML، YAML یا هر زبان دیگری، مطمئن شوید که entity expansion فعال نیست تا از Billion Laughs/XML bomb از طریق حمله گسترش entity expansion جلوگیری شود.
• برای آپلود فایل از CDN استفاده کنید.
• اگر با حجم عظیمی از داده‌ها سروکار دارید، از Workers و Queues برای پردازش تا حد امکان در پس‌زمینه استفاده کنید و پاسخ را سریع برگردانید تا از مسدود شدن HTTP جلوگیری کنید.
• فراموش نکنید که حالت DEBUG را خاموش کنید.
• در صورت امکان از پشته‌های غیر قابل اجرا (non-executable stack) استفاده کنید.

7. خروجی

• هدر X-Content-Type-Options: nosniff ارسال شود.
• هدر X-Frame-Options: deny ارسال شود.
• هدر Content-Security-Policy: default-src ‘none’ ارسال شود.
• هدرهایی که اثر انگشت به جای می‌گذارند، حذف شوند. مانند: X-Powered-By، Server، X-AspNet-Version
• content-type برای پاسخ اجباری شود. به طور مثال اگر application/json را برگردانید، پاسخ content-type، application/json است.
• داده‌های حساس مانند داده‌های اعتبارسنجی، رمزهای عبور یا توکن‌های امنیتی را برنگردانید.
• کد وضعیت متناسب با عملیات تکمیل شده را برگردانید. (به عنوان مثال، 200OK  ، 400 Bad Request ، 401 Unauthorized ، 405 Method Not Allowed)

8. CI و CD

• طراحی و پیاده‌سازی تحت پوشش تست‌های unit/integration انجام شود.
• از فرآیند بازبینی کد استفاده کنید و خود-تاییدی را نادیده بگیرید.
• اطمینان حاصل کنید تمام اجزای سرویس‌ها، قبل از شروع به تولید، از جمله کتابخانه‌ها و سایر وابستگی‌ها، به طور ایستا توسط آنتی ویروس اسکن شده‌اند.
• به طور مداوم ارزیابی‌های امنیتی (تحلیل استاتیک / دینامیک) را روی کد اجرا کنید.
• وابستگی‌ها، اعم از نرم‌افزاری و سیستم عامل را برای آسیب‌پذیری‌های شناخته شده بررسی کنید.
• یک راه حل با قابلیت عقب‌گرد  (rollback) برای استقرار (deploy) طراحی کنید.

سوالات متداول

برای اینکار ما از متخصصان تیم قرمز خود استفاده خواهیم کرد. همانطور که در مقاله‌ی تیم قرمز چیست؟ عنوان شد، تیم قرمز شامل گروهی از متخصصان امنیت است که با کمک روش‌های تست نفوذ، برای آزمایش، ارتقا امنیت و همچنین بهبود کارایی یک سازمان، استخدام می‌شوند.

همچنین با توجه به توضیحات ما درباره‌ی تست نفوذ، در مقاله‌ی تست نفوذ چیست؟، تست نفوذ (pentest)، فرایندی است که در آن یک هکر قانونمند، با ارسال کدهای مخرب، به یافتن آسیب‌پذیری‌ها می‌پردازد و هدف اصلی تست نفوذ، دسترسی غیرمجاز به سیستم به تقلید از یک هکر غیرقانونی است.