sysbraykr.com news -

1. Mengubah versi API: api/v3/login → api/v1/login

Penjelasan: Dalam pengembangan API, versi lama dari API sering kali digunakan untuk menjaga kompatibilitas ke belakang. Namun, versi yang lebih tua mungkin tidak seaman versi yang lebih baru karena belum menerapkan mekanisme keamanan terbaru. Penyerang mungkin mencoba mengakses versi API yang lebih lama (misalnya api/v1/login) untuk mengeksploitasi kerentanan yang sudah diperbaiki di versi yang lebih baru (seperti api/v3/login).

Kenapa penting: Jika API lama masih dapat diakses, penyerang bisa memanfaatkan kelemahan keamanan di versi tersebut untuk melewati kontrol keamanan, mencuri data, atau melakukan tindakan tidak sah.

Ringkasan referensi: Berdasarkan OWASP API Security Top 10, API yang tidak diperbarui atau tidak ditambal bisa menimbulkan risiko besar, seperti autentikasi yang rusak atau paparan data yang tidak aman.

Referensi: https://owasp.org/www-project-api-security/

2. Cek endpoint AuthN lain: /api/mobile/login → /api/v3/login /api/magic_link

Penjelasan: Banyak sistem memiliki beberapa endpoint autentikasi untuk platform yang berbeda (misalnya, /api/mobile/login untuk aplikasi mobile dan /api/v3/login untuk aplikasi web). Masing-masing endpoint ini mungkin memiliki tingkat keamanan yang berbeda. Penyerang sering kali menguji berbagai jalur autentikasi (seperti autentikasi menggunakan magic link /api/magic_link) untuk menemukan titik lemah.

Kenapa penting: Setiap endpoint autentikasi bisa memiliki konfigurasi keamanan yang berbeda. Menguji semuanya penting untuk memastikan bahwa penyerang tidak bisa melewati metode autentikasi yang lebih kuat dengan menggunakan endpoint yang lebih lemah.

Ringkasan referensi: OWASP API Security menekankan pentingnya memiliki mekanisme autentikasi yang aman di semua endpoint untuk mencegah akses yang tidak sah.

Referensi: https://owasp.org/www-project-api-security/

3. Verb Tampering: GET /api/trips/1 → POST /api/trips/1 atau DELETE /api/trips/1

Penjelasan: Verb tampering adalah teknik di mana penyerang mengubah metode HTTP yang digunakan untuk berinteraksi dengan API (misalnya, mengubah permintaan GET menjadi POST, PUT, atau DELETE). Contohnya, penyerang bisa mencoba mengubah permintaan yang hanya membaca data (GET) menjadi permintaan yang mengubah atau menghapus data (POST atau DELETE). Hal ini dilakukan untuk melihat apakah API gagal menerapkan pembatasan metode HTTP dengan benar.

Kenapa penting: Jika API tidak secara ketat memvalidasi metode HTTP, penyerang dapat melakukan tindakan yang tidak sah seperti mengubah atau menghapus data.

Ringkasan referensi: OWASP memperingatkan tentang endpoint API yang tidak memeriksa metode HTTP dengan benar, yang dapat menyebabkan tindakan tidak sah seperti mengubah atau menghapus data sensitif.

Referensi: https://owasp.org/www-project-api-security/

4. Coba gunakan Object IDs di header dan body HTTP, karena URL cenderung lebih aman

Penjelasan: Dalam interaksi dengan API, data sensitif seperti object identifier (ID) sering kali dikirim melalui URL. Beberapa pengembang mungkin tidak mengamankan ID ini dengan benar di header atau body HTTP, sehingga rentan dimanipulasi (misalnya dengan mengganti ID untuk mengakses data yang tidak sah). Object ID biasanya lebih terlindungi jika dikirim di header HTTP daripada URL, yang lebih jarang diintersep.

Kenapa penting: Jika API membolehkan perubahan langsung pada object ID (seperti mengubah user ID), penyerang bisa menggunakan ini untuk mengakses atau memanipulasi data yang tidak sah.

Ringkasan referensi: OWASP menyatakan bahwa API harus melindungi pengidentifikasi sensitif dan mengelolanya dengan aman untuk mencegah manipulasi ID yang tidak sah.

Referensi: https://owasp.org/www-project-api-security/

5. Coba gunakan Numeric IDs ketika menghadapi GUID/UUID: GET /api/users/6b95d962-df38 → GET /api/users/1

Penjelasan: Beberapa API menggunakan identifier yang rumit seperti UUID (Universally Unique Identifier) untuk alasan keamanan. Namun, kadang-kadang pengembang masih menyediakan dukungan untuk ID numerik sederhana (seperti 1, 2, 3), yang lebih mudah ditebak atau dieksploitasi. Mengubah UUID (misalnya 6b95d962-df38) menjadi ID numerik sederhana (1) adalah tes umum untuk melihat apakah API rentan terhadap manipulasi ID.

Kenapa penting: Jika API secara tidak benar menerima UUID dan numeric ID, penyerang dapat mencoba menebak ID umum untuk mendapatkan akses atau hak istimewa yang lebih tinggi.

Ringkasan referensi: OWASP menyoroti bahwa endpoint API harus menangani object identifier dan user identifier dengan aman, menggunakan validasi yang kuat untuk mencegah manipulasi ID.

Referensi: https://owasp.org/www-project-api-security/

6. Gunakan [] pada ID dengan array: {“id”:111} → {“id”:[111]}

Penjelasan: Ini melibatkan pengiriman ID dalam format yang berbeda (seperti membungkusnya dalam array) untuk melihat apakah API merespons secara tidak terduga. Misalnya, alih-alih mengirim satu ID ({"id":111}), kamu bisa mengirim array ({"id":[111]}). Beberapa API mungkin tidak siap untuk menangani input ini dengan benar, yang dapat menyebabkan masalah keamanan.

Kenapa penting: Jika API tidak memvalidasi input secara ketat, membungkus ID dalam array atau mengubah strukturnya bisa mengakibatkan kerentanan seperti akses data yang tidak sah atau rusaknya logika sistem.

Ringkasan referensi: OWASP merekomendasikan validasi input yang ketat untuk menghindari kasus di mana API menerima format yang tidak diharapkan seperti array.

Referensi: https://owasp.org/www-project-api-security/

7. Bungkus ID dengan objek JSON: {“id”:111} → {“id”:{“id”:111}}

Penjelasan: Mirip dengan membungkus ID dalam array, di sini kamu membungkus ID dalam objek JSON (misalnya {"id":{"id":111}}). Beberapa API mungkin tidak siap menangani format input yang tidak biasa ini dan bisa merespons dengan cara yang tidak terduga, membuka peluang bagi penyerang untuk mengeksploitasi kelemahan tersebut.

Kenapa penting: Pengujian ini dilakukan untuk melihat apakah API memiliki validasi yang cukup kuat. Jika tidak, penyerang bisa menggunakan teknik ini untuk melewati validasi dan mengakses data yang tidak sah.

Ringkasan referensi: OWASP merekomendasikan agar API selalu memvalidasi struktur input secara ketat untuk mencegah kerentanan yang muncul dari manipulasi format data.

Referensi: https://owasp.org/www-project-api-security/

8. HTTP Parameter Pollution: /api/profile?user_id=legit&user_id=victim atau /api/profile?user_id=victim&user_id=legit

Penjelasan: HTTP Parameter Pollution (HPP) terjadi ketika penyerang memasukkan parameter yang sama beberapa kali dalam satu permintaan (misalnya user_id diulang dua kali). HPP dapat mengeksploitasi cara API menangani input yang ganda, terutama jika parameter yang diterima memengaruhi otorisasi pengguna.

Kenapa penting: Jika API tidak memproses parameter ganda dengan benar, penyerang dapat menggunakan teknik ini untuk memanipulasi hasil permintaan, seperti mengakses profil pengguna lain atau melakukan tindakan yang tidak sah.

Ringkasan referensi: OWASP menekankan pentingnya API untuk mengelola parameter dengan aman, terutama ketika parameter ganda atau tidak terduga diterima dalam satu permintaan.

Referensi: https://owasp.org/www-project-api-security/

9. JSON Parameter Pollution: {“user_id”,”user_id”} atau {“user_id”,”user_id”}

Penjelasan: JSON Parameter Pollution adalah teknik yang mirip dengan HTTP Parameter Pollution, tetapi terjadi di dalam permintaan JSON. Jika sebuah API tidak mengelola parameter yang diulang dalam objek JSON dengan benar, ini bisa digunakan untuk merusak logika API atau melakukan manipulasi data.

Kenapa penting: Jika API tidak memvalidasi dengan benar, penyerang dapat menyalahgunakan parameter ganda dalam JSON untuk mengakses data yang salah atau melakukan tindakan yang tidak diinginkan.

Ringkasan referensi: Seperti halnya HPP, OWASP menyarankan agar pengembang API menangani semua parameter yang dikirim melalui JSON dengan hati-hati, termasuk mendeteksi dan menolak parameter yang diulang.

Referensi: https://owasp.org/www-project-api-security/

10. Wildcard daripada ID: /api/users/1 → /api/users/ /api/users/% /api/users/_ /api/users/.*

Penjelasan: Wildcard adalah simbol yang dapat digunakan untuk mewakili satu atau lebih karakter di dalam sebuah string. Dalam pengujian API, penyerang dapat mencoba menggunakan wildcard (*, %, _, atau .) alih-alih ID spesifik untuk melihat apakah API merespons dengan memberikan akses ke semua data yang terkait.

Kenapa penting: Jika API menerima wildcard dalam permintaan ID dan merespons dengan memberikan data yang luas (misalnya, seluruh daftar pengguna), maka ini adalah kerentanan yang serius. Penyerang bisa mendapatkan akses ke data yang seharusnya tidak mereka lihat.

Ringkasan referensi: Menurut OWASP, API harus melakukan validasi input yang ketat untuk memastikan bahwa input seperti wildcard tidak menyebabkan kebocoran data.

Referensi: https://owasp.org/www-project-api-security/

11. Aplikasi Ruby dengan parameter HTTP yang mengandung URL → Menyisipkan perintah shell di depan URL menggunakan pipe (|)

Penjelasan: Beberapa API (terutama yang dibangun dengan Ruby) mungkin menerima parameter berupa URL. Penyerang dapat mencoba menyisipkan karakter pipe (|) di depan URL yang diberikan, yang kemudian dijalankan sebagai perintah shell oleh server. Ini adalah bentuk serangan injeksi command, di mana penyerang memanipulasi input agar dijalankan sebagai perintah di sistem server.

Kenapa penting: Jika API tidak mengamankan input ini dengan benar, penyerang dapat menjalankan perintah shell yang berbahaya di server, yang dapat menyebabkan kerusakan serius atau pencurian data.

Ringkasan referensi: OWASP menekankan bahwa injeksi perintah (command injection) adalah salah satu ancaman serius dalam API dan aplikasi web, karena memungkinkan eksekusi perintah berbahaya di server.

Referensi: https://owasp.org/www-project-api-security/

12. API pengembang berbeda dengan API mobile dan web. Uji secara terpisah

Penjelasan: Dalam banyak sistem, API yang digunakan oleh pengembang (misalnya untuk internal atau debug) mungkin berbeda dari API yang digunakan untuk aplikasi mobile atau web. API pengembang mungkin kurang diamankan karena tidak dirancang untuk diakses oleh publik. Oleh karena itu, pengujian terhadap API pengembang harus dilakukan secara terpisah untuk memastikan bahwa mereka tidak rentan.

Kenapa penting: API pengembang yang kurang aman bisa menjadi pintu belakang (backdoor) bagi penyerang untuk mengakses sistem dengan hak istimewa yang lebih tinggi.

Ringkasan referensi: OWASP merekomendasikan pengujian keamanan yang komprehensif untuk semua API, termasuk API pengembang yang mungkin diabaikan karena dianggap hanya untuk penggunaan internal.

Referensi: https://owasp.org/www-project-api-security/

13. Ubah Content-Type ke application/xml dan lihat apakah API bisa memprosesnya

Penjelasan: Sebagian besar API dirancang untuk menerima dan memproses data dalam format JSON. Namun, penyerang bisa mencoba mengubah header Content-Type menjadi application/xml untuk melihat apakah API akan memprosesnya dengan benar. Jika API tidak mengamankan proses parsing XML, ini dapat menyebabkan serangan seperti XML External Entity (XXE) yang memungkinkan penyerang membaca file sensitif dari server atau melakukan DoS (Denial of Service).

Kenapa penting: Penyerang bisa mengeksploitasi kelemahan parsing XML jika API tidak mengantisipasi dan mengamankan format input yang berbeda.

Ringkasan referensi: OWASP menyoroti serangan XXE sebagai salah satu bentuk eksploitasi yang sering terjadi ketika API tidak mengamankan parsing XML dengan baik.

Referensi: https://owasp.org/www-project-api-security/

14. Lingkungan non-produksi cenderung kurang aman (staging/QA, dll.) Manfaatkan ini untuk melewati otorisasi (AuthZ), autentikasi (AuthN), pembatasan rate, & validasi input

Penjelasan: Lingkungan non-produksi seperti staging atau QA biasanya tidak seaman lingkungan produksi karena digunakan untuk pengujian internal. Penyerang dapat menargetkan lingkungan ini karena sering kali memiliki kontrol keamanan yang lebih lemah atau data uji yang masih sensitif. Mereka mungkin mencoba mengeksploitasi kelemahan ini untuk melewati autentikasi, otorisasi, atau pembatasan lainnya.

Kenapa penting: Jika lingkungan non-produksi tidak dilindungi dengan baik, penyerang bisa mendapatkan akses ke sistem atau data yang seharusnya tidak mereka miliki, dan mungkin bisa menggunakan akses ini untuk menyerang lingkungan produksi.

Ringkasan referensi: OWASP menekankan pentingnya menerapkan kontrol keamanan yang sama kuatnya di lingkungan non-produksi untuk mencegah penyusupan dari lingkungan tersebut.

Referensi: https://owasp.org/www-project-api-security/

15. Export Injection jika ada fitur “Convert to PDF”

Penjelasan: Beberapa API menyediakan fitur untuk mengekspor data dalam format tertentu (misalnya, mengubah data ke PDF). Jika fitur ini tidak diimplementasikan dengan benar, penyerang bisa memanfaatkan input yang mereka masukkan untuk menyisipkan perintah atau skrip berbahaya yang dieksekusi ketika dokumen PDF dihasilkan.

Kenapa penting: Penyerang bisa memanipulasi fitur ini untuk menyisipkan kode berbahaya yang mungkin dieksekusi oleh pengguna akhir saat mereka membuka file yang dihasilkan.

Ringkasan referensi: OWASP memperingatkan bahwa fitur ekspor harus diproses dengan aman untuk mencegah eksploitasi dari input pengguna yang tidak diharapkan.


Referensi: https://owasp.org/www-project-api-security/


Artikel berdasarkan https://github.com/HolyBugx/HolyTips/blob/main/Checklist/API%20Security.md