Xavfsiz API yaratish uchun eng yaxshi amaliyotlar

Rakesh Talanki va Vidxer Gadikota

API (amaliy dasturlash interfeysi) dizaynerlari va ishlab chiquvchilari odatda interfeysni amalga oshirishda dizayn tamoyillariga rioya qilish muhimligini tushunishadi. Hech kim yomon APIni loyihalash yoki amalga oshirishni xohlamaydi!

Shunday bo'lsa-da, ba'zan o'sha tajovuzkor sprint vaqt jadvaliga etib borish, marraga etib borish va API-ni o'rnatish uchun yorliqlarni qidirishga moyil. Ushbu yorliqlar jiddiy xavf tug'dirishi mumkin - himoyalanmagan API.

Ishlatishdan oldin ishlab chiquvchilar API xakerining shlyapasini kiyishni unutmasliklari kerak. Agar ishlab chiqaruvchi API zaifliklarini aniqlashga ahamiyat bermasa, API zararli faoliyat uchun ochiq eshikka aylanishi mumkin.

API zaifliklarini aniqlash va hal qilish

API o'z foydalanuvchilarining talablarini qanchalik yaxshi tushunganligi va bajarganligiga qarab, o'z provayderi uchun yoki unga qarshi ishlay oladi. Agar kompaniya nihoyatda xavfsiz API qursa, undan foydalanish juda qiyin bo'lishi mumkin. API maqsadi va iste'mol qilish qulayligi o'rtasida yaxshi muvozanatni saqlash kerak. Ushbu maqolada, biz Google Apigee jamoasi tarkibidagi ishimiz davomida duch kelgan ba'zi API zaifliklarini, shuningdek, ushbu zaifliklar qanday qilib oldini olish mumkinligini ko'rib chiqamiz.

In'ektsiyalar

API - bu korxonalar dunyo bilan raqamli ulanish uchun eshikdir. Afsuski, zararli foydalanuvchilar ham bor, ular API uchun mavjud bo'lgan o'zboshimchalik bilan ma'lumotlarni tashlab yuborish, yo'q qilish, yangilash va hatto yaratish uchun rejasiz buyruqlar yoki iboralarni kiritib, korxonalarning himoya tizimlariga kirishni maqsad qiladilar.

Masalan, 2014 yil oktyabr oyida Drupal SQL qarshi zaifligini e'lon qildi, bu hujumchilarga ma'lumotlar bazalari, kodlar va fayllar kataloglariga kirish huquqini berdi. Hujum shu qadar kuchli ediki, tajovuzkorlar barcha ma'lumotlarni mijoz saytlaridan nusxalashgan bo'lishi mumkin. Inyeksiya tahdidlarining ko'p turlari mavjud, ammo eng keng tarqalganlari SQL Enjeksiyon, RegEx Enjeksiyon va XML Injection. Bir necha bor biz API-lar tahdidlarsiz himoyalanishini ko'rdik - bu kam emas.

Haqiqiylikni tekshirishsiz API

Haqiqiylikni tekshirish orqali zararli tahdidlardan himoyasiz qurilgan API, tashkilotning ma'lumotlar bazalariga tahdid soladigan API dizaynidagi xatolikni anglatadi. To'g'ri autentifikatsiyaga e'tibor bermaslik - hatto transport sathining shifrlanishi (TLS) ishlatilsa ham muammolarga olib kelishi mumkin. API so'rovida yaroqli mobil raqami bilan, masalan, istalgan kishi shaxsiy elektron pochta manzillari va qurilmalarni aniqlash ma'lumotlarini olishi mumkin. OAuth / OpenID Connect kabi sanoat standartidagi kuchli autentifikatsiya va avtorizatsiya mexanizmlari TLS bilan birgalikda juda muhimdir.

Ochiq ma'lumotlar

Odatda, operatsion guruhlar va boshqa ichki guruhlar nosozliklarni tuzatish vositalarini tekshirish vositalaridan foydalana olishadi, bu esa API-ning yuklanishiga oid ma'lumotlarning aniq ko'rinishini ta'minlaydi. Ideal holda, PCI karta egalari ma'lumotlari (CHD) va Shaxsiy sog'liqni saqlash ma'lumotlari (PHI) ma'lumotlar saqlanadigan joydan ma'lumotlarni iste'mol qilinadigan joygacha shifrlangan, ammo bu har doim ham shunday emas.

API xavfsizligi bilan bog'liq xavotirlar oshib borayotganida, maxfiy va maxfiy ma'lumotlarni shifrlash birinchi darajali vazifa bo'lishi kerak. Masalan, 2016 yil iyun oyida http-proksi zaifligi aniqlandi, bu tajovuzkorlarga tanlangan serverga chiquvchi so'rovni proksi qilish, so'rovdan maxfiy ma'lumotlarni olish va ichki ma'lumotlar haqida ma'lumot olish uchun bir nechta usullarni taqdim etdi. TLS-dan tashqari, API-trafikni maxfiy ma'lumotlarni shifrlash, iz / jurnal uchun ma'lumot maskalashini amalga oshirish va karta ma'lumotlari uchun tokenizatsiya yordamida himoya qilish juda muhimdir.

Qayta hujumlar

Korxonalar me'morlari uchun katta qiziqish "operatsiyalarni takrorlash" deb nomlanadi. Keng omma uchun ochiq bo'lgan API kirish so'rovlariga ishonish yoki topmaslik muammosiga duch keladi. Ko'p holatlarda, ishonchsiz so'rov yuborilgan va rad etilgan bo'lsa ham, API, ehtimol zararli bo'lgan foydalanuvchiga muloyimlik bilan qayta urinib ko'rishga ruxsat berishi mumkin.

Hujumchilar ushbu noto'g'ri ishonchdan foydalanib, qonuniy foydalanuvchi so'rovini (ba'zi holatlarda shafqatsiz kuch usullaridan foydalangan holda) muvaffaqiyatli bo'lguncha ishlatadilar. 2016 yilda xakerlar buzilgan boshqa onlayn xizmatlarning elektron pochta manzillari va parollarini qayta ishlatib, ularni Github hisoblarida sinab ko'rish orqali Github hisoblariga kirishdi.

Qarama-qarshi choralar so'rovlarni siqish uchun stavkalarni cheklash siyosati, API so'rovlari trafigini tahlil qilish uchun Apigee Sense kabi murakkab vositalardan foydalanish va bot so'rovlarini ifodalovchi naqshlarni aniqlashni o'z ichiga oladi. Qayta takrorlash hujumlarini to'xtatish uchun qo'shimcha xavfsizlik choralari quyidagilarni o'z ichiga oladi:

  • Bitimning amal qilish muddatini belgilangan vaqtga cheklash uchun vaqt belgilarini o'z ichiga olgan HMAC
  • ikki faktorli autentifikatsiya
  • OAuth yordamida qisqa muddatli kirish tokenini yoqish

API ishlatishda kutilmagan siljishlar

API ishlatilishini hisoblash har doim qiyin. Milliy ob-havo xizmati API-ni qisqartirgan ilova bunga yaxshi misol bo'la oladi. Ushbu maxsus API hech qanday trafikni oldini olish yoki tebranish mexanizmiga ega emas edi, shuning uchun kutilmagan trafikning keskin oshishi orqa tomonga to'g'ri keldi.

Yaxshi amaliyot shpalka ta'sir qilmasligi uchun tez-tez trafik bilan hibsga olish yoki bir ilovadan foydalanish uchun kvotani joriy qilishdir. Buni murakkab API boshqaruvi platformasi yordamida kvota va boshoqni ushlab turish kabi qoidalar yordamida osongina olib tashlash mumkin.

URI kalitlari

Ba'zi bir foydalanish holatlarida autentifikatsiya va avtorizatsiya uchun API kalitlarini ishlatish etarli. Biroq, kalitni Yagona Resurs identifikatori (URI) ning bir qismi sifatida yuborish kalitning buzilishiga olib kelishi mumkin. IETF RFC 6819-da tushuntirilganidek, URI tafsilotlari brauzer yoki tizim jurnallarida ko'rinishi mumkinligi sababli, boshqa foydalanuvchi brauzer tarixidan URI-larni ko'rish imkoniyatiga ega bo'lishi mumkin, bu esa API kalitlari, parollari va sezgir sanasini API URI-larida osonlikcha ochib beradi.

Tarmoq elementlari kirmagan xabarlarni avtorizatsiya qilish sarlavhasida API kalitlarini yuborish xavfsizroqdir. Qoida tariqasida, HTTP POST usulidan yuklarni sezgir ma'lumotlarga ega bo'lgan holda foydalanish tavsiya etiladi.

Stack iz

Ko'pgina API ishlab chiquvchilari barcha muvaffaqiyat talablari uchun 200, barcha muvaffaqiyatsizliklar uchun 404, ba'zi ichki server xatolari uchun 500 va ba'zi ekstremal holatlarda tanadagi xato xabari 200 bilan batafsil stack izidan foydalanishda qulay bo'ladilar. Stack izi zararli foydalanuvchi uchun paketning nomlari, sinf nomlari, ramka nomlari, versiyalari, server nomlari va SQL so'rovlari ko'rinishidagi asosiy dizayn yoki arxitektura amaliyotlarining ochilishida ma'lumot tarqalishiga olib kelishi mumkin.

Ushbu Cisco misolida tushuntirilganidek, tajovuzkorlar ushbu URL-dan talab qilingan so'rovlarni yuborish orqali foydalanishlari mumkin. Xatolik sharoitida "muvozanatli" xato ob'ektini, HTTP maqom kodini, talab qilinadigan minimal xato xabarlari (lar) va "stack izlari" bo'lmagan holda qaytarish yaxshi amaliyot. Bu xato bilan ishlashni yaxshilaydi va buzg'unchi tomonidan API amalga oshirish tafsilotlarini himoya qiladi. Xato xabarlarini standart xabarlarga aylantirish uchun API shlyuzidan foydalanish mumkin, shunda barcha xato xabarlari bir-biriga o'xshaydi; bu, shuningdek, orqa kod kodi tuzilishini fosh qiladi.

API xavfsizligini saqlang

Ushbu maqolada ko'rib chiqqanimizdek, ko'pgina potentsial tahdidlardan API dizayniga fikr yuritish va korxona bo'ylab qo'llanilishi mumkin bo'lgan boshqaruv siyosatini o'rnatish orqali oldini olish mumkin. Ishlayotgan vaqtda sezgir shifrlangan ma'lumotlarga kirish va niqoblash va serverlarni to'g'ridan-to'g'ri kirishdan himoya qilish orqali zararli xabar tarkibidan API-larni himoya qilish muhimdir. API xavfsizlik xatosi jiddiy oqibatlarga olib kelishi mumkin, ammo to'g'ri o'ylab va boshqarish bilan korxonalar o'zlarini ancha xavfsizroq qilishlari mumkin.

[API xavfsizligi haqida ko'proq bilmoqchimisiz? Bizning so'nggi elektron kitobimiz nusxasini, API mahsulotining ichki qismida: xavfsiz API-larni yaratish va boshqarish.