Kirim email atas nama perusahaan? Inilah cara saya menemukan kerentanan ini di beberapa perusahaan besar yang memungkinkan saya mendapatkan hadiah dengan mudah.

Halo pemburu . Tujuannya di sini adalah untuk dapat mengirim email atas nama perusahaan — dari alamat emailnya — dengan kemampuan untuk mengubah/menyesuaikan konten dan karenanya template HTML .

Apa dampak dari kerentanan seperti itu?

Dampak dari kerentanan ini bisa sangat signifikan, penyerang akan memanfaatkan kepercayaan yang dimiliki pengguna di platform untuk mengarahkan mereka ke situs penipuan (phishing, dll.) atau bahkan mendorong mereka untuk melakukan tindakan yang tidak diinginkan dari akun mereka. Program umumnya mempertimbangkan tingkat keparahan kerentanan antara rendah dan menengah .

Bagaimana cara kerjanya?

Injeksi HTML adalah kerentanan di mana aplikasi menerima input pengguna dan kemudian menyematkan input tersebut ke dalam HTML. Penyerang dapat menyuntikkan HTML dari input pengguna sehingga kode berbahaya mereka disematkan ke dalam template keseluruhan yang dihasilkan oleh aplikasi.

Ini karena sanitasi input pengguna yang tidak memadai. Ini sangat mudah untuk diperbaiki tetapi sangat sering tidak terdeteksi — vektor serangan ini khususnya — untuk menyenangkan para pemburu bug.

Aturan emas yang terkenal untuk pengembang: Jangan pernah mempercayai input pengguna

Identifikasi berbagai vektor serangan & eksploitasi

Hal pertama yang harus dilakukan untuk mengidentifikasi kerentanan ini adalah menemukan fitur pada aplikasi yang mengirim email : sebagian besar aplikasi memiliki bagian "Hubungi kami", atau bagian "Bantuan" untuk mengirim permintaan ke tim perusahaan. Fitur-fitur ini adalah yang paling mendasar, dan daftarnya tidak lengkap, berbagai fungsi pengiriman email dapat ditemukan tergantung pada sifat aplikasinya.

Setelah fungsionalitas ini ditemukan, mereka harus diuji dan diperiksa keberadaan beberapa kriteria :

Kami akan mengambil contoh formulir yang memungkinkan untuk mengirim permintaan (permintaan bantuan) kepada staf teknis perusahaan

[1] Saat mengirimkan formulir, apakah saya menerima email (ke alamat email yang tertera di formulir atau ke alamat email yang ditautkan ke akun asal pengiriman permintaan)?

Jika tidak — pastikan karena ini bisa memakan waktu — maka Anda tidak perlu mencari lebih jauh. Sebelum berharap untuk menyuntikkan kode ke dalam template, template yang dimaksud harus tetap ada.

[2] Jika saya mendapatkan email saat mengirimkan formulir, apakah mungkin untuk menentukan alamat email apa pun di formulir/permintaan?

Untuk mengeksploitasi kerentanan, perlu untuk dapat menargetkan orang lain sehingga formulir yang dimaksud memungkinkan saya untuk menentukan email pilihan saya, atau perlu terhubung untuk mengirimkan formulir dan oleh karena itu email akan dikirim secara otomatis ke alamat email terikat ke akun yang terhubung :

Dalam hal ini mencegat permintaan di proxy pilihan Anda, dan periksa apakah alamat email Anda tidak ada dalam permintaan HTTP (POST pada prinsipnya), dan coba ubah ke alamat email pilihan Anda.

[3] Apakah beberapa informasi yang diberikan dalam formulir tercermin dalam email yang diterima?

Jika tidak demikian, periksa apakah beberapa informasi pribadi Anda — jika Anda terhubung ke akun Anda — tercermin dalam email seperti nama pengguna, nama belakang atau nama depan misalnya.

Dalam hal ini, ubah informasi yang direfleksikan dan coba masukkan payload Anda di sana. Kalaupun informasi yang dimaksud tidak diinterpretasikan di aplikasi, bisa diinterpretasikan di email , ini disebut injeksi urutan kedua , injeksi tidak langsung dilakukan dari input pengguna formulir, tetapi dari informasi yang direkam di tempat lain , pada akun misalnya.

Jika tidak, kami tidak dapat mencoba menyuntikkan kode, atau bahkan melewati filter apa pun.

[4] Langkah terakhir adalah mencoba menyuntikkan kode HTML yang akan diinterpretasikan oleh template yang dimaksud

Seperti yang disebutkan sebelumnya, kerentanan semacam ini sering tidak terdeteksi, dan beberapa aplikasi tidak memiliki filter sisi depan atau belakang dan muatan sederhana termasuk kode HTML sudah cukup :

vul<strong>ne</strong>rable

Terkadang pengembang berfokus pada filter front-end, yang membuat pengiriman formulir yang berisi karakter khusus menjadi tidak mungkin: jangan berhenti di situ , kirimkan formulir dengan nilai acak, mencegat permintaan di proxy Anda dan kemudian memasukkan payload Anda langsung dari proxy. Ini akan meledakkan semua pertahanan di depan, yang terkadang merupakan benteng terakhir menuju karunia. Jika perlindungan juga ada di sisi belakang, jangan menyerah dalam beberapa menit pertama, coba lewati filter, metodologi di sini sama dengan kerentanan XSS.

Kesulitan melewati filter untuk karakter tertentu? Melihat :https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md

Ini adalah tulisan pertama saya, terima kasih telah membaca. Jika Anda memiliki pertanyaan, jangan ragu untuk memberi tahu saya.

Akun Twitter saya :https://twitter.com/blank_cold