𝗦𝗲𝗿𝗮𝗻𝗴𝗮𝗻 𝗟𝗼𝗴𝗶𝗸 𝗣𝗲𝗿𝗻𝗶𝗮𝗴𝗮𝗮𝗻 𝗗𝗶𝘁𝗲𝗿𝗮𝗻𝗴𝗸𝗮𝗻
Penyerang tidak sentiasa memecah masuk kod anda untuk mencuri wang.
Ramai pembangun menghabiskan masa berbulan-bulan untuk mengukuhkan API dan penyulitan. Mereka fokus untuk menghalang suntikan SQL atau XSS. Kemudian, penyerang mencuri dana tanpa memecahkan satu pun kawalan keselamatan.
Ini adalah serangan logik perniagaan.
Aplikasi tersebut berfungsi tepat seperti yang direka. Penyerang hanya menggunakan peraturan anda sendiri untuk melawan anda.
Bayangkan sebuah peti besi bank. Kebanyakan ujian keselamatan memeriksa sama ada pintunya kuat. Ujian logik perniagaan bertanya soalan yang berbeza. Bagaimana jika seseorang memujuk pengawal untuk membukakan pintu untuk mereka?
Peti besi itu berfungsi. Prosesnya pula gagal.
Berikut adalah tiga cara penyerang menyalahgunakan logik perbankan:
Memintas Tempoh Menunggu Bank sering memerlukan tempoh menunggu 24 jam selepas menambah penerima baharu. Ini bertujuan menghalang kecurian pantas. Penyerang mungkin menemui titik akhir (endpoint) API yang melangkau semakan ini. Mereka memintas sekatan UI dan memindahkan wang dengan serta-merta.
Memecah Had Transaksi Bank mungkin menetapkan had harian sebanyak 50,000. Jika kod hanya menyemak setiap transaksi secara individu, penyerang boleh menghantar lima pemindahan sebanyak 49,000. Setiap transaksi kelihatan sah. Jumlah keseluruhan melebihi had, tetapi sistem terlepas pandang.
Penyalahgunaan Ganjaran Banyak aplikasi memberikan pulangan tunai (cashback) untuk pembayaran bil. Penyerang mungkin membayar bil dan kemudian membatalkannya dengan segera. Jika sistem tidak menarik balik ganjaran tersebut, penyerang akan mencipta satu kitaran untuk mengumpul pulangan tunai tanpa henti.
Mengapa pengimbas automatik terlepas pandang perkara ini?
Pengimbas mencari kelemahan teknikal seperti perisian hasad (malware) atau suntikan (injection). Pengimbas melihat pemindahan yang berjaya dan mengembalikan status 200 OK. Ia menganggap semuanya baik-baik sahaja.
Penguji manusia bertanya: Patutkah pemindahan ini berlaku pun?
Untuk mencari kelemahan ini, berhenti bertanya sama ada sesuatu ciri boleh digodam. Mula bertanya sama ada sesuatu ciri boleh disalahgunakan.
Semak kawasan ini:
- Bolehkah pengguna melangkau langkah pengesahan?
- Bolehkah pengguna menukar pemilikan sesuatu ID?
- Bolehkah tempoh menunggu dipintas melalui API?
- Adakah had dikuatkuasakan pada jumlah keseluruhan atau hanya bagi setiap klik?
- Bolehkah ganjaran dicetuskan berkali-kali?
Pasukan keselamatan elit tidak hanya mencipta kes penggunaan (use cases). Mereka mencipta kes penyalahgunaan (abuse cases).
Daripada menguji "Pengguna memindahkan wang," uji "Penyerang cuba melakukan 500 pemindahan kecil untuk memintas had."
Soalan kedua akan menemui risiko sebenar.
Sumber: https://dev.to/arashad_dodhiya_0e4bdba5a/business-logic-attacks-explained-using-a-banking-app-27hj