چه API های RESTful را حفظ کنید یا یک نقطه پایانی GraphQL، آسیب پذیری های شناخته شده و تنظیمات اشتباه رایجی وجود دارد که مهاجمان می توانند از آنها سوء استفاده کنند.
به عنوان یک توسعه دهنده، شما محدودیت هایی دارید: زمان، بودجه، دانش محدود.
چرا خود را درگیر امنیت کنیم؟
رویکرد «از ابتدا» لزوماً شیطانی نیست. توسعه دهندگان باتجربه می دانند چگونه API های قوی بسازند.
در شک و یا برای صرفه جویی در زمان، چارچوب ها و راه حل های استاندارد مانند پلت فرم API وجود دارد.
این بسته باورنکردنی است و حتی می‌تواند لایه‌های امنیتی اضافی را با استفاده از مؤلفه امنیتی Symfony فعال کند.
همانطور که در این پست اشاره کردم، مشکل این است که اغلب نادیده گرفته می‌شود، احتمالاً به این دلیل که اولویت اصلی تحویل آن است. شگفت آور ویژگی.
چه به منابع موجود متکی باشید (به عنوان مثال، منبع باز، راه حل های اختصاصی) یا همه چیز را به تنهایی بسازید، نقاط پایانی شما دیر یا زود مورد آزمایش قرار خواهند گرفت.
به دلیل وضعیت فعلی وب، APIها حاوی داده های حساس تری هستند که گاهی منجر به نشت گسترده می شود.
API های معیوب می توانند به معنای واقعی کلمه تجارت را از بین ببرند و حتی آژانس های وب و توسعه دهندگان را در بدترین سناریو در معرض شکایت های قانونی قرار دهند.
اخیراً در مورد مورد مشابهی خوانده‌ام که در آن یک شرکت از «تامین‌کننده» (آژانس وب) خود به خاطر یک API معیوب که منجر به خسارات جدی شده است، شکایت کرد.
تامین کننده پولی دریافت نکرد و مسئول این حملات شناخته شد.
چه چیزی ممکن است اشتباه باشد؟
به اختصار:
- نشت داده ها / خروج
- انواع مختلف تزریق مخرب (مانند XSS، SSTI)
- کنترل دسترسی خراب
- احراز هویت شکسته (به عنوان مثال، اطلاعات کاربری سرقت شده، مانند کلیدهای API)
- مجوز شکسته
- اعتبار سنجی شکسته
- پیمودن مسیرها
- از دست دادن داده ها (به عنوان مثال، حذف گسترده)
- قرار گرفتن در معرض نقاط پایانی خصوصی
- حملات DoS/DDoS
و خیلی بیشتر…
مهاجمان از چه ابزارهایی می توانند استفاده کنند؟
مثلا:
- OSINT ساده اما قدرتمند (به عنوان مثال، Google/Shodan dorks اما نه تنها)
- ابزارهای کشف مانند Nmap افسانه ای
- BurpSuite افسانه ای و پروکسی آن
- انواع تکنیک های فازی و فهرست کلمات (مانند SecLists)
- شاید graphql voyager
- شاید swagger.txt
- برخی از شرایط مسابقه در برابر URL های خاص برای دشمنان با انگیزه
ابزارهای مبهم و فهرست کلمات امکان خودکارسازی بسیاری از حملات را فراهم می کند. در واقع ابزارهای خودکار رایگان زیادی برای هک کردن API ها وجود دارد.
در حالی که اینها ابزارهای هک هستند، هنوز هم فقط می توان از ابزارهای برنامه نویس قانونی استفاده کرد:
- پستچی و مشتریان مشابه
- ابزارهای اشکال زدایی در مرورگر (به عنوان مثال، تب شبکه)
رایج ترین مسیرها
URL های API بسیار قابل پیش بینی هستند، به ویژه API های RESTful.
این تقریباً نکته است. مسیرهای زیر ممکن است شبیه مسیرهایی باشند که در نمونه‌های اصلی و دیگر «سلام جهان» یافت می‌شوند، اما در واقع اغلب در تولید استفاده می‌شوند:
/api/graphql/v1/v2/rest/swagger/api/login
تغییر مسیرهای پیش‌فرض ممکن است برای شما مانند امنیت به نظر برسد، و همینطور است، اما همچنان ممکن است از بسیاری از اسکن‌های خودکار اولیه/عظیم اجتناب کنید.
برای ایمن سازی API های خود چه کاری می توانید انجام دهید؟
- هرگز به قوانین و تنظیمات پیش فرض تکیه نکنید، صرف نظر از ابزاری که برای نمایش نقاط پایانی خود استفاده می شود
- 10 امنیت API برتر توسط OWASP را بررسی کنید
- غیرفعال کردن مستندات swagger در تولید
- قوانین CORS را با دقت تنظیم کنید
- قابلیت مشاهده و جزئیات را برای کاربران خود فراهم کنید (دستگاه های ثبت شده، 2FA، فعالیت اخیر حساب، امکان تمدید/لغو اعتبار و غیره)
- ورود به سیستم همه چيز
- دریچه گاز و محدودیت نرخ (ممنوع کردن ارسال کنندگان هرزنامه)
- نقاط پایانی خود را آزمایش کنید (آزمون های قلم، اسکن آسیب پذیری)
- اگر از پلتفرم API استفاده می‌کنید، برای یادگیری و فعال کردن مکانیسم‌های امنیتی مورد نیاز خود وقت بگذارید (جزء امنیتی Symfony)
بسته شدن
API ها یک نگرانی امنیتی رایج هستند، زیرا داده های حساس تر و بیشتر در معرض دید قرار می گیرند.
در بیشتر موارد، حساب‌های کاربری توسط چندین لایه امنیتی محافظت می‌شوند، مانند ورود به سیستم/رمز عبور، 2FA (احراز هویت دو مرحله‌ای)، MFA (تأیید هویت چند عاملی)، کلیدهای رمزنگاری
با این حال، کلیدهای API ساده همچنان می‌توانند قابلیت‌های پیشرفته و دسترسی ممتاز به داده‌های حساس را اعطا کنند.
یک کلید API فقط یک لایه (1FA) است…
