Rekomendasi untuk mengurangi ancaman 10 Teratas Keamanan API OWASP menggunakan API Management

  • Artikel

BERLAKU UNTUK: Semua tingkatAN API Management

Open Web Application Security Project (OWASP) Foundation bekerja untuk meningkatkan keamanan perangkat lunak melalui proyek perangkat lunak sumber terbuka yang dipimpin komunitas, ratusan bab di seluruh dunia, puluhan ribu anggota, dan dengan menyelenggarakan konferensi lokal dan global.

Proyek Keamanan API OWASP berfokus pada strategi dan solusi untuk memahami dan mengurangi kerentanan dan risiko keamanan API yang unik. Dalam artikel ini, kita akan membahas rekomendasi untuk menggunakan Azure API Management guna mengurangi 10 teratas ancaman API yang diidentifikasi oleh OWASP.

Catatan

Selain mengikuti rekomendasi dalam artikel ini, Anda dapat mengaktifkan Defender untuk API, kemampuan Microsoft Defender untuk Cloud, untuk wawasan keamanan API, rekomendasi, dan deteksi ancaman. Pelajari selengkapnya tentang menggunakan Defender untuk API dengan API Management

Otorisasi tingkat objek rusak

Objek API yang tidak dilindungi dengan tingkat otorisasi yang sesuai mungkin rentan terhadap kebocoran data dan manipulasi data yang tidak sah melalui pengidentifikasi akses objek yang lemah. Misalnya, penyerang dapat mengeksploitasi pengidentifikasi objek bilangan bulat, yang dapat diulang.

Informasi selengkapnya tentang ancaman ini: API1:2019 Otorisasi Tingkat Objek Rusak

Rekomendasi

  • Tempat terbaik untuk menerapkan otorisasi tingkat objek adalah dalam API backend itu sendiri. Di backend, keputusan otorisasi yang tepat dapat dibuat pada tingkat permintaan (atau objek), jika berlaku, menggunakan logika yang berlaku untuk domain dan API. Pertimbangkan skenario saat permintaan tertentu dapat menghasilkan tingkat detail yang berbeda dalam respons, tergantung izin dan otorisasi pemohon.

  • Jika API yang rentan saat ini tidak dapat diubah di backend, maka API Management dapat digunakan sebagai fallback. Contohnya:

    • Gunakan kebijakan kustom untuk menerapkan otorisasi tingkat objek, jika tidak diterapkan di backend.

    • Terapkan kebijakan kustom untuk memetakan pengidentifikasi dari permintaan ke backend dan dari backend ke klien, sehingga pengidentifikasi internal tidak terekspos.

      Dalam kasus ini, kebijakan kustom bisa berupa ekspresi kebijakan dengan pencarian (misalnya, kamus) atau integrasi dengan layanan lain melalui kebijakan kirim permintaan.

  • Untuk skenario GraphQL, terapkan otorisasi tingkat objek melalui kebijakan validasi permintaan GraphQL, menggunakan elemen authorize.

Autentikasi pengguna rusak

Mekanisme autentikasi sering diterapkan dengan tidak benar atau tidak ada, sehingga penyerang dapat mengeksploitasi kelemahan penerapan untuk mengakses data.

Informasi selengkapnya tentang ancaman ini: API2:2019 Autentikasi Pengguna Rusak

Rekomendasi

Gunakan API Management untuk autentikasi dan otorisasi pengguna:

  • Autentikasi - API Management mendukung metode autentikasi berikut:

    • Kebijakan autentikasi dasar - Informasi masuk nama pengguna dan kata sandi.

    • Kunci langganan - Kunci langganan menyediakan tingkat keamanan yang sama dengan autentikasi dasar dan mungkin tidak cukup sendiri. Jika kunci langganan disusupi, penyerang bisa mendapatkan akses tidak terbatas ke sistem.

    • Kebijakan sertifikat klien - Menggunakan sertifikat klien lebih aman daripada informasi masuk dasar atau kunci langganan, tetapi tidak mengizinkan fleksibilitas yang disediakan oleh protokol otorisasi berbasis token seperti OAuth 2.0.

  • Otorisasi - API Management mendukung kebijakan validasi JWT untuk memeriksa validitas token akses JWT OAuth 2.0 yang masuk berdasarkan informasi yang diperoleh dari titik akhir metadata penyedia identitas OAuth. Konfigurasikan kebijakan untuk memeriksa klaim token, audiens, dan waktu kedaluwarsa yang relevan. Pelajari selengkapnya tentang melindungi API menggunakan otorisasi OAuth 2.0 dan ID Microsoft Entra.

Rekomendasi lainnya:

  • Gunakan kebijakan dalam API Management untuk meningkatkan keamanan. Misalnya, pembatasan tarif panggilan memperlambat pelaku jahat menggunakan serangan brute force untuk menyusupi informasi masuk.

  • API harus menggunakan TLS/SSL (keamanan transportasi) untuk melindungi informasi masuk atau token. Informasi masuk dan token harus dikirim dalam header permintaan dan bukan sebagai parameter kueri.

  • Di portal pengembang API Management, konfigurasikan ID Microsoft Entra atau Azure Active Directory B2C sebagai idP untuk meningkatkan keamanan akun. Portal pengembang menggunakan CAPTCHA untuk mengurangi serangan brute force.

Paparan data yang berlebihan

Desain antarmuka API yang bagus sangat menantang. Seringkali, terutama dengan API lama yang telah berevolusi seiring waktu, antarmuka permintaan dan respons berisi lebih banyak bidang data dari yang dibutuhkan aplikasi yang menggunakannya.

Pelaku jahat dapat mencoba mengakses API secara langsung (mungkin dengan memutar ulang permintaan yang valid), atau mengendus lalu lintas antara server dan API. Analisis tindakan API dan data yang tersedia dapat menghasilkan data sensitif kepada penyerang, yang tidak muncul ke, atau digunakan oleh, aplikasi frontend.

Informasi selengkapnya tentang ancaman ini: API3:2019 Paparan Data Berlebihan

Rekomendasi

  • Pendekatan terbaik untuk mengurangi kerentanan ini adalah memastikan antarmuka eksternal yang ditentukan di API backend dirancang dengan hati-hati dan, idealnya, secara independen dari persistensi data. Antarmuka tersebut hanya boleh berisi bidang yang diperlukan oleh konsumen API. API harus sering ditinjau, dan bidang lama tidak digunakan lagi, lalu dihapus.

    Di API Management, gunakan:

    • Revisi untuk mengontrol perubahan yang tidak mencolok dengan baik, misalnya, penambahan bidang ke antarmuka. Anda dapat menggunakan revisi bersama dengan implementasi penerapan versi di backend.

    • Versi untuk perubahan yang mencolok, misalnya, penghapusan bidang dari antarmuka.

  • Jika tidak dapat mengubah desain antarmuka backend dan data yang berlebihan menjadi perhatian, gunakan kebijakan transformasi API Management untuk menulis ulang payload respons dan menutupi atau memfilter data. Misalnya, hapus properti JSON yang tidak diperlukan dari isi respons.

  • Validasi konten respons dalam API Management dapat digunakan dengan skema XML atau JSON untuk memblokir respons dengan properti yang tidak terdokumentasi atau nilai yang tidak tepat. Kebijakan ini juga mendukung respons pemblokiran yang melebihi ukuran tertentu.

  • Gunakan kebijakan validasi kode status untuk memblokir respons dengan kesalahan yang tidak ditentukan dalam skema API.

  • Gunakan kebijakan validasi header untuk memblokir respons dengan header yang tidak ditentukan dalam skema atau tidak mematuhi definisinya dalam skema. Hapus header yang tidak diinginkan dengan kebijakan tetapkan header.

  • Untuk skenario GraphQL, gunakan kebijakan validasi permintaan GraphQL untuk memvalidasi permintaan GraphQL, mengotorisasi akses ke jalur kueri tertentu, dan membatasi ukuran respons.

Kurangnya sumber daya dan pembatasan tarif

Kurangnya pembatasan tarif dapat menyebabkan penyelundupan data atau serangan DDoS yang berhasil pada layanan backend, menyebabkan gangguan untuk semua konsumen.

Informasi selengkapnya tentang ancaman ini: API4:2019 Kurangnya sumber daya dan pembatasan tarif

Rekomendasi

  • Gunakan kebijakan pembatasan tarif (jangka pendek) dan batas kuota (jangka panjang) untuk mengontrol jumlah panggilan API atau bandwidth yang diizinkan per konsumen.

  • Tentukan definisi objek permintaan yang ketat dan propertinya dalam definisi OpenAPI. Misalnya, tentukan nilai maksimum untuk bilangan bulat penomoran halaman, maxLength, dan ekspresi reguler (regex) untuk string. Terapkan skema tersebut dengan kebijakan validasi konten dan validasi parameter di API Management.

  • Terapkan ukuran maksimum permintaan dengan kebijakan validasi konten.

  • Optimalkan performa dengan caching bawaan, sehingga mengurangi penggunaan sumber daya CPU, memori, dan jaringan untuk operasi tertentu.

  • Menerapkan autentikasi untuk panggilan API (lihat Autentikasi pengguna yang rusak). Cabut akses pengguna yang kasar. Misalnya, nonaktifkan kunci langganan, blokir alamat IP dengan kebijakan batasi IP penelepon, atau tolak permintaan untuk klaim pengguna tertentu dari token JWT.

  • Terapkan kebijakan CORS untuk mengontrol situs web yang diizinkan untuk memuat sumber daya yang dilayani melalui API. Untuk menghindari konfigurasi yang terlalu permisif, jangan gunakan nilai wildcard (*) dalam kebijakan CORS.

  • Kurangi waktu yang dibutuhkan layanan backend untuk merespons. Semakin lama layanan backend merespons, semakin lama koneksi ditempati di API Management, oleh karena itu mengurangi jumlah permintaan yang dapat dilayani dalam jangka waktu tertentu.

  • Meskipun API Management dapat melindungi layanan backend dari serangan DDoS, API Management mungkin rentan terhadap serangan itu sendiri. Sebarkan layanan perlindungan bot di depan API Management (misalnya, Azure Application Gateway, Azure Front Door, atau Azure DDoS Protection) untuk melindungi dari serangan DDoS dengan lebih baik. Saat menggunakan WAF dengan Azure Application Gateway atau Azure Front Door, pertimbangkan untuk menggunakan Microsoft_BotManagerRuleSet_1.0.

Otorisasi tingkat fungsi rusak

Kebijakan kontrol akses yang kompleks dengan hierarki, grup, dan peran yang berbeda, dan pemisahan yang tidak jelas antara fungsi administratif dan reguler menyebabkan kelemahan otorisasi. Dengan mengeksploitasi masalah ini, penyerang mendapatkan akses ke sumber daya atau fungsi administratif pengguna lain.

Informasi selengkapnya tentang ancaman ini: API5:2019 Otorisasi tingkat fungsi rusak

Rekomendasi

  • Secara default, lindungi semua titik akhir API di API Management dengan kunci langganan.

  • Tentukan kebijakan validasi JWT dan terapkan klaim token yang diperlukan. Jika operasi tertentu memerlukan penerapan klaim yang lebih ketat, tentukan kebijakan validate-jwt tambahan hanya untuk operasi tersebut.

  • Gunakan jaringan virtual Azure atau Private Link untuk menyembunyikan titik akhir API dari internet. Pelajari selengkapnya tentang opsi jaringan virtual dengan API Management.

  • Jangan tentukan operasi API wildcard (yaitu, API "catch-all" dengan * sebagai jalur). Pastikan bahwa API Management hanya melayani permintaan untuk titik akhir yang ditentukan secara eksplisit, dan permintaan ke titik akhir yang tidak ditentukan ditolak.

  • Jangan terbitkan API dengan produk terbuka yang tidak memerlukan langganan.

Penugasan massal

Jika API menawarkan lebih banyak bidang dari yang diperlukan klien untuk tindakan tertentu, penyerang dapat memasukkan properti yang berlebihan untuk melakukan operasi yang tidak sah pada data. Penyerang dapat menemukan properti yang tidak terdokumentasi dengan memeriksa format permintaan dan respons atau API lain, atau menebaknya. Kerentanan ini terutama berlaku jika Anda tidak menggunakan bahasa pemrograman yang diketik dengan jelas.

Informasi selengkapnya tentang ancaman ini: API6:2019 Penugasan massal

Rekomendasi

  • Antarmuka API eksternal harus dipisahkan dari penerapan data internal. Hindari mengikat kontrak API langsung ke kontrak data di layanan backend. Sering tinjau desain API, serta hentikan dan hapus properti lama menggunakan penerapan versi di API Management.

  • Tentukan kontrak XML dan JSON dengan tepat dalam skema API dan gunakan kebijakan validasi konten dan validasi parameter untuk memblokir permintaan dan respons dengan properti yang tidak terdokumentasi. Memblokir permintaan dengan properti yang tidak terdokumentasi mengurangi serangan, sementara memblokir respons dengan properti yang tidak terdokumentasi membuatnya lebih sulit merekayasa ulang vektor serangan potensial.

  • Jika antarmuka backend tidak dapat diubah, gunakan kebijakan transformasi untuk menulis ulang payload permintaan dan respons dan memisahkan kontrak API dari kontrak backend. Misalnya, menutupi atau memfilter data atau menghapus properti JSON yang tidak perlu.

Kesalahan konfigurasi keamanan

Penyerang dapat mencoba mengeksploitasi kerentanan kesalahan konfigurasi keamanan seperti:

  • Pengerasan keamanan tidak ada
  • Fitur yang tidak perlu diaktifkan
  • Koneksi jaringan tidak perlu terbuka ke internet
  • Penggunaan protokol atau cipher yang lemah
  • Pengaturan atau titik akhir lain yang dapat mengizinkan akses tidak sah ke sistem

Informasi selengkapnya tentang ancaman ini: API7:2019 Kesalahan konfigurasi keamanan

Rekomendasi

  • Konfigurasikan gateway TLS dengan benar. Jangan gunakan protokol yang rentan (misalnya, TLS 1.0, 1.1) atau cipher.

  • Konfigurasikan API untuk menerima lalu lintas terenkripsi saja, misalnya melalui protokol HTTPS atau WSS.

  • Pertimbangkan untuk menyebarkan API Management di belakang titik akhir privat atau dilampirkan ke jaringan virtual yang disebarkan dalam mode internal. Di jaringan internal, akses dapat dikontrol dari dalam jaringan privat (melalui firewall atau kelompok keamanan jaringan) dan dari internet (melalui proksi terbalik).

  • Gunakan kebijakan Azure API Management:

    • Selalu warisi kebijakan induk melalui tag <base>.

    • Saat menggunakan OAuth 2.0, konfigurasikan dan uji kebijakan validasi JWT untuk memeriksa keberadaan dan validitas token JWT sebelum menjangkau backend. Periksa secara otomatis waktu kedaluwarsa token, tanda tangan token, dan pengeluar sertifikat. Terapkan klaim, audiens, kedaluwarsa token, dan tanda tangan token melalui pengaturan kebijakan.

    • Konfigurasikan kebijakan CORS dan jangan gunakan wildcard * untuk opsi konfigurasi apa pun. Sebaliknya, secara eksplisit cantumkan nilai yang diizinkan.

    • Atur kebijakan validasi ke prevent di lingkungan produksi untuk memvalidasi skema JSON dan XML, header, parameter kueri, dan kode status, dan untuk menerapkan ukuran maksimum permintaan atau respons.

    • Jika API Management berada di luar batas jaringan, validasi IP klien tetap dapat menggunakan kebijakan batasi IP penelepon. Pastikan bahwa ia menggunakan daftar yang diizinkan, bukan daftar blokir.

    • Jika sertifikat klien digunakan antara pemanggil dan API Management, gunakan kebijakan validasi sertifikat klien. Pastikan atribut validate-revocation, validate-trust, validate-not-before, dan validate-not-after semuanya diatur ke true.

      • Sertifikat klien (TLS bersama) juga dapat diterapkan antara API Management dan backend. Backend harus:

        • Mengonfigurasi informasi masuk otorisasi

        • Memvalidasi rantai sertifikat jika berlaku

        • Memvalidasi nama sertifikat jika berlaku

  • Untuk skenario GraphQL, gunakan kebijakan validasi permintaan GraphQL. Pastikan elemen authorization dan atribut max-sizemax-depth diatur.

  • Jangan menyimpan rahasia dalam file kebijakan atau di kontrol sumber. Selalu gunakan nilai bernama API Management atau ambil rahasia saat runtime menggunakan ekspresi kebijakan kustom.

    • Nilai bernama harus diintegrasikan dengan Key Vault atau dienkripsi dalam API Management dengan menandainya "rahasia". Jangan pernah menyimpan rahasia dalam nilai bernama teks biasa.

  • Terbitkan API melalui produk, yang memerlukan langganan. Jangan gunakan produk terbuka yang tidak memerlukan langganan.

  • Gunakan integrasi Key Vault untuk mengelola semua sertifikat – ini memusatkan manajemen sertifikat dan dapat membantu memudahkan tugas manajemen operasi seperti perpanjangan atau pencabutan sertifikat.

  • Saat menggunakan gateway yang di-hosting sendiri, pastikan ada proses untuk memperbarui gambar ke versi terbaru secara berkala.

  • Mewakili layanan backend sebagai entitas backend. Konfigurasikan informasi masuk otorisasi, validasi rantai sertifikat, dan validasi nama sertifikat jika berlaku.

  • Saat menggunakan portal pengembang:

    • Jika Anda memilih untuk meng-hosting sendiri portal pengembang, pastikan ada proses untuk memperbarui portal yang di-hosting sendiri secara berkala ke versi terbaru. Pembaruan untuk versi terkelola default bersifat otomatis.

    • Gunakan ID Microsoft Entra atau Azure Active Directory B2C untuk pendaftaran dan masuk pengguna. Nonaktifkan autentikasi nama pengguna dan kata sandi default, yang kurang aman.

    • Tetapkan grup pengguna ke produk, untuk mengontrol visibilitas API di portal.

  • Gunakan Azure Policy untuk menerapkan konfigurasi tingkat sumber daya API Management dan izin kontrol akses berbasis peran (RBAC) untuk mengontrol akses sumber daya. Berikan hak istimewa minimum yang diperlukan untuk setiap pengguna.

  • Gunakan proses DevOps dan pendekatan infrastruktur sebagai kode di luar lingkungan pengembangan untuk memastikan konsistensi konten API Management dan perubahan konfigurasi dan untuk meminimalkan kesalahan manusia.

  • Jangan gunakan fitur yang tidak digunakan lagi.

Injeksi

Setiap titik akhir yang menerima data pengguna berpotensi rentan terhadap eksploitasi injeksi. Contoh meliputi tetapi tidak terbatas pada:

  • Injeksi perintah, di mana pelaku jahat mencoba mengubah permintaan API untuk menjalankan perintah pada sistem operasi yang meng-hosting API

  • Injeksi SQL, di mana pelaku jahat mencoba mengubah permintaan API untuk menjalankan perintah dan kueri terhadap database yang bergantung pada API

Informasi selengkapnya tentang ancaman ini: API8:2019 Injeksi

Rekomendasi

  • Kebijakan Web Application Firewall (WAF) modern membahas banyak kerentanan injeksi umum. Meskipun API Management tidak memiliki komponen WAF bawaan, menyebarkan upstream WAF (di depan) instans API Management sangat disarankan. Misalnya, gunakan Azure Application Gateway atau Azure Front Door.

    Penting

    Pastikan bahwa pelaku jahat tidak dapat melewati gateway yang meng-hosting WAF dan terhubung langsung ke gateway API Management atau API backend itu sendiri. Kemungkinan mitigasi meliputi: ACL jaringan, menggunakan kebijakan API Management untuk membatasi lalu lintas masuk oleh IP klien, menghapus akses publik jika tidak diperlukan, dan autentikasi sertifikat klien (juga dikenal sebagai TLS atau mTLS bersama).

  • Gunakan kebijakan validasi skema dan parameter, jika berlaku, untuk lebih membatasi dan memvalidasi permintaan sebelum menjangkau layanan API backend.

    Skema yang disediakan dengan definisi API harus memiliki batasan pola regex yang diterapkan ke bidang yang rentan. Setiap regex harus diuji untuk memastikan bahwa regex membatasi bidang dengan cukup untuk mengurangi upaya injeksi umum.

Manajemen aset yang tidak tepat

Kerentanan terkait manajemen aset yang tidak tepat meliputi:

  • Kurangnya dokumentasi API atau informasi kepemilikan yang tepat

  • Jumlah versi API yang lebih lama yang berlebihan, yang mungkin tidak memiliki perbaikan keamanan

Informasi selengkapnya tentang ancaman ini: API9:2019 Manajemen aset yang tidak tepat

Rekomendasi

  • Gunakan spesifikasi OpenAPI yang ditentukan dengan baik sebagai sumber untuk mengimpor REST API. Spesifikasi ini memungkinkan enkapkulasi definisi API, termasuk metadata yang mendokumentasikan sendiri.

    • Gunakan antarmuka API dengan jalur yang tepat, skema data, header, parameter kueri, dan kode status. Hindari operasi wildcard. Berikan deskripsi untuk setiap API dan operasi serta sertakan informasi kontak dan lisensi.

    • Hindari titik akhir yang tidak secara langsung berkontribusi pada tujuan bisnis. Titik akhir ini tidak perlu meningkatkan area permukaan serangan dan membuatnya lebih sulit mengembangkan API.

  • Gunakan revisi dan versi dalam API Management untuk mengatur dan mengontrol titik akhir API. Memiliki strategi penerapan versi backend yang kuat dan berkomitmen untuk jumlah maksimum versi API yang didukung (misalnya, 2 atau 3 versi sebelumnya). Rencanakan untuk menghentikan dengan cepat dan pada akhirnya menghapus versi API yang lama, sering kali kurang aman.

  • Gunakan instans API Management per lingkungan (seperti pengembangan, pengujian, dan produksi). Pastikan setiap instans API Management terhubung ke dependensinya di lingkungan yang sama. Misalnya, di lingkungan pengujian, sumber daya API Management pengujian harus terhubung ke sumber daya Azure Key Vault pengujian dan versi pengujian layanan backend. Gunakan otomatisasi DevOps dan praktik infrastruktur sebagai kode untuk membantu menjaga konsistensi dan akurasi antara lingkungan dan mengurangi kesalahan manusia.

  • Gunakan tag untuk mengatur API dan produk lalu mengelompokkannya untuk penerbitan.

  • Terbitkan API untuk digunakan melalui portal pengembang bawaan. Pastikan dokumentasi API sudah diperbarui.

  • Temukan API yang tidak terdokumentasi atau tidak terkelola dan ekspos melalui API Management untuk kontrol yang lebih baik.

Pencatatan log dan pemantauan tidak mencukupi

Pencatatan log dan pemantauan yang tidak mencukupi, ditambah dengan integrasi yang hilang atau tidak efektif dengan respons insiden, memungkinkan penyerang untuk lebih lanjut menyerang sistem, mempertahankan persistensi, pivot ke lebih banyak sistem untuk dirusak, dan mengekstrak atau menghancurkan data. Sebagian besar studi pelanggaran menunjukkan bahwa waktu untuk mendeteksi pelanggaran lebih dari 200 hari, biasanya terdeteksi oleh pihak eksternal daripada proses internal atau pemantauan.

Informasi selengkapnya tentang ancaman ini: API10:2019 Pencatatan log dan pemantauan tidak mencukupi

Rekomendasi

Langkah berikutnya

Pelajari lebih lanjut tentang: