Hari ini kami memutuskan untuk membahas topik keamanan informasi. Kami menerbitkan terjemahan artikel Kunal pandey, mendeteksi kerentanan, dan bekerja lebih cepat!
pengantar
Pencurian data pribadi (PII) pengguna sudah menjadi hal yang lumrah bagi kami. Penyerang menemukan banyak cara untuk mendapatkan data pribadi, misalnya, menggunakan kerentanan XSS dan IDOR, pengungkapan titik akhir API, dan banyak lagi.
Skenario yang dijelaskan dalam artikel ini dapat diuji hanya dengan mengamati perilaku titik akhir API. Pada contoh di bawah, dengan memanggil API, informasi pribadi setiap pengguna dapat disimpan di titik akhir API lainnya.
Penjelasan
Di salah satu program privat di platform HackerOne Bug Bounty , di mana saya diundang, diusulkan untuk menguji portal toko, yaitu bagian untuk pekerjaan penjual. Di sini, karyawan toko dapat mengirim undangan "Buat pesanan" kepada setiap pelanggan. Untuk mendapatkan informasi yang dibutuhkan, penjual mengirimkan permintaan ini ke pelanggan melalui email atau menggunakan kode QR.
Setelah menerima link dengan undangan untuk melakukan pembayaran, pembeli membuka: payment-na.examle.com/0811ebf4-d7d0-ba31-9ce68648a5a9 dan mengisi data yang diperlukan.
Saat permintaan dicegat, Burp Suite menemukan titik akhir API POST yang berisi data yang dimasukkan.
Permintaan
POST /na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 HTTP/1.1
Host: payments-na.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json;charset=utf-8
X-Cdc-Client: 2.15.45
Content-Length: 125
Origin: https://payments-na.example.com
DNT: 1
Connection: close
Referer: https://payments-na.example.com
{"browser_prefilled":[],"customer_details":{"country":"US"..............},"skipped_fields":[],"user_submitted":true,"action":"continueAddressUnverified"}
Menjawab
Setelah mengisi formulir, operasi selesai. Selesai!
Selama metode POST ke payments-na.example.com/na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 semua informasi disimpan, pembayaran telah dilakukan.
Tahap operasi
Pengguna atau penyerang dapat menemukan bagian lain dari portal tempat mereka dapat menggunakan fungsi "Lakukan Pemesanan", seperti metode yang dijelaskan di atas, dan menerima tautan berikut untuk pembayaran: pembayaran-na.examle.com/fa5daba4-5d50-8f80 –9eb1-ebia3ea6d665 .
Dalam hal ini, cukup isi formulir, hentikan permintaan di Burp Suite, terima permintaan POST ke payment-na.example.com/na/customer/client/v1/session/xxxx , unduh titik akhir API yang dibuat dan buang permintaan lain ke kami tidak mengirim mereka.
Titik akhir API yang diterima: payment-na.example.com/na/customer/client/v1/session/96afd42f-4281-4529-9b8c-3ba70b0f000b .
Untuk pengujian lebih lanjut, titik akhir ini juga dapat digunakan menggunakan metode GET di browser. Di bawah ini adalah tangkapan layar dari titik akhir API yang dihasilkan:
Seperti yang kita lihat, belum ada informasi yang ditambahkan dan tidak ada parameter yang ditentukan.
Kami sekarang akan mengambil tautan API ini dan mengirimkannya ke pengguna lain yang telah mengisi detail pesanan mereka. Segera setelah korban mengklik tautan API ini, semua data pribadi dari kiriman sebelumnya yang disimpan di sini ( / na / customer / client / v1 / session / 002420e4-e031-47aa-8d94-6f7c40c248c7 ) akan disalin ke endpoint yang ditentukan API: / na / customer / client / v1 / session / 96afd42f-4281-4529-9b8c-3ba70b0f000b .
Setelah korban mengklik tautan API yang kami kirimkan kepada Anda, semua data pribadi pengguna akan disalin ke titik akhir ini.
Dari sisi korban:
Penyerang cukup mengunjungi endpoint API ini dalam mode penyamaran, dan akan ada data korban yang disalin (email, alamat, dll.).
Data pribadi korban:
Dengan cara ini, penyerang dapat memperoleh data pribadi klien mana pun hanya dengan membuat titik akhir API sesi baru dan mengirimkannya ke pengguna lain.
Mengatasi bug
Tim pengembangan portal menghapus metode GET, mengikatnya ke metode POST, dan menambahkan header token otorisasi ke permintaan metode POST di atas, di mana setiap kali akan mengautentikasi dari server.
Ini menghilangkan kemungkinan mengulangi skenario yang dijelaskan di atas - serangan dengan menyalin data pribadi pengguna melalui API.
Poin-poin penting
1. Skenario untuk serangan semacam itu bisa berbeda, contoh saya hanyalah salah satunya. Perhatikan kerentanan ini dan coba gali lebih dalam untuk membuat skenario serupa: bagaimana lagi penyerang bisa menyerang Anda.
2. Dalam contoh yang dijelaskan, API penyerang diautentikasi ke titik akhir API korban karena tidak ada validasi dari header token otorisasi. Ini memungkinkan server untuk menyalin data pribadi klien ke titik akhir API lain.
Kursus acara:
22 Juli: Saya melaporkan kerentanan ke tim portal.
23 Juli: Laporan ditinjau oleh tim dan tingkat keparahan ditetapkan ke Sedang.
23 Juli: Menerima hadiah $ 500.
27 Juli: Masalah terselesaikan, laporan dikompilasi.