API security: kawalan akses dan logging yang berguna

0 komen

Semak API dengan melihat keputusan authorization, respons kepada pengguna dan bukti untuk penyiasatan secara bersama. Panduan ini menyediakan pelan makmal dan syarat lulus ujian untuk dibincangkan dengan developer dan SOC.

Ringkasan pertahanan API melalui authorization objek, respons terkawal dan bukti audit.
Panduan mereka bentuk dan menyemak pertahanan API.

Executive Summary

Menurut OWASP, perkhidmatan REST yang bukan untuk akses awam perlu menyemak hak akses pada setiap endpoint API. 1 Jika endpoint menerima ID objek, semak juga sama ada pengguna dibenarkan melakukan tindakan itu pada objek tersebut. 3

Kami mencadangkan pasukan memilih satu fungsi perniagaan dan menyenaraikan hak aksesnya dalam matriks. Kemudian, uji respons dan rekod audit bersama-sama. Melalui panduan ini, pembaca diharap dapat membezakan identiti pemanggil API daripada haknya untuk mengakses objek. Pembaca juga dapat menentukan bukti yang perlu disemak dan syarat lulus ujian sebelum perubahan dilancarkan.

Prasyarat dan Skop

Gunakan API makmal milik organisasi atau persekitaran ujian yang mempunyai kebenaran bertulis. Sediakan dua akaun sintetik, dua tenant rekaan dan beberapa invois palsu. Tentukan siapa yang bertanggungjawab terhadap ujian, bila ujian dijalankan, had permintaan dan cara menghentikannya. Semua contoh di bawah ialah cadangan reka bentuk. Tiada permintaan API dibuat atau ujian keselamatan aplikasi dijalankan untuk artikel ini.

Dalam contoh ini, andaikan akaun A hanya boleh membaca invois milik tenant A. Akaun B pula mewakili tenant B. Tentukan keputusan yang dijangka sebelum membuka klien ujian. Elakkan data pelanggan sebenar, operasi memadam, pemindahan wang atau perubahan privilege. Panduan ini hanya meliputi bacaan data dan semakan konfigurasi, bukan penerokaan sasaran Internet.

Kaedah dan Penjelasan

1. Nyatakan keputusan authorization

OWASP mengesyorkan deny by default dan semakan permission pada setiap request. 4 Untuk makmal ini, tulis satu baris polisi bagi setiap gabungan peranan, tindakan dan jenis objek. Sertakan kes tanpa identiti dan kes yang tiada kebenaran jelas dalam polisi.

Dalam contoh invois, catat akaun mana yang boleh mengakses tenant dan invois tertentu. Log masuk yang berjaya sahaja tidak cukup untuk membenarkan akses. Broken Object Level Authorization berlaku pada tahap objek walaupun pengguna dibenarkan mengakses fungsi tersebut. 3 MITRE CWE-639 pula menerangkan kelemahan yang membolehkan pengguna mengakses rekod orang lain dengan mengubah key yang dikawalnya. 5

Kami mencadangkan pemilik produk meluluskan polisi dan developer menunjukkan tempat semakan akses dibuat. Reviewer kemudian memadankan polisi dan semakan itu dengan kes ujian. Jika API menggunakan gateway, minta developer menunjukkan komponen yang menentukan akses kepada objek. Tandakan sempadan komponen itu dalam rajah dalaman. Jangan anggap rajah umum dalam artikel ini menggambarkan deployment sebenar.

Peta batasan bukti yang membezakan panduan OWASP, contoh invois makmal dan keputusan deployment yang belum diuji.
Rajah ini memisahkan dokumentasi, contoh makmal dan perkara yang belum disahkan.

Peta ini menunjukkan perkara yang disokong dokumentasi dan perkara yang masih perlu dibuktikan oleh pasukan. Ia bukan urutan exploit atau gambaran insiden sebenar. Semasa semakan, gunakannya untuk menandakan andaian yang memerlukan bukti daripada kod, konfigurasi atau hasil ujian.

2. Pisahkan respons awam daripada bukti dalaman

OWASP menyarankan mesej ralat umum kepada klien, tanpa stack trace atau butiran dalaman. Panduan itu menetapkan 401 untuk masalah authentication. Kod 403 pula digunakan apabila identiti sudah disahkan tetapi akses tidak dibenarkan. OWASP juga tidak mengesyorkan penggunaan API key sahaja untuk melindungi sumber sensitif atau bernilai tinggi. 1

Untuk makmal invois, kami mencadangkan respons ringkas dengan kod ralat aplikasi yang didokumenkan. Semak body respons bersama status HTTP. Syarat lulus ujian mesti menyatakan bahawa respons tidak boleh mengandungi invois tenant lain. Minta reviewer membandingkan kes akses dibenarkan dan ditolak dengan data sintetik yang sama. Jika respons tidak sepadan dengan kontrak API, catat sebagai isu untuk diselesaikan. Jangan terus menukar semua respons kepada satu kod.

3. Tentukan log yang benar-benar diperlukan

Menurut OWASP, jenis rekod log yang diperlukan bergantung pada seni bina, jenis aplikasi dan sistem hos. 2 Dokumen itu mengesyorkan supaya kegagalan authorization direkodkan bersama konteks masa, lokasi, identiti dan peristiwa. Jangan rekodkan access token dan kata laluan secara langsung. Sanitization pula membantu menangani log injection. 2

Untuk skema log makmal, kami mencadangkan masa peristiwa, ID korelasi, alias akaun sintetik, nama operasi, alias objek dan keputusan polisi. Contoh rekaan: operasi baca invois, akaun A, objek invois B, keputusan ditolak. Ini bukan output sebenar atau IOC. Pemilik aplikasi perlu meluluskan medan dan maksud setiap nilai sebelum SOC membina carian.

Perbandingan bukti pada klien dan rekod dalaman untuk semakan respons API serta keputusan authorization.
Cadangan syarat lulus ujian berdasarkan respons klien dan bukti dalaman.

Semak kedua-dua sisi: respons yang diterima pemanggil API dan bukti yang boleh diperiksa oleh reviewer. Nyatakan bukti minimum untuk kedua-duanya dalam tiket perubahan. Jika salah satu tiada, tandakan ujian sebagai belum lengkap. Ini tetap terpakai walaupun developer sudah menunjukkan kod semakan akses.

Pengesahan Hasil

OWASP mengesyorkan ujian authorization dan menyekat deployment jika perubahan menyebabkan ujian itu gagal. 3 Berikut ialah matriks syarat lulus yang dicadangkan untuk makmal invois. Pasukan perlu mengisi keputusan sebenar selepas menjalankan ujian:

  • Akaun A membaca invois A: akses dibenarkan mengikut polisi contoh. Body hanya mengandungi rekod sintetik yang dijangka.
  • Akaun A membaca invois B: akses ditolak. Body tidak mengandungi invois B, dan reviewer boleh mencari rekod penolakan itu dalam log.
  • Request tanpa identiti yang diperlukan: authentication gagal. Reviewer menyemak kontrak respons tanpa memasukkan token sebenar dalam laporan.
  • Kes tanpa peraturan yang membenarkan akses: akses kekal ditolak. Pemilik polisi menyemak sama ada kes itu memang patut disokong.

Untuk setiap kes, simpan ID ujian, masa, polisi yang digunakan, keputusan yang dijangka, keputusan sebenar dan rujukan bukti yang telah disunting. Minta reviewer kedua mengulangi sekurang-kurangnya kes akses merentas tenant. Jangan tandakan ujian lulus berdasarkan status HTTP sahaja. Semak juga kandungan respons dan rekod audit yang berkaitan.

Checklist penerimaan makmal: semak polisi, uji akses lintas tenant, periksa respons dan padankan bukti log.
Empat semakan untuk pelan makmal yang boleh diaudit.

Batasan dan Pemulihan

Matriks ringkas ini tidak meliputi semua endpoint, jenis objek atau perubahan peranan. Jika mahu meluaskan scope, tambah kes secara berperingkat dan tentukan siapa yang bertanggungjawab bagi setiap kes. Tiada produk atau versi tertentu dinyatakan sebagai terjejas. Panduan ini juga tidak mengesahkan keselamatan sesuatu deployment.

OWASP turut meminta pasukan menguji kegagalan logging dan kawalan akses kepada log. 2 Kami mencadangkan simulasi kegagalan penghantaran log menggunakan stub dalam makmal. Tetapkan had masa dan keadaan yang menunjukkan sistem sudah pulih. Jangan penuhkan cakera atau ganggu collector produksi untuk membuktikan kegagalan itu.

Sebelum mengubah konfigurasi, simpan versi polisi terakhir yang telah disemak. Tetapkan juga keadaan yang memerlukan rollback. Jika akses yang sah terganggu, hentikan pelancaran perubahan. Selepas semakan pemilik, pulihkan konfigurasi yang diketahui sesuai. Jangan longgarkan semua permission sebagai jalan pintas. Selepas pemulihan, ulang kes akses dibenarkan dan ditolak. Catat perkara yang masih belum diliputi oleh ujian.

Apa Yang Security Team Malaysia Perlu Buat

Untuk pasukan Malaysia, kami mencadangkan semakan bersama pemilik satu API pelanggan atau rakan integrasi. Lantik seorang yang bertanggungjawab terhadap keputusan authorization dan seorang lagi terhadap bukti pemantauan. Gunakan istilah tenant, pengguna dan objek secara konsisten dalam tiket pembangunan dan runbook SOC. Dengan itu, kedua-dua pasukan boleh menyemak keputusan yang sama.

Dalam sesi serahan tugas, minta developer menunjukkan satu penolakan akses yang dijangka. Kemudian, minta SOC mencari rekodnya. Sepakati siapa yang menyemak log, berapa lama log disimpan mengikut keperluan organisasi dan langkah eskalasi jika bukti hilang. Artikel ini tidak menetapkan tempoh undang-undang atau mendakwa ada insiden tempatan. Sesi itu sepatutnya menghasilkan matriks yang diluluskan, senarai perkara yang masih belum lengkap dan pihak yang bertanggungjawab mengambil tindakan.

References

Dokumentasi primer dibaca pada 29 September 2026. Tarikh ini ialah tarikh bacaan, bukan tarikh insiden atau kemas kini dokumen.

  1. OWASP — REST Security Cheat Sheet: Access Control, API Keys, Error handling, HTTP Return Code.
  2. OWASP — Logging Cheat Sheet: Which events to log, Event attributes, Data to exclude, Event collection, Verification.
  3. OWASP — API1:2023 Broken Object Level Authorization: Is the API Vulnerable?, How To Prevent.
  4. OWASP — Authorization Cheat Sheet: Deny by Default, Validate the Permissions on Every Request.
  5. MITRE — CWE-639: Authorization Bypass Through User-Controlled Key: Description dan Extended Description.