در دهه ۹۰، «هکر» کمی یک واژه بد بود. هکرهای فیلم‌ها نام‌های تند و تیز مانند Electra (Assassins)، Neo (The Matrix)، Phantom Phreak (Hackers) و Boris Grishenko (Goldeneye) داشتند. سلیقه عالی در پیراهن‌های هاوایی، اما کمتر در ارائه برنامه‌هایی برای شکست دادن جیمز باند.
این شخصیت‌های مانند خدا برای فیلم‌های مربوطه حیاتی هستند، شکستن کد آنها در آخرین لحظه تقریباً همیشه کلید دستیابی به MacGuffin است. سی سال بعد، هودی‌ها جای پیراهن‌های هاوایی را گرفته‌اند و زبان l337 تقریباً رها شده است.
با این حال، برخی چیزها تغییر نکرده‌اند. اگرچه نگاه‌ها به هکرها در برخی جنبه‌ها نرم‌تر شده است — تابلوی پیام YCombinator با نام Hacker News در واقع ادای احترامی به آنهاست — اما آنها هنوز در میان عموم مردم هاله‌ای از رمزآلود بودن دارند. شاید به لطف جرایم سایبری پرسر و صدای اخیر، حتی هاله‌ای از خطر.
هرچقدر هم احمقانه به نظر برسد، این یک حالت ذهنی ارزشمند برای توسعه‌دهندگان است تا گاهی وارد آن شوند. حداقل، این دیدگاه دن باراهونا از APISec University است. در اجلاس ۲۰۲۴ Austin API، باراهونا همراه ما شد تا از تلاش برای هک کردن APIهای خودتان دفاع کند.
در این پست، ما چند نکته کاربردی از آن گفتگو استخراج می‌کنیم و بررسی می‌کنیم که چگونه این نگاه به APIها ممکن است به شما کمک کند با رویکردی کاملاً جدید به امنیت نزدیک شوید. یک نوشیدنی انرژی‌زای Monster و یک جفت عینک آفتابی بدون دسته بردارید و با ما در آبشار کد سبز شیرجه بزنید.
چرا مهاجمان APIها را دوست دارند
باراهونا صحبت خود را با یک مرور سریع از چیزهایی شروع می‌کند که APIها را برای مهاجمان جذاب می‌کند. یعنی اینکه آنها به مهاجمان اجازه می‌دهند نیاز به تعامل با رابط کاربری وب یا اپ‌های موبایل را دور بزنند، که ممکن است لایه‌های بیشتری از محافظت داشته باشند. طبق گفته باراهونا، هکرها معمولاً به دنبال APIهایی می‌گردند که دسترسی بیش از حد دارند، اطلاعات بیش از حد برمی‌گردانند، به توابع غیرمجاز دسترسی دارند یا نقص‌های منطقی را آشکار می‌کنند.
او همچنین اشاره می‌کند که این موضوع بسیار فراتر از یک تمرین آکادمیک است — مشکلات مربوط به APIها مسئول چندین نقض امنیتی واقعی بوده‌اند. برای مثال، Coinbase یک بررسی اعتبارسنجی منطقی را کم داشت، که منجر به یک اکسپلویت شد که به یک مشتری اجازه داد معامله‌ای به ارزش ۴۳٬۰۰۰ دلار انجام دهد که مجاز نبود — کاری که از طریق رابط کاربری فرانت‌اند هرگز قابل انجام نبود.
باراهونا همچنین مثال API نشت‌کننده Peloton را ارائه می‌دهد، که اجازه دسترسی به داده‌های حساب میلیون‌ها دوچرخه‌سوار را می‌داد… حتی اگر پروفایل خود را خصوصی کرده بودند. «نکته حرفه‌ای اینجاست»، او با طعنه می‌گوید، «که احراز هویت با مجوزدهی یکی نیست.»
Coinbase پس از خبردار شدن توسط همان مشتری، این اکسپلویت را رفع کرد و ۲۵۰٬۰۰۰ دلار به او پاداش داد. با اینکه این پست بر امن‌سازی API توسط خودتان متمرکز است، اما ذکر برنامه‌های باگ‌بانتی نیز ارزشمند است، زیرا راهی برای تشویق افراد به یافتن مشکلات ارائه می‌کنند.
نکات کلیدی از تحلیل نقض‌ها
در گزارش بازار امنیت API سال ۲۰۲۴، دانشگاه APIsec رایج‌ترین علل نقض داده‌های اخیر را شکافته و آنها را با ۱۰ ریسک برتر امنیت API OWASP مرتبط کرده است:
-
محدودسازی نرخ (۷۰٪ نقض‌ها) – OWASP #4
-
نقص در مجوزدهی (۶۰٪) – OWASP #1
-
نقص در احراز هویت (۴۵٪) – OWASP #2
-
افشای بیش از حد داده (۳۰٪) – OWASP #3
با وجود اینکه نقش مهمی در بیش از ۷۰٪ نقض‌ها دارد، باراهونا می‌گوید: «محدودسازی نرخ قرار نیست همه چیز را محافظت کند. نداشتن آن اوضاع را بدتر می‌کند — به‌جای از دست دادن ۱۰۰ رکورد، ممکن است ۱۰۰ میلیون را از دست بدهید — اما این ریشه اصلی آسیب‌پذیری‌های API نیست.»
ما نیز اخیراً اشاره کردیم که محدودسازی نرخ گلوله جادویی برای جلوگیری از نقض داده نیست. با وجود اینکه پس از آن قرار می‌گیرد، موارد ۱، ۲ و ۳ در فهرست OWASP نقش ترکیبی در ۹۰٪ نقض‌های قابل‌توجه دارند.
باراهونا پیشنهاد می‌کند که مشکل اصلی پشت بسیاری از نقض‌ها این است که چیز جذابی برای برداشت وجود دارد. نمونه آن نشت اخیر Trello است، که در آن ۱۵ میلیون رکورد کاربر از طریق یک API افشا شده به دست آمد.
«اگر فقط لازم دارید نام کوچک ارسال کنید»، باراهونا باطن‌پرس می‌پرسد، «چرا باید نام خانوادگی، آدرس منزل، شماره حساب، آدرس ایمیل یا هر چیز دیگر را در آن رکورد ارسال کنید؟»
مشکل ذهنیت معمول یک توسعه‌دهنده
به عنوان توسعه‌دهنده، ممکن است بیشتر نگران این باشیم که مطمئن شویم چیزها درست (و خوب) کار می‌کنند تا اینکه مطمئن شویم آنها به‌طور امن یا مختصر عمل می‌کنند. اگر این جمله کلی‌گویی به نظر برسد، اما با اعداد واقعی پشتیبانی می‌شود:
گزارش وضعیت API پست‌من ۲۰۲۳ تأیید می‌کند که در حالی‌که ۶۷٪ و ۶۴٪ از پاسخ‌دهندگان تست‌های عملکردی و یکپارچه‌سازی انجام می‌دهند، این عدد برای امنیت به کمتر از ۵۰٪ کاهش می‌یابد. و این شاید به این دلیل باشد که ما مانند توسعه‌دهنده فکر می‌کنیم، نه مهاجم.
با اشاره به یک نشت Duolingo، باراهونا این جمله را درباره یک API هک‌شده که عمومی‌سازی نشده بود اما امن نیز نبود بیان می‌کند: «فقط می‌توانم تصور کنم که توسعه‌دهنده این API احتمالاً فکر کرده: چه کسی قرار است این چیز را پیدا کند؟ هدف آنها از استفاده از آن چه خواهد بود؟»
«اما APIهای مخفی شما»، باراهونا نتیجه می‌گیرد، «پیدا خواهند شد.» وقتی مدتی را در برخی گوشه‌های اینترنت می‌گذرانید، می‌فهمید که چیزی پوچ، بی‌هدف یا غریب هیچ تضمینی نمی‌دهد که اتفاق نمی‌افتد. فقط به دنیای بازی نگاه کنید. از عبور از تمام نقشه Red Dead Redemption 2 بدون برداشتن یک قدم گرفته تا فرقه ۳۶۰ no scope، همیشه کسی بیرون هست که سعی می‌کند تقریباً هر کار بی‌هدفی را انجام دهد.
در بسیاری از موارد، ذهنیت هکری از کنجکاوی هدایت می‌شود: خواسته‌ای برای اثبات اینکه کاری فقط برای اثبات قابلیت انجام آن قابل انجام است. هرگز فرض نکنید API شما امن است فقط چون آن را عمومی نمی‌کنید یا چون اطلاعات چندانی ارسال نمی‌کند. البته، برخی موارد وجود دارد که رویکرد مهاجم بسیار شرورانه‌تر از کنجکاوی بی‌ضرر است.
درک نحوه تفکر هکرها
در سال ۲۰۱۷، اکونومیست نوشت که ارزشمندترین منبع جهان دیگر نفت نیست، بلکه داده است. بات‌نت‌ها، هک، باج‌افزار و غیره حضور قابل‌توجهی در دارک‌وب دارند، اغلب با هدف مشترک به‌دست‌آوردن داده کاربران برای فروش.
با افزایش حجم این داده‌ها، ارزش قابل‌فروشش نیز افزایش می‌یابد. و همان‌طور که از نقض‌های بالا دیده‌ایم، APIها راهی جذاب برای دستیابی به مقادیر عظیمی از داده هستند.
مهاجمان باهوش هستند و راه‌هایی برای سوءاستفاده از APIها پیدا خواهند کرد، باراهونا می‌گوید. «آنها از پروکسی‌ها استفاده می‌کنند، آدرس‌های IP را چرخشی می‌کنند، و درخواست‌های خود را محدود می‌کنند. آنها از همه این تکنیک‌ها استفاده می‌کنند، حتی اگر اجرای آن ماه‌ها طول بکشد.» به عبارت دیگر؟ هرگز یک هکر با چشم‌داشت به هدف را دست‌کم نگیرید.
چرخه عمر امنیت API
باراهونا نقاط مختلفی را پیشنهاد می‌کند که در آن می‌توانید تدابیر امنیتی API را در چرخه عمر API پیاده‌سازی کنید، با هدف کاهش چنین حملاتی.
وقتی صحبت از مقابله با حملات می‌شود، او روش‌شناسی زیر را پیشنهاد می‌کند:
-
خودکارسازی: حذف هرچه بیشتر تست دستی
-
جامع بودن: تست هر اندپوینت بر اساس OWASP و بیشتر
-
مستمر بودن: ادغام تست در SDLC، یعنی انتقال به چپ
«تست دستی خوب است»، باراهونا می‌گوید. «اما قرار نیست بتواند همراهی کند… اگر APIای با ۱۰۰ اندپوینت دارید و می‌خواهید مجوزدهی، احراز هویت، افشای داده و غیره را تست کنید، شما هزاران ترکیب دارید. و اگر نسخه شبانه می‌گیرید، باید شبانه تست کنید. ما باید از قابلیت تولید تست هوشمند استفاده کنیم.»
