Ujian Penembusan API Berkesan di Thailand

Aplikasi berhenti menjadi “laman web” bertahun-tahun yang lalu. Ia kini API: mikroservis memanggil mikroservis, klien mudah alih di satu hujung dan landasan pembayaran di hujung yang lain. Perbualan keselamatan belum sepenuhnya mengejar. Pasukan masih membeli “ujian penembusan aplikasi web” yang menghabiskan 80% usaha pada bahagian hadapan, manakala API di belakangnya, tempat wang dan data benar-benar bergerak, kurang diuji.

Mengapa API mengalahkan pengimbas #

Pengimbas web automatik dibina sekitar model halaman: merangkak pautan, cari borang, suntik muatan. API tidak membentangkan halaman. Ia membentangkan laluan, kaedah dan skema, dan tingkah laku yang menarik hidup dalam logik perniagaan di antara mereka.

Fikirkan kelemahan akses tahap objek: pengguna menukar user_id=1024 kepada user_id=1025 dalam satu permintaan dan membaca rekod orang lain. Tiada tandatangan tercetus. Tiada muatan berniat jahat. Pengimbas melihat permintaan normal dan bergerak pula. Inilah Broken Object Level Authorisation (BOLA), entri nombor satu dalam OWASP API Security Top 10, dan ia tidak kelihatan oleh hampir semua alat automatik.

Itulah hujah utama pengujian API diketuai manusia: kelemahan paling merosakan ialah kelemahan reka bentuk, dan reka bentuk memerlukan penganalis yang memahami konteks perniagaan untuk menemuinya.

Apa yang benar-benar diliputi oleh ujian API berkesan #

Penilaian API yang bermakna jauh melebihi menjalankan pengimbas terhadap spesifikasi OpenAPI:

• Pengesahan dan kebenaran: pengendalian token, semakan skop dan akses tahap objek merentasi setiap sempadan peranan.
• Logik perniagaan: bolehkah pengguna menetapkan harga negatif bagi pesanan, main semula panggil balik pembayaran atau melangkau langkah aliran kerja dengan terus memanggil endpoint seterusnya?
• Pendedahan data: endpoint mana yang memulangkan terlalu banyak medan, dan mana yang menerima medan yang tidak patut dihantar oleh klien.
• Had kadar dan penyalahgunaan: enumerasi, credential stuffing dan laluan pengambilalihan akaun yang menyalahgunakan throttling lemah.
• Sempadan integrasi: webhook, panggilan balik pihak ketiga dan baris gilir mesej tempat kepercayaan kerap diandaikan dan tidak pernah disahkan.

Itulah sebabnya tugasan terbaik menggabungkan kepakaran ofensif manual dengan risikan dan fuzzing dibantu AI: automasi mengembangkan liputan, manusia menilai keparahan dan konteks.

Berterusan, bukan tahunan #

Ujian API setahun sekali ialah gambar titik-masa bagi sistem yang membangun secara mingguan. Menjelang laporan siap ditulis, endpoint telah berubah. Pendekatan moden melipatgandingkan semakan keselamatan API ke dalam saluran paip penghantaran:

1. Shift-left dengan analisis statik dan validasi skema dalam CI.
2. Uji setiap keluaran: semakan fokus apabila permukaan API berubah.
3. Kajian mendalam tahunan: penilaian penuh diketuai manusia untuk jejak audit dan logik perniagaan yang tidak dapat dinilai oleh saluran paip.

PCI DSS Keperluan 6 dan Keperluan 11.4 kedua-duanya mendorong ke arah ini bagi organisasi yang menyentuh data kad, begitu juga garis panduan keselamatan saluran digital Bank of Thailand.

Apa yang pengimbas automatik tidak nampak #

Berbaloi untuk nyatakan dengan spesifik apa yang automasi tertinggal, sebab jurangnya tidak rawak: ia berkumpul tepat di tempat wang mengalir.

BOLA dalam praktik. Pengimbas menguji endpoint yang ditemui dan parameter yang difahaminya. Ambil satu API invois: GET /invoices/8842 memulangkan invois penyerunya sendiri, jadi pengimbas catat lulus. Tetapi GET /invoices/8843 (invois pelanggan lain) mungkin dipulangkan sama senangnya, dan tiada pengimbas akan mencubanya, kerana memahami bahawa 8843 milik orang lain memerlukan tahu apa maksud pemilikan dalam perniagaan anda. Setiap pengecam objek yang melintasi sempadan tenant ialah BOLA berpotensi, dan hanya penganalisis yang menghitung objek merentas akaun akan menjumpainya.

Cacat logik perniagaan. Pengimbas menguji sama ada request berjaya atau gagal; cacat logik tinggal dalam request yang berjaya sedangkan ia tidak sepatutnya. Contoh sebenar daripada engagement: kod kupon boleh digunakan dua kali kerana semakan penebusan berlaku selepas tangkapan bayaran; pemindahan tempahan antara akaun tanpa re-authorisation; pembatalan pesanan yang telah dibayar selepas dihantar kerana endpoint batal tidak pernah menyemak status pemenuhan. Setiap satunya memulangkan HTTP 200. Setiap satunya kerugian kewangan tanpa sebarang mesej ralat.

Andaian kepercayaan antara servis. Dalam estate mikroservis, satu servis lazimnya mempercayai header, token atau endpoint dalaman yang diserahkan oleh “pemanggil”, kerana dalam rajah reka bentuk pemanggil sentiasa servis dalaman juga. Kemudian satu servis dikompromikan, atau satu endpoint dalaman menjadi reachable dari segmen rangkaian yang kurang dipercayai, dan andaian kepercayaan warisan itu menjadi tangga penyerang: authenticate pada servis edge yang lemah dahulu, kemudian serahkan identitinya ke hilir di mana API bernilai tinggi berada. Menjumpai ini memerlukan membaca arkitektur mengikut niat perekanya, kemudian mengujinya seperti penyerang akan melaluinya.

Tiada satu pun daripada tiga perkara ini muncul dalam output pengimbas. Semuanya muncul dalam laporan penganalisis yang mengambil masa memahami apa API anda sebenarnya dibuat untuk.

Semakan Keselamatan API & Aplikasi kami menggabungkan analisis kod sumber manual dengan ujian penembusan kontekstual dan menghantar panduan pembaikan yang boleh terus digunakan pembangun. Jika yang anda perlukan ialah pengesahan lebih luas ke atas perimeter dan segmentasi, lihat ujian penembusan diketuai manusia.