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

ابزارهای امنیت API
ابزار Burp Scanner
ابزار Burp Scanner میتواند تعاریف رابط برنامه نویسی برنامه را تجزیه(parse) کند. این ویژگی که بسیاری از اسکنرهای آسیبپذیری وب قادر به انجام آن نیستند، باعث میشود تا این ابزار بتواند نقاط پایانی(endpoint) رابط برنامه نویسی برنامه (API) را شناسایی و تست کند. با تجزیه (parse) خودکار تعاریف OpenAPI v3 REST API نوشته شده در JSON، Burp Scanner میتواند برای کشف حمله احتمالی کمک کننده باشد. این فرآیند به این ابزار اجازه میدهد تا بسیاری از رابط برنامه نویسی برنامه (API)ها که حتی برای مرورگرهای وب در نظر گرفته نشدهاند، را شناسایی و ارزیابی کند.
ابزار Postman در رابط برنامه نویسی برنامه:
Postman که دفتر مرکزی آن در سانفرانسیسکو قرار دارد، توسعه و مدیریت در رابط برنامه نویسی برنامه (API) خود را به صورت رایگان در اختیار تیمهای کوچک و توسعه دهندگان مستقل قرار میدهد. ردههای بالاتر (Postman Pro) و (Postman Enterprise) از مدیریت رابط برنامه نویسی برنامه (API) ، همکاری تیمی، پشتیبانی گسترده و سایر موارد پیشرفته پشتیبانی میکنند.

ابزار SoapUI:
SoapUI یک ابزار ارزیابی API و به صورت منبع باز است که توسط کمپانی SmartBear پشتیبانی میشود. این ابزار عملکرد و کارایی API ها را مورد تست قرار میدهد.
ابزار Apigee Sense:
Apigee Sense که توسط Google در اواخر سال 2016 خریداری شد، رابط برنامه نویسی برنامه (API)ها را در برابر ترافیک ریکوئست ناخواسته، از جمله حملات کلاینتهای مخرب محافظت میکند. این ابزار ترافیک ریکوئستهای API را مورد تجزیه و تحلیل قرار میدهد و الگوهایی را که ممکن است نشان دهندهی ریکوئستهای ناخواسته باشد، شناسایی میکند.
ابزار Wallarm:
Wallarm پلتفرمی است که توسط تیمهای Dev ، Sec و Ops برای ساخت ایمن برنامههای کاربردی ابر بومی، نظارت بر تهدیدات مدرن و دریافت هشدار هنگام بروز تهدید استفاده میشود.
ابزار Cequence Security در رابط برنامه نویسی برنامه:
Cequence Security یک شرکت نرمافزاری امنیت سایبری است که در سال 2015 تأسیس شده و در کالیفرنیا مستقر است. ماموریت آن تبدیل امنیت برنامههای کاربردی با ادغام چندین عملکرد امنیتی، به یک پلتفرم نرمافزاری باز و مبتنی بر هوش مصنوعی است که از رابط برنامه نویسی برنامه (API)های مشتریان و مبتنی بر وب محافظت میکند.

ابزار Broken Object Level Authorization:
در آسیبپذیری، مهاجم میتواند به دادههای محافظت شده دسترسی پیدا کند.
کنترل دسترسی شامل چند بخش است که عبارتنند از:
- احراز هویت یا Authentication
- مجوز دسترسی یا Authorization
- وظایف یا Accountability
نقص در هر یک از بخشهای بالا، باعث این آسیبپذیری میشود.

ویژگیهای شناسایی این آسیبپذیری را میتوان به صورت زیر مشخص نمود:
Broken User Authentication در رابط برنامه نویسی برنامه (API):
در این آسیبپذیری مهاجم با استفاده از عدم کنترل و بررسی کافی فرآیند احراز هویت قربانی، سبب دسترسی به اطلاعات بدون احراز هویت و یا با احراز هویت ناقص خواهد شد. همچنین در کلیه روشهای پیادهسازی فرآیندهای احراز هویت، به سبب عدم بررسی وضعیت کاربر و پیادهسازی صحیح فرآیند احراز هویت امکان Bypass نمودن فرآیند و احراز هویت مهاجم به عنوان قربانی وجود دارد.
Excessive Data Exposure:
کنترل دسترسی باعث ایجاد دسترسی به مطالب و عملکردها برای برخی از کاربران و محدودیت برای برخی از آنها میشود. آسیبپذیریهایی که در این دسته بندی قرار میگیرند، باعث نقض محدودیت و دسترسی منابع محدود شده، میشود.
از نمونههای این آسیبپذیری میتوان به موارد زیر اشاره کرد.
- ارسال درخواست با دسترسی مدیر سیستم
- ایجاد، ویرایش و یا حذف سایر کاربران
Lack of Resources and Rate Limiting:
در این آسیبپذیری، مهاجم امکان دسترسی به اطلاعات و منابع به دلیل حجم بالای درخواست دسترسی و در نهایت دسترسی نادرست به منابع توسط مهاجم بدون دسترسی لازم وجود دارد. همچنین امکان اختلال در دادههای سامانه به دلیل عدم کنترل محدودیتهای لازم در ایجاد و ویرایش و دسترسی به منابع توسط مهاجم وجود دارد.

Broken Function Level Authorization:
با استفاده از آسیبپذیری فوق، امکان انجام فعالیتهای دارای کنترل دسترسی توسط مهاجم، بدون دسترسی کافی برای اقدامات مقتضی وجود دارد. همچنین امکان تغییر در یکپارچگی سامانه با استفاده از تزریق و ویرایش دادههای سامانه توسط مهاجم نیز وجود خواهد داشت.
Mass Assignment:
یکی از روشهای دسترسی به اطلاعات استفاده از پارامترهای کلیدی به عنوان معیار تعیینکننده برای دسترسی به اطلاعات است. در این آسیبپذیری، مهاجم میتواند با استفاده از درهمسازی پارامترها به اطلاعات محافظت شده، بدون دسترسی اولیه (از قبل)، به سیستم دسترسی پیدا نماید.
Security Misconfiguration:
آسیبپذیری از این نوع دستهبندی بر اثر تنظیم نادرست و یا ناقص موارد امنیتی به وجود میآید. برخی از این موارد عبارتنند از:
- کلمه عبور های پیش فرض یکسان برای کاربران
- موارد راهنمای نصب
عدم تنظیم هدرهای امنیت API:
برای مثال فرض کنید در صفحهای، از دستوری مانند sleep برای تاخیر در عملیات استفاده میشود. اگر به درستی از این نوع دستورات استفاده نشود، میتواند در نهایت منجر به حملات DOS شود.
Injection:
در این نوع از آسیبپذیریها، مهاجم میتواند payload خود را در قسمتهای مختلف برنامه، تزریق کند. از انواع آسیبپذیریهای injection میتوان به تزریق SQL و یا تزریق command اشاره کرد. زبان پرس و جو SQL راهی برای مدیریت دادههای ذخیره شده، در پایگاه دادههای رابطهای است. به این معنا که میتوانیم در هر بستری از جمله وب، دادهها را ذخیره، ویرایش و یا تغییر دهیم. گاهی اوقات احراز هویت کاربران، نمایش محتوای وبسایت و یا عکسهای کاربران در پایگاه داده ذخیره میشود و توسط SQL در مسیرهای مختلف به کار برده میشود. حال فرض کنید attacker در پرس و جوی sql، دستکاری و یا Inject کند. در اینجا میگوییم SQL Injection رخ داده است.
Improper Assets Management:
در این آسیبپذیریها، امکان دسترسی مهاجم به داراییهای سامانه، بدون دسترسی کافی و اطلاعات کافی از داراییهای موجود رخ میدهد. با استفاده از آسیبپذیری فوق، مهاجم امکان دسترسی به اطلاعات سامانه را بدون اطلاع صاحب سامانه خواهد داشت.
Insufficient Logging and Monitoring:
نرمافزارهای مختلف برای اطلاعرسانی خود و سایر استفاده کنندگان نرم افزار، از log استفاده میکنند. برای مثال پس از ورود کاربر جدید به سیستم و احراز هویت با نام کاربری و کلمه عبور، نرمافزار نام کاربری و کلمه عبور را به صورت log نمایش میهد. در مثال دیگر نرمافزار، پس از ارسال پیام خصوصی به کاربران، پیام را به صورت log نمایش دهد.

چک لیست امنیت API
چک لیستی از مهمترین اقدامات متقابل امنیتی هنگام طراحی، آزمایش و انتشار رابط برنامه نویسی برنامه (API):
احراز هویت در رابط برنامه نویسی برنامه (API):
- به جای استفاده از Basic Auth از احراز هویت استاندارد استفاده کنید. به عنوان مثال: JWT، OAuth.
- برای احراز هویت، تولید توکن و ذخیره رمز عبور از استانداردها استفاده کنید.
- از ویژگیهای محدودیت تعدا بیشینه (MAX) تلاش مجدد و تعداد دفعات ورود برای Login استفاده کنید.
- تمامی دادههای حساس رمزگذاری را رمزگزاری کنید..
JWT (JSON Web Token):
- از یک کلید پیچیده تصادفی (JWT Secret) برای سخت کردن حمله brute force توکن استفاده کنید.
- الگوریتم را از هدر استخراج نکنید. الگوریتم در backend انجام شود. (RS256) یا ( HS256)
- انقضای توکن (TTL, RTTL) را تا حد امکان کوتاه کنید.
- دادههای حساس را در JWT peyload ذخیره نکنید زیرا میتوان آن را به راحتی رمزگشایی کرد.
- از ذخیره بیش از حد دادهها خودداری کنید. JWT معمولاً در هدرها به اشتراک گذاشته میشود و محدودیت اندازه دارند.
OAuth:
- همیشه redirect_uri سمت سرور را اعتبار سنجی کنید تا فقط بهURLهای لیست سفید اجازه داده شود.
- همیشه سعی کنید کد را مبادله کنید. توکن را مبادله نکنید. (answer_type=token) اجازه داده نشود.
- از پارامتر state با hash تصادفی برای جلوگیری از CSRF در فرآیند احراز هویت OAuth استفاده کنید.
- Scope پیش فرض را تعریف کنید و پارامترهای Scope برای هر برنامه کاربردی اعتبارسنجی شود.
دسترسی در رابط برنامه نویسی برنامه (API):
- درخواستها (Requests) را محدود کنید تا از حملات DDoS / brute-force جلوگیری شود(Throttling).
- در سمت سرور از HTTPS با TLS 1.2+ و رمزهای امن استفاده کنید تا حملات مرد میانی(MITM) جلوگیری شود.
- از هدر HSTS با SSL برای جلوگیری از حملات SSL Strip استفاده کنید.
- لیستهای دایرکتوری را خاموش کنید.
- برای رابط برنامه نویسی برنامه (API)های خصوصی، فقط IPهای میزبانهای لیست سفید، اجازه دسترسی داشته باشند.
ورودی:
از متد 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) شود.
پردازش:
- بررسی کنید که آیا تمامی 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) استفاده کنید.
خروجی:
- هدر 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)
CI و CD:
- طراحی و پیادهسازی تحت پوشش تستهای unit/integration انجام شود.
- از فرآیند بازبینی کد استفاده کنید و خود-تاییدی را نادیده بگیرید.
- اطمینان حاصل کنید تمام اجزای سرویسها، قبل از شروع به تولید، از جمله کتابخانهها و سایر وابستگیها، به طور ایستا توسط آنتی ویروس اسکن شدهاند.
- به طور مداوم ارزیابیهای امنیتی (تحلیل استاتیک / دینامیک) را روی کد اجرا کنید.
- وابستگیها، اعم از نرمافزاری و سیستم عامل را برای آسیبپذیریهای شناخته شده بررسی کنید.
- یک راه حل با قابلیت عقبگرد (rollback) برای استقرار (deploy) طراحی کنید.

سوالات متداول:
چگونه میتوان رابط برنامه نویسی برنامه (API) را از حمله مهاجمان ایمن کرد؟
- استفاده از مجوز دسترسی و احراز هویت قوی
- اولویتبندی کردن امنیت
- فهرست کردن و مدیریت رابط برنامه نویسی برنامه (API)ها
- رعایت کردن اصل حداقل بودن مجوز دسترسی
- رمزگذاری ترافیک با استفاده از TLS
- حذف اطلاعاتی که قرار نیست به اشتراک گذاشته شوند
- در معرض افشا قرار ندادن دادهها بیش از حد لزوم
- صحت سنجی ورودی
- استفاده از محدودیت نرخ درخواست
- استفاده از فایروال برنامه کاربردی تحت وب (WAF)
چگونه رابط برنامه نویسی برنامه (API) سفارشی Java یا Net. خود را ایمن کنم؟
زبانهایی مانند Java یا .Net شامل JSON Web Token (JWT) هستند که تنها با استفاده از یک نمونه JWT در برابر مهاجمان آسیبپذیر میشوند. بدین منظور سامانههای SAST برای پویش و پیدا نمودن آسیبپذیری در سطح سورس کد موثر است. برای آشنایی بیشتر با تست استاتیک اپلیکیشن (SAST) و با دریافت مشاوره از متخصصین امنیت سایبری حادث، با ما در تماس باشید.
بهترین راه برای بررسی APIها و برنامههای مرتبط برای آسیبپذیریهای امنیتی چیست؟
- بهترین راه برای بررسی آسیبپذیریهای امنیتی عبارتند از:
- روش تشخیص غیرفعال: در این روش آسیبپذیری به دلیل رخ دادن حادثه امنیتی تشخیص داده میشود.
- اعتبارسنجی تهدید فعال
- اسکنر آسیبپذیری: تمام عناصر محدوده (scope) برای آسیبپذیریهای رایج اسکن میشوند.
با توجه به مواردی که در این مقاله مطرح کردیم، متوجه شدیم که امنیت رابط برنامه نویسی برنامه (API) از اهمیت ویژهای برخوردار است. شرکت حادث با تست و بررسی درگاههای API شما میتواند آسیبهای امنیت سایبری موجود را برطرف و از ایجاد آسیبپذیری در آینده جلوگیری کند.

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