10 تهدید برتر برنامه وب OWASP

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

این سند رویکردهای مختلفی را توصیف می‌کند که می‌توانید در Apigee برای رفع آسیب‌پذیری‌های امنیتی شناسایی‌شده توسط OWASP استفاده کنید. برای رویکردهای اضافی مستند شده برای Apigee، به 10 گزینه برتر کاهش 2021 OWASP در Google Cloud مراجعه کنید.

نمای کلی

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

OWASP یک جامعه باز است که به سازمان ها کمک می کند تا برنامه ها و API های قابل اعتماد را توسعه دهند، خریداری کنند و نگهداری کنند. از طریق پروژه امنیت API OWASP ، OWASP بحرانی ترین خطرات امنیتی را برای برنامه های کاربردی وب و API های REST منتشر می کند و توصیه هایی برای رسیدگی به این خطرات ارائه می دهد.

با Apigee، لایه پروکسی API می‌تواند درخواست‌های API نادرست از مشتری را قبل از پردازش درخواست‌ها در سیستم‌های باطن، شناسایی، مسدود کرده و گزارش کند، بنابراین خطرات را کاهش داده و از خدمات شما محافظت می‌کند. درخواست‌های نادرست می‌توانند شامل هر مؤلفه‌ای باشند که پروتکل سطح برنامه HTTP را می‌سازد:

  • URL
  • سرصفحه ها
  • مسیر
  • بار

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

پلتفرم مدیریت هوشمند API Apigee به شما این امکان را می‌دهد که آسیب‌پذیری‌های امنیتی OWASP API را به‌طور یکپارچه برطرف کنید، زیرا رویکردی متمرکز بر مصرف برای طراحی APIهای خود و اتصال آنها به سیستم‌های باطن خود دارید. در زیر فهرستی از سیاست ها/پیکربندی هایی که Apigee برای تهدیدات REST OWASP برتر توصیه می کند، آمده است.

راه حل های Apigee برای 10 OWASP برتر 2017

نگرانی های امنیتی زیادی در مورد ایجاد و ایمن سازی برنامه های کاربردی وب وجود دارد. OWASP لیست 10 تهدید امنیتی برتر OWASP 2017 را برای برنامه های تحت وب منتشر کرد. در حالی که بخش های زیادی در یک برنامه وب وجود دارد، اکثر برنامه های وب مدرن به شدت به API های REST متکی هستند. Apigee قرار نیست تمام نیازهای امنیتی یک برنامه وب را برطرف کند، اما می تواند نقشی اساسی در ایمن سازی API های REST داشته باشد. در زیر مهمترین تهدیدات امنیتی OWASP با توضیحاتی در مورد نحوه استفاده از Apigee برای کمک به مقابله با این تهدیدها آورده شده است.

A1:2017 - تزریق

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

چندین روش برای اعتبارسنجی ورودی با پلتفرم Apigee وجود دارد:

اعتبارسنجی انواع محتوا:

A2:2017 - احراز هویت شکسته و مدیریت جلسه

مهاجمان می‌توانند با استفاده از نقص‌های پیاده‌سازی در برنامه‌ها، به رمزهای عبور، نشانه‌های جلسه و کلیدها برای جعل هویت سایر کاربران دسترسی داشته باشند. این بیشتر یک مشکل پیاده سازی است و مشکل محصول نیست. Apigee خط‌مشی‌های VerifyApiKey، OAuth و JSON Web Token (JWT) را ارائه می‌کند که به محافظت در برابر این آسیب‌پذیری کمک می‌کند.

اعتبار سنجی کلید API

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

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

اصطلاح "کلیدهای API" گاهی اوقات می تواند به معنای متفاوت باشد. در Apigee، زمانی که رابطه برنامه و محصول شکل می‌گیرد، Apigee شناسه مشتری و راز مشتری تولید می‌کند. برخی به ID و Secret به عنوان کلید API اشاره می کنند. برخی فقط به شناسه مشتری به عنوان کلید API اشاره می کنند. در رابط کاربری Edge، "کلید مصرف کننده" و "محرمانه مصرف کننده" را خواهید دید.

در خط‌مشی VerifyAPIKey ، فقط شناسه مشتری یا «کلید مصرف‌کننده» تأیید می‌شود. زمانی که برنامه‌نویسان برنامه خود را در Apigee ثبت می‌کنند و برنامه را با یک محصول API مرتبط می‌کنند، یک کلید مصرف‌کننده دریافت می‌کنند. برنامه‌نویسان کلید مصرف‌کننده را در تماس‌هایی که برنامه با پراکسی‌های API انجام می‌دهد که در محصول API همراه هستند، شامل می‌شوند.

Apigee همچنین از توانایی وارد کردن کلیدهای API موجود از منابع خارجی پشتیبانی می کند.

برای انواع کمک هزینه OAuth، هر دو شناسه مشتری و مخفی استفاده می شود.

OAuth 2.0

چارچوب مجوز OAuth 2.0 به یک برنامه شخص ثالث امکان دسترسی محدود به سرویس HTTP را می دهد، یا از طرف مالک منبع با هماهنگ کردن تعامل تأیید بین مالک منبع و سرویس HTTP، یا با اجازه دادن به برنامه شخص ثالث از طرف خود دسترسی پیدا کند.

خط‌مشی‌های OAuth 2.0 Apigee به شما امکان می‌دهد چهار نوع کمک مالی OAuth 2.0 را پیاده‌سازی و سفارشی کنید. اجرای نشانه دسترسی OAuth را می توان با استفاده از خط مشی OAuthv2 انجام داد. مصرف‌کننده باید ثبت‌نام شده باشد و برنامه‌ای تأیید شده باشد که به او اجازه دسترسی به API را داده است. در ازای آن، آنها شناسه مشتری API و راز مشتری دریافت خواهند کرد. مصرف‌کننده برای احراز هویت باید یکی از کمک‌های OAuth را طی کند، که به او یک توکن دسترسی غیرشفاف می‌دهد. این توکن می تواند برای کنترل دسترسی به API استفاده شود.

JWT

JSON Web Tokens یا JWT معمولاً برای به اشتراک گذاشتن ادعاها یا ادعاها بین برنامه های کاربردی متصل استفاده می شود. Apigee پشتیبانی JWT را با استفاده از سه خط مشی ارائه می کند.

  • GenerateJWT Tokens (پشتیبانی از امضای HS256 و RS256)
  • اعتبارسنجی توکن های JWT
  • رمزگشایی توکن های JWT بدون اعتبار سنجی

A3:2017 - قرار گرفتن در معرض داده های حساس

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

TLS (Transport Layer Security، که سلف آن SSL است) فناوری امنیتی استاندارد برای ایجاد یک پیوند رمزگذاری شده بین یک وب سرور و یک سرویس گیرنده وب، مانند یک مرورگر یا یک برنامه است. Apigee از TLS یک طرفه و دو طرفه پشتیبانی می کند.

Northbound TLS (کلینت متصل به API که به عنوان سرور عمل می کند) از طریق استفاده از پیکربندی میزبان مجازی پشتیبانی می شود. یک میزبان مجازی را می توان برای TLS یک طرفه یا دو طرفه پیکربندی کرد.

Southbound TLS (apigee به عنوان یک کلاینت در حال اتصال به سرویس باطن) از طریق استفاده از پیکربندی سرور هدف پشتیبانی می شود. یک سرور هدف را می توان برای TLS یک طرفه یا دو طرفه پیکربندی کرد.

Apigee از بسیاری از گزینه های پیکربندی TLS پشتیبانی می کند.

اجرای دو طرفه TLS تضمین می کند که مشتری از گواهی استفاده می کند که قبلاً در Apigee نصب شده است. OWASP همچنین بهترین شیوه های TLS را ارائه می دهد.

در ترکیبی Apigee، TLS از طریق یک نام مستعار میزبان در دسترس است، که مفهومی مشابه با میزبان مجازی است.

در زیر دستورالعمل هایی برای ایمن سازی داده های حساس آمده است:

  • از پلتفرمی استفاده کنید که از TLS یک طرفه و دو طرفه پشتیبانی می کند که در سطح پروتکل محافظت می کند.
  • از خط‌مشی‌هایی مانند خط‌مشی AssignMessage و خط‌مشی جاوا اسکریپت برای حذف داده‌های حساس قبل از بازگرداندن به مشتری استفاده کنید.
  • از تکنیک‌های استاندارد OAuth استفاده کنید و برای بهبود سطح احراز هویت برای هر درخواست، HMAC، هش، حالت، nonce، PKCE یا تکنیک‌های دیگر را اضافه کنید.
  • از تنظیمات پوشش داده برای پوشاندن داده های حساس در ابزار Edge Trace استفاده کنید.
  • مراقب ذخیره داده های حساس در حافظه پنهان باشید (یا داده های حساس ذخیره شده در حافظه پنهان را رمزگذاری کنید). در Edge، می‌توانید داده‌های حساس را در حالت استراحت در نقشه‌های مقادیر کلیدی رمزگذاری کنید.

A4:2017 - موجودیت های خارجی XML

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

خط مشی ExtractVariables Apigee به شما امکان می دهد محتوا را از یک درخواست یا پاسخ استخراج کنید و آن محتوا را به یک متغیر اختصاص دهید. می‌توانید هر بخشی از پیام را استخراج کنید، از جمله سرصفحه‌ها، مسیرهای URI، بارهای JSON/XML، پارامترهای فرم و پارامترهای پرس و جو. این خط‌مشی با اعمال یک الگوی متنی برای محتوای پیام و پس از یافتن مطابقت، تنظیم متغیری با محتوای پیام مشخص شده کار می‌کند.

Apigee یک تجزیه کننده XML داخلی به عنوان بخشی از پلتفرم دارد که از XPath برای استخراج داده ها استفاده می کند. همچنین دارای یک خط مشی XMLThreatProtection برای محافظت در برابر بارهای مخرب XML است.

A5:2017 - کنترل دسترسی شکسته

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

Apigee از یک رویکرد لایه‌ای برای پیاده‌سازی کنترل‌های دسترسی پشتیبانی می‌کند تا بازیگران بد از ایجاد تغییرات غیرمجاز یا دسترسی به سیستم جلوگیری کنند.

کنترل های دسترسی برای رابط کاربری Edge

کنترل های دسترسی برای پورتال توسعه دهنده Apigee

کنترل های دسترسی برای دسترسی Apigee زمان اجرا

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

A6:2017-پیکربندی اشتباه امنیتی

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

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

انتشار محصولات Apigee محافظت در برابر کتابخانه‌های دارای آسیب‌پذیری را تضمین می‌کند. در صورت یافتن آسیب‌پذیری‌های جدید، Apigee ممکن است وصله‌ها یا به‌روزرسانی‌های اضافی را منتشر کند. ابر عمومی لبه به طور خودکار وصله می شود. Edge for Private Cloud (در محل) مشتریان باید خودشان وصله های محصول را اعمال کنند.

A7:2017-Scros-Site Scripting (XSS)

برنامه نویسی متقابل سایت (XSS) به مهاجمان اجازه می دهد تا اسکریپت ها را در مرورگرهای وب کاربر اجرا کنند تا جلسات کاربر را کنترل کنند، وب سایت ها را دستکاری کنند یا به روش های دیگر به طور مخرب روی کاربران تأثیر بگذارند. مسائل XSS لزوماً به API ها مربوط نمی شوند، اما Apigee سیاست های محافظت از تهدید را ارائه می دهد که می تواند برای محافظت در برابر XSS در API مورد استفاده قرار گیرد. با استفاده از عبارات منظم، چه با خط مشی RegularExpressionProtection یا خط مشی جاوا اسکریپت ، مقدار بار و پارامتر را برای جاوا اسکریپت و سایر حملات نوع تزریق بررسی کنید.

CORS، یکی از راه حل های رایج برای سیاست یکسانی که توسط همه مرورگرها اجرا می شود، می تواند با استفاده از خط مشی AssignMessage پیاده سازی شود .

A8:2017 - Deserialization ناامن

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

Apigee deserialization را توصیه نمی کند. با این حال، خط‌مشی JSONThreatProtection و خط‌مشی RegularExpressionProtection می‌تواند به محافظت در برابر بارهای مخرب JSON کمک کند. خط مشی جاوا اسکریپت همچنین می تواند برای اسکن محموله ها برای محتوای مخرب استفاده شود. کش و سایر سیاست ها می توانند برای محافظت در برابر حملات تکراری استفاده شوند. در سطح زیرساخت، پلت فرم Apigee همچنین دارای حفاظ هایی برای محافظت از فرآیندهای در حال اجرا است.

A9:2017 - استفاده از مؤلفه هایی با آسیب پذیری های شناخته شده

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

عرضه‌های منظم محصولات Apigee، محافظت در برابر آسیب‌پذیری‌های مؤلفه را تضمین می‌کند، به‌ویژه زمانی که آسیب‌پذیری‌های خاصی کشف می‌شوند. ابر عمومی Apigee به طور خودکار وصله می شود و Apigee به مشتریان Edge برای Private Cloud اطلاع می دهد که وصله های داخلی برای نصب در دسترس هستند.

A10:2017 - ثبت و نظارت کافی

هنگامی که ثبت، نظارت و مدیریت حوادث را به اندازه کافی در سیستم خود انجام نمی دهید، مهاجمان می توانند حملات عمیق تر و طولانی تری را بر روی داده ها و نرم افزار انجام دهند.

Apigee چندین راه برای انجام گزارش، نظارت، مدیریت خطا و ثبت حسابرسی دارد.

ورود به سیستم

  • پیام های گزارش را می توان با استفاده از خط مشی MessageLogging به Splunk یا دیگر نقطه پایانی syslog ارسال کرد.
  • داده های تجزیه و تحلیل API را می توان از طریق API تجزیه و تحلیل کشیده و به سیستم های دیگر وارد یا صادر کرد .
  • در Edge for Private Cloud، می‌توانید از سیاست MessageLogging برای نوشتن در فایل‌های گزارش محلی استفاده کنید. فایل های گزارش از هر یک از اجزای در حال اجرا نیز در دسترس هستند.
  • از خط مشی جاوا اسکریپت می توان برای ارسال پیام های گزارش به یک نقطه پایانی گزارش REST به صورت همزمان یا ناهمزمان استفاده کرد.

نظارت

  • از API Monitoring UI یا API برای نظارت منظم بر APIها و backendها و راه‌اندازی آلت‌ها استفاده کنید.
  • از نظارت بر سلامت برای نظارت منظم بر پشتیبان سرورهای هدف استفاده کنید.
  • Apigee توصیه هایی برای نظارت بر Edge برای Private Cloud ارائه می دهد.
  • Apigee همچنین بهترین شیوه هایی را ارائه می دهد که تیم شما می تواند برای نظارت بر برنامه API شما از آنها استفاده کند.

رسیدگی به خطا

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

گزارش های حسابرسی

پلتفرم Apigee یک گزارش حسابرسی نگه می دارد که تغییرات پروکسی های API، محصولات و تاریخچه سازمان را ردیابی می کند. این گزارش از طریق UI یا از طریق Audits API در دسترس است.

راه حل های Apigee برای آسیب پذیری های OWASP 2013

هنگامی که OWASP لیست خود را برای سال 2017 به روز کرد، برخی از آسیب پذیری ها از لیست سال 2013 حذف شدند. آنها همچنان تهدیدهای معتبری هستند. بخش‌های زیر نحوه مدیریت این تهدیدات را با Apigee شرح می‌دهند.

A8:2013 - جعل درخواست بین سایتی (CSRF)

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

رهنمودها:

  • این بیشتر یک مشکل مرورگر است، نه مشکل محصول API. می توانید این آسیب پذیری را با OpenID Connect، OAuth و تکنیک های دیگر برطرف کنید.
  • استفاده از تکنیک های HMAC، State، Hash، nonce یا PKCE را برای جلوگیری از جعل و حملات مجدد در نظر بگیرید.

A10:2013 - تغییر مسیرها و فورواردهای بدون اعتبار

اگر یک برنامه وب، تغییر مسیرها را انجام می‌دهد، اما تأیید نمی‌کند که تغییر مسیرها، کاربران را به وب‌سایت‌های مورد اعتماد و مورد نظر می‌فرستند، مهاجمان می‌توانند کاربران را به مقصدهای مخرب برای انجام فیشینگ، اجرای بدافزار و سایر حملات بفرستند.

رهنمودها:

  • از OAuth استفاده کنید و در هر درخواست اعتبارسنجی را اعمال کنید.
  • با بررسی کدهای پاسخ در منطق پروکسی API و مدیریت صحیح تغییر مسیرها، از تغییر مسیرهای غیرمنتظره 302 جلوگیری کنید.
،

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

این سند رویکردهای مختلفی را توصیف می‌کند که می‌توانید در Apigee برای رفع آسیب‌پذیری‌های امنیتی شناسایی‌شده توسط OWASP استفاده کنید. برای رویکردهای اضافی مستند شده برای Apigee، به 10 گزینه برتر کاهش 2021 OWASP در Google Cloud مراجعه کنید.

نمای کلی

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

OWASP یک جامعه باز است که به سازمان ها کمک می کند تا برنامه ها و API های قابل اعتماد را توسعه دهند، خریداری کنند و نگهداری کنند. از طریق پروژه امنیت API OWASP ، OWASP بحرانی ترین خطرات امنیتی را برای برنامه های کاربردی وب و API های REST منتشر می کند و توصیه هایی برای رسیدگی به این خطرات ارائه می دهد.

با Apigee، لایه پروکسی API می‌تواند درخواست‌های API نادرست از مشتری را قبل از پردازش درخواست‌ها در سیستم‌های باطن، شناسایی، مسدود کرده و گزارش کند، بنابراین خطرات را کاهش داده و از خدمات شما محافظت می‌کند. درخواست‌های نادرست می‌توانند شامل هر مؤلفه‌ای باشند که پروتکل سطح برنامه HTTP را می‌سازد:

  • URL
  • سرصفحه ها
  • مسیر
  • بار

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

پلتفرم مدیریت هوشمند API Apigee به شما این امکان را می‌دهد که آسیب‌پذیری‌های امنیتی OWASP API را به‌طور یکپارچه برطرف کنید، زیرا رویکردی متمرکز بر مصرف برای طراحی APIهای خود و اتصال آنها به سیستم‌های باطن خود دارید. در زیر فهرستی از سیاست ها/پیکربندی هایی که Apigee برای تهدیدات REST OWASP برتر توصیه می کند، آمده است.

راه حل های Apigee برای 10 OWASP برتر 2017

نگرانی های امنیتی زیادی در مورد ایجاد و ایمن سازی برنامه های کاربردی وب وجود دارد. OWASP لیست 10 تهدید امنیتی برتر OWASP 2017 را برای برنامه های تحت وب منتشر کرد. در حالی که بخش های زیادی در یک برنامه وب وجود دارد، اکثر برنامه های وب مدرن به شدت به API های REST متکی هستند. Apigee قرار نیست تمام نیازهای امنیتی یک برنامه وب را برطرف کند، اما می تواند نقشی اساسی در ایمن سازی API های REST داشته باشد. در زیر مهمترین تهدیدات امنیتی OWASP با توضیحاتی در مورد نحوه استفاده از Apigee برای کمک به مقابله با این تهدیدها آورده شده است.

A1:2017 - تزریق

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

چندین روش برای اعتبارسنجی ورودی با پلتفرم Apigee وجود دارد:

اعتبارسنجی انواع محتوا:

A2:2017 - احراز هویت شکسته و مدیریت جلسه

مهاجمان می‌توانند با استفاده از نقص‌های پیاده‌سازی در برنامه‌ها، به رمزهای عبور، نشانه‌های جلسه و کلیدها برای جعل هویت سایر کاربران دسترسی داشته باشند. این بیشتر یک مشکل پیاده سازی است و مشکل محصول نیست. Apigee خط‌مشی‌های VerifyApiKey، OAuth و JSON Web Token (JWT) را ارائه می‌کند که به محافظت در برابر این آسیب‌پذیری کمک می‌کند.

اعتبار سنجی کلید API

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

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

اصطلاح "کلیدهای API" گاهی اوقات می تواند به معنای متفاوت باشد. در Apigee، زمانی که رابطه برنامه و محصول شکل می‌گیرد، Apigee شناسه مشتری و راز مشتری تولید می‌کند. برخی به ID و Secret به عنوان کلید API اشاره می کنند. برخی فقط به شناسه مشتری به عنوان کلید API اشاره می کنند. در رابط کاربری Edge، "کلید مصرف کننده" و "محرمانه مصرف کننده" را خواهید دید.

در خط‌مشی VerifyAPIKey ، فقط شناسه مشتری یا «کلید مصرف‌کننده» تأیید می‌شود. زمانی که برنامه‌نویسان برنامه خود را در Apigee ثبت می‌کنند و برنامه را با یک محصول API مرتبط می‌کنند، یک کلید مصرف‌کننده دریافت می‌کنند. برنامه‌نویسان کلید مصرف‌کننده را در تماس‌هایی که برنامه با پراکسی‌های API انجام می‌دهد که در محصول API همراه هستند، شامل می‌شوند.

Apigee همچنین از توانایی وارد کردن کلیدهای API موجود از منابع خارجی پشتیبانی می کند.

برای انواع کمک هزینه OAuth، هر دو شناسه مشتری و مخفی استفاده می شود.

OAuth 2.0

چارچوب مجوز OAuth 2.0 به یک برنامه شخص ثالث امکان دسترسی محدود به سرویس HTTP را می دهد، یا از طرف مالک منبع با هماهنگ کردن تعامل تأیید بین مالک منبع و سرویس HTTP، یا با اجازه دادن به برنامه شخص ثالث از طرف خود دسترسی پیدا کند.

خط‌مشی‌های OAuth 2.0 Apigee به شما امکان می‌دهد چهار نوع کمک مالی OAuth 2.0 را پیاده‌سازی و سفارشی کنید. اجرای نشانه دسترسی OAuth را می توان با استفاده از خط مشی OAuthv2 انجام داد. مصرف‌کننده باید ثبت‌نام شده باشد و برنامه‌ای تأیید شده باشد که به او اجازه دسترسی به API را داده است. در ازای آن، آنها شناسه مشتری API و راز مشتری دریافت خواهند کرد. مصرف‌کننده برای احراز هویت باید یکی از کمک‌های OAuth را طی کند، که به او یک توکن دسترسی غیرشفاف می‌دهد. این توکن می تواند برای کنترل دسترسی به API استفاده شود.

JWT

JSON Web Tokens یا JWT معمولاً برای به اشتراک گذاشتن ادعاها یا ادعاها بین برنامه های کاربردی متصل استفاده می شود. Apigee پشتیبانی JWT را با استفاده از سه خط مشی ارائه می کند.

  • GenerateJWT Tokens (پشتیبانی از امضای HS256 و RS256)
  • اعتبارسنجی توکن های JWT
  • رمزگشایی توکن های JWT بدون اعتبار سنجی

A3:2017 - قرار گرفتن در معرض داده های حساس

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

TLS (Transport Layer Security، که سلف آن SSL است) فناوری امنیتی استاندارد برای ایجاد یک پیوند رمزگذاری شده بین یک وب سرور و یک سرویس گیرنده وب، مانند یک مرورگر یا یک برنامه است. Apigee از TLS یک طرفه و دو طرفه پشتیبانی می کند.

Northbound TLS (کلینت متصل به API که به عنوان سرور عمل می کند) از طریق استفاده از پیکربندی میزبان مجازی پشتیبانی می شود. یک میزبان مجازی را می توان برای TLS یک طرفه یا دو طرفه پیکربندی کرد.

Southbound TLS (apigee به عنوان یک کلاینت در حال اتصال به سرویس باطن) از طریق استفاده از پیکربندی سرور هدف پشتیبانی می شود. یک سرور هدف را می توان برای TLS یک طرفه یا دو طرفه پیکربندی کرد.

Apigee از بسیاری از گزینه های پیکربندی TLS پشتیبانی می کند.

اجرای دو طرفه TLS تضمین می کند که مشتری از گواهی استفاده می کند که قبلاً در Apigee نصب شده است. OWASP همچنین بهترین شیوه های TLS را ارائه می دهد.

در ترکیبی Apigee، TLS از طریق یک نام مستعار میزبان در دسترس است، که مفهومی مشابه با میزبان مجازی است.

در زیر دستورالعمل هایی برای ایمن سازی داده های حساس آمده است:

  • از پلتفرمی استفاده کنید که از TLS یک طرفه و دو طرفه پشتیبانی می کند که در سطح پروتکل محافظت می کند.
  • از خط‌مشی‌هایی مانند خط‌مشی AssignMessage و خط‌مشی جاوا اسکریپت برای حذف داده‌های حساس قبل از بازگرداندن به مشتری استفاده کنید.
  • از تکنیک‌های استاندارد OAuth استفاده کنید و برای بهبود سطح احراز هویت برای هر درخواست، HMAC، هش، حالت، nonce، PKCE یا تکنیک‌های دیگر را اضافه کنید.
  • از تنظیمات پوشش داده برای پوشاندن داده های حساس در ابزار Edge Trace استفاده کنید.
  • مراقب ذخیره داده های حساس در حافظه پنهان باشید (یا داده های حساس ذخیره شده در حافظه پنهان را رمزگذاری کنید). در Edge، می‌توانید داده‌های حساس را در حالت استراحت در نقشه‌های مقادیر کلیدی رمزگذاری کنید.

A4:2017 - موجودیت های خارجی XML

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

خط مشی ExtractVariables Apigee به شما امکان می دهد محتوا را از یک درخواست یا پاسخ استخراج کنید و آن محتوا را به یک متغیر اختصاص دهید. می‌توانید هر بخشی از پیام را استخراج کنید، از جمله سرصفحه‌ها، مسیرهای URI، بارهای JSON/XML، پارامترهای فرم و پارامترهای پرس و جو. این خط‌مشی با اعمال یک الگوی متنی برای محتوای پیام و پس از یافتن مطابقت، تنظیم متغیری با محتوای پیام مشخص شده کار می‌کند.

Apigee یک تجزیه کننده XML داخلی به عنوان بخشی از پلتفرم دارد که از XPath برای استخراج داده ها استفاده می کند. همچنین دارای یک خط مشی XMLThreatProtection برای محافظت در برابر بارهای مخرب XML است.

A5:2017 - کنترل دسترسی شکسته

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

Apigee از یک رویکرد لایه‌ای برای پیاده‌سازی کنترل‌های دسترسی پشتیبانی می‌کند تا بازیگران بد از ایجاد تغییرات غیرمجاز یا دسترسی به سیستم جلوگیری کنند.

کنترل های دسترسی برای رابط کاربری Edge

کنترل های دسترسی برای پورتال توسعه دهنده Apigee

کنترل های دسترسی برای دسترسی Apigee زمان اجرا

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

A6:2017-پیکربندی اشتباه امنیتی

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

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

نسخه های Apigee Product از محافظت در برابر کتابخانه ها با آسیب پذیری اطمینان می دهد. در صورت یافتن آسیب پذیری های جدید ، Apigee ممکن است تکه ها یا به روزرسانی های اضافی را منتشر کند. Edge Public Cloud به طور خودکار وصله می شود. حاشیه برای ابر خصوصی (در محل) مشتریان باید خودشان تکه های محصول را اعمال کنند.

A7: 2017-Cross-Site Scripting (XSS)

برنامه نویسی متقابل سایت (XSS) به مهاجمان اجازه می دهد تا اسکریپت ها را در مرورگرهای وب کاربر اجرا کنند تا جلسات کاربر را کنترل کنند ، وب سایت ها را دستکاری کنند یا به روش های دیگر بر کاربران تأثیر بگذارند. مسائل XSS لزوماً مربوط به API ها نیست ، اما Apigee سیاست های محافظت از تهدید را ارائه می دهد که می تواند برای محافظت در برابر XSS در API استفاده شود. با استفاده از عبارات منظم ، یا با خط مشی تنظیم تنظیم کننده یا خط مشی JavaScript ، مقادیر بار و پارامتر را برای JavaScript و سایر حملات از نوع تزریق بررسی کنید.

CORS ، یکی از راه حل های متداول برای سیاست همان منبعی که توسط همه مرورگرها اجرا می شود ، می تواند با استفاده از خط مشی AssignMessage اجرا شود .

A8: 2017 - ناامن شدن ناامن

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

Apigee deserialization را توصیه نمی کند. با این حال ، سیاست JSONTheReatProtection و خط مشی RegulareXpressionProtection می تواند به محافظت در برابر بارهای مخرب JSON کمک کند. از خط مشی JavaScript همچنین می توان برای اسکن بارهای برای محتوای مخرب استفاده کرد. از حافظه نهان و سایر سیاستها می توان برای محافظت در برابر حملات پخش مجدد استفاده کرد. در سطح زیرساخت ها ، پلت فرم Apigee همچنین دارای نگهبانان ساخته شده برای محافظت از فرآیندهای در حال اجرا است.

A9: 2017 - استفاده از مؤلفه هایی با آسیب پذیری های شناخته شده

از آنجا که چارچوب ها ، کتابخانه ها و ماژول ها با اجرای کامل و دسترسی CRUD اجرا می شوند ، مهاجمان می توانند از آسیب پذیری های مؤلفه برای حمله به سیستم استفاده کنند.

نسخه های منظم محصول Apigee از محافظت در برابر آسیب پذیری های مؤلفه اطمینان می دهد ، به ویژه هنگامی که آسیب پذیری های خاص کشف می شود. ابر عمومی Apigee به طور خودکار وصله می شود ، و Apigee در صورت وجود تکه های داخلی برای نصب ، Edge را برای مشتریان ابر خصوصی مطلع می کند.

A10: 2017 - ورود و نظارت کافی

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

Apigee روش های مختلفی برای انجام ورود به سیستم ، نظارت ، رسیدگی به خطا و ورود به سیستم حسابرسی دارد.

ورود به سیستم

  • پیام های ورود به سیستم می توانند با استفاده از خط مشی پیام MessageLogging به Splunk یا سایر نقطه پایانی Syslog ارسال شوند.
  • داده های تجزیه و تحلیل API را می توان از طریق API Analytics کشیده و به سیستم های دیگر وارد یا صادر کرد .
  • در Edge for Private Cloud ، می توانید از خط مشی پیام MesseLogging برای نوشتن در پرونده های ورود به سیستم محلی استفاده کنید. پرونده های ورود به سیستم از هر یک از مؤلفه های در حال اجرا نیز در دسترس هستند.
  • از خط مشی JavaScript می توان برای ارسال پیام های ورود به سیستم به نقطه انتهایی استراحت همزمان یا ناهمزمان استفاده کرد.

نظارت

  • از UI یا API مانیتورینگ API استفاده کنید تا به طور منظم API ها و بالهای با عقب را کنترل کنید و Alets را تحریک کنید.
  • از نظارت بر سلامت استفاده کنید تا به طور منظم با حمایت های سرور هدف را کنترل کنید.
  • Apigee توصیه هایی را برای نظارت بر لبه های خصوصی ارائه می دهد.
  • Apigee همچنین بهترین شیوه هایی را ارائه می دهد که تیم شما می تواند برای نظارت بر برنامه API شما از آن استفاده کند.

رسیدگی به خطا

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

سیاهههای مربوط به حسابرسی

پلت فرم Apigee یک گزارش حسابرسی را نگه می دارد که تغییرات در پراکسی های API ، محصولات و تاریخ سازمان را ردیابی می کند. این ورود از طریق UI یا از طریق API حسابرسی در دسترس است.

راه حل های Apigee برای آسیب پذیری های OWASP 2013

هنگامی که OWASP لیست خود را برای سال 2017 به روز کرد ، برخی از آسیب پذیری ها از لیست 2013 از بین رفت. آنها هنوز تهدیدهای معتبر هستند. در بخش های زیر نحوه رسیدگی به این تهدیدها با Apigee توضیح داده شده است.

A8: 2013 - جعل درخواست متقابل (CSRF)

درخواست های جعلی در سایت به مهاجمان اجازه می دهد تا جزئیات تأیید اعتبار کاربر ، کوکی جلسه و سایر داده ها را به یک برنامه وب آسیب پذیر از طریق HTTP ارسال کنند ، و این برنامه وب را به این باور برساند که درخواست ها درخواست های قانونی از کاربر هستند.

رهنمودها:

  • این بیشتر یک مشکل مرورگر است ، نه یک مسئله محصول API. شما می توانید این آسیب پذیری را با OpenID Connect ، OAUTH و سایر تکنیک ها برطرف کنید.
  • برای جلوگیری از حملات جعل و پخش مجدد ، از تکنیک های HMAC ، State ، Hash ، Nonce یا PKCE استفاده کنید.

A10: 2013 - تغییر مسیر و رو به جلو بی اعتبار

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

رهنمودها:

  • در هر درخواست از OAUTH و اعتبار سنجی استفاده کنید.
  • با بررسی کدهای پاسخ در منطق پروکسی API و استفاده مجدد از هدایت مناسب ، از تغییر مسیر 302 غیر منتظره جلوگیری کنید.