Setelah
artikel pertama saya diterbitkan pada codeby, yang masuk dalam 3 publikasi terbaik dalam seminggu, saya sangat termotivasi untuk menulis yang berikutnya. Tapi kelas 11 memberlakukan pembatasan waktu luang untuk mempersiapkan ujian dan olimpiade. Oleh karena itu, saya menulis yang kedua hanya setelah beberapa bulan setelah
terbang keluar dari semua Olimpiade .
Publikasi ini akan berbicara tentang kasus menarik ketika kerentanan ditemukan pada satu sumber daya memerlukan rantai untuk menemukan mereka di beberapa situs lain.
Awal
Semuanya dimulai dengan memeriksa situs salah satu produsen utama produk palsu. Akun pribadi pengguna tidak ada di sana, dan area pencarian kerentanan tidak terlalu luas.
Saat menguji formulir pengiriman pesanan, sejumlah kerentanan ditemukan di dalamnya.
Pertama, ini adalah XSS tersimpan yang cukup standar dalam data pembeli, dengan mana kusut ini membentang. XSS adalah standar, dan tidak adanya bendera "httponly" pada cookie jelas bukan standar. Berkali-kali saya menerima cookie dari berbagai situs, tetapi saya tidak pernah menerima otorisasi, dan saya mulai ragu bahwa di alam ada situs yang tidak menggunakan bendera "httponly", karena penggunaannya secara signifikan mengurangi risiko serangan XSS. Jauh lebih mengejutkan untuk bertemu dengan acara semacam itu di situs sebuah perusahaan besar. Tetapi, ternyata, layanan yang memungkinkan pengawasan ini jauh lebih besar dari yang saya harapkan. Tetapi lebih lanjut tentang itu setelah.
Saya mengganti cookie yang diterima dan masuk ke akun crm dari sistem situs (saya tidak bisa menahan, untuk pertama kalinya saya sangat beruntung). Hak itu bukan admin, tetapi cukup untuk mengakses statistik tentang pesanan, termasuk dan data pelanggan.
Saya membuat tangkapan layar untuk membuktikan adanya kerentanan dan mengirim laporan. Lebih dari seminggu berlalu dan saya tidak lagi menunggu jawaban. Menurut statistik, jika Anda tidak dijawab dalam tiga hari, Anda bisa melupakannya. Tetapi setelah 8 hari, jawaban yang tidak terduga datang. Dan bahkan lebih, mereka adalah yang pertama membayar saya untuk kerentanan yang ditemukan.
Kembali ke pengujian formulir pengiriman pesanan, saya juga menemukan ada kerentanan iDOR yang memungkinkan Anda untuk mengubah harga pesanan dengan mengedit parameter "json_order [0] [harga]" dan "json_order [0] [total]" dalam permintaan POST domain.ru/shop.php . Substitusi tautan pesanan dalam permintaan yang sama di bidang json_order [0] [href] menyebabkan RFI.
Tidak ada balasan diterima untuk pesan tentang penemuan baru ...
Lanjutan
Di situs CRM itu ternyata sistem tidak ditulis sendiri, tetapi disediakan untuk pembayaran oleh satu layanan terkenal. Setelah kesalahan mereka dengan cookie, logis untuk berasumsi bahwa akan ada kerentanan lain.
Jika skrip yang dikirim oleh saya melalui formulir pesanan berfungsi, maka tidak ada validasi bidang baik di situs yang diinginkan maupun dalam sistem CRM. x2. Oleh karena itu, setelah menerima akun uji coba, saya mulai dengan mencari bidang yang rentan terhadap xss.
Setelah perjalanan panjang melalui sistem CRM yang luas, lebih dari selusin bidang dengan validasi yang tidak memadai diidentifikasi. Di suatu tempat, Anda bisa langsung memasukkan tag skrip, di suatu tempat Anda harus menggunakan skrip in-line dari jenis "onmouseover = alert ()". Selain itu, di beberapa tempat dimungkinkan untuk menyematkan skrip, tetapi di beberapa tempat, saya ingin tahu logika apa yang dipandu oleh mereka, menambahkan penyaringan di beberapa tempat dan tidak di tempat lain? Dari sudut pandang tujuan logis bidang, saya tidak melihat pola. Di beberapa tempat, di mana hampir semua orang tidak akan pergi, semuanya bekerja dengan baik, tetapi, misalnya, mereka tidak repot-repot menambahkan pemfilteran ke nama pihak lawan.
Sebagian besar bidang yang rentan tidak dapat dipengaruhi secara eksternal. Mereka hanya dapat digunakan oleh karyawan untuk meningkatkan hak mereka dalam sistem, yang juga penting.
Di atasnya dengan xss sudah berakhir, itu mungkin untuk melewati hal-hal yang lebih menarik.
Saya belum pernah mencari kerentanan CSRF sebelumnya, situs yang saya uji tidak berada di kelas yang bisa mereka gunakan phising. Oleh karena itu, saya tidak ingin mengganggu diri sendiri atau pemilik situs dengan kerentanan yang tidak akan pernah digunakan untuk melawan mereka. Itu adalah kasus yang sangat berbeda. Sistem CRM ini sangat populer, juga digunakan oleh toko online besar, ditambah ada kemungkinan menghubungkan meja kas titik offline ritel, yang membuat masalah keamanan menjadi lebih penting.
Anehnya, tidak ada perlindungan terhadap CSRF. Itu mungkin untuk mengirim permintaan, cek tidak dilakukan di mana pun.
- Ubah informasi akun? - tolong
- Mengubah nama dan harga barang? - Tidak ada pertanyaan
Pada saat yang sama, cookie berisi sesuatu yang disebut "csrftoken".
Kemudian saya masih berpikir, apa gunanya memasukkan token csrf ke dalam cookie? Googling, saya menemukan bahwa ada cara yang lebih mudah untuk melindungi terhadap csrf dengan token di cookie dan menduplikatnya dalam permintaan posting, di mana Anda tidak perlu menyimpan token di server. Lebih detail di
sini .
Tetapi dalam kasus kami hanya setengah dari pekerjaan yang dilakukan, token ditempatkan di cookie, dan tidak ada dalam permintaan ke server. Dan bahkan lebih, penghapusan lengkapnya dari cookie tidak mengubah apa pun. Mengapa ditambahkan?
Sehubungan dengan csrf yang ditemukan, xss kami, yang sebelumnya tidak dapat diakses dari luar, mendapatkan kehidupan kedua. Lagipula, kita tidak perlu masuk ke akun kita untuk mengedit bidang yang rentan.
Selain itu, melalui subtitusi tipe-pantomim file, dimungkinkan untuk mengunggah file sewenang-wenang ke server. Tetapi server telah dikonfigurasi dengan benar dan skrip php tidak dieksekusi di sana.
Lebih jauh lebih menarik. Semua data tentang barang yang diambil toko online dari crm. Yaitu nama, deskripsi, foto. Tautan ke gambar produk adalah "yyyy.domain.ru/file/get/id=xxx". Agar toko online dapat mengambil gambar, mereka harus memiliki hak baca untuk semua orang. 122.
Setelah memeriksa jalur di mana lainnya, lebih banyak file pribadi disimpan, saya melihat url yang sama. Sepertinya tidak ada yang mengejutkan, mereka mungkin memiliki hak akses lainnya. Tidak lebih rendah dari 022 pasti. Tetapi, kenyataannya ternyata sedikit berbeda, mereka juga memiliki akses gratis untuk pengguna yang tidak sah.
- Sudahkah Anda membuat permintaan untuk mengimpor data pesanan dalam file exel? - Hebat, sekarang semua orang bisa mengunduhnya.
Mungkin ada id yang tampak seperti "yt5bjFb54hb # HJ% $ p" dan tidak menyerah pada kekerasan? Tidak juga. Semua file id memiliki format numerik dan berada dalam kisaran beberapa ribu. Perlindungan terhadap brutus, saya juga tidak perhatikan. Setelah memindai semua id dari 1 hingga 10.000 rintangan tidak memenuhi. Diulang beberapa kali, tidak ada yang tertarik dengan kegiatan seperti itu.
Mereka menjawab laporan saya dalam 3 hari.
Mengenai kurangnya bendera, httponly mengatakan bahwa itu tidak ada "Rupanya lama sekali, karena versi php telah diperbarui." Diaktifkan pada hari yang sama.
Menurut xss mereka mengatakan bahwa semua orang tahu bahwa filter dimatikan pada awal musim panas (pada saat itu sudah Agustus), ini tentu saja tidak menjelaskan mengapa ada penyaringan di suatu tempat, tetapi tidak di suatu tempat, tetapi mari kita berpura-pura bahwa kita tidak melihat ini ketidakkonsistenan. Mereka juga memastikan bahwa filter akan diluncurkan dalam beberapa hari. Bahkan, ternyata dalam beberapa bulan. Tapi, di sini saya mengerti mereka dengan sempurna: Saya juga berencana untuk mulai mempersiapkan ujian dalam beberapa hari ...
Mengunggah file sewenang-wenang ke server tidak terlalu memprihatinkan karena tidak dieksekusi di server, yang berarti tidak ada yang perlu dikhawatirkan. Hanya pada saat menulis artikel saya memiliki ide jika situs yang sudah di hosting selain crm mencoba untuk mengambil gambar dari produk untuk etalase, tetapi menerima skrip php, apakah akan menjalankannya? Atau karena faktanya dimaksudkan untuk tag img, apakah hanya akan diproses sebagai gambar? Atau apakah itu tergantung pada pengaturan server? Harap jawab orang yang berpengetahuan.
Respons terhadap laporan csrf ternyata cukup menarik. Mereka menjawab dengan pertanyaan: "Apa yang Anda anggap sebagai token untuk perlindungan terhadap serangan csrf?" Sungguh, apa yang saya bicarakan?
Mereka mengatakan tentang akses gratis ke file apa pun yang tidak mereka perhitungkan saat ini. Segera ditutup.
Saya harus mengatakan bahwa ini adalah satu-satunya saat ketika saya benar-benar berharap untuk menerima hadiah uang tunai. Situs ini besar, kecuali crm masih belum ada satu proyek berbayar. Majalah online populer. Tapi dia hanya menerima ucapan terima kasih verbal.
Saya harus berterima kasih kepada mereka, saya menjadi lebih tenang tentang masalah pembayaran. Bekerja demi rasa terima kasih dalam bentuk apa pun pada akhirnya tidak akan menghasilkan apa-apa. Anda akan terbiasa dengan segala pujian dan penghargaan lainnya, dan mereka akan berhenti membawa kepuasan. Dan jika Anda melakukan semuanya demi mereka, maka makna melakukan sesuatu akan hilang. Dan Anda tidak dapat kehilangan kesenangan dari proses aktivitas Anda, menyelesaikan masalah baru, menciptakan sesuatu yang baru. Bekerja demi kerja, tidak peduli seberapa basi kedengarannya. Pekerjaan di mana Anda tidak memperhatikan bagaimana jam berlalu, bagaimana matahari berhasil tidak hanya melampaui cakrawala, tetapi untuk bangkit kembali karenanya.
''
Kami puas dengan hal-hal kecil, kebahagiaan bukanlah uang banyak
"Lakukan apa yang Anda sukai" - dihargai di kalangan kami
'' '© Kolya Manyu - Setiap hari
Berakhir
Dalam dukungan teknis dari situs sebelumnya, sistem penerimaan tiket pihak ketiga UserEcho digunakan. Saya tidak gagal memeriksanya. Dalam mimpi, tentu saja, bisa mendapatkan kesempatan untuk membaca tiket pribadi. Secara alami, saya tidak berhasil. Saya harus puas dengan sedikit.
Saat menguji api yang bekerja dengan tiket, awalnya tidak ada anomali yang diperhatikan, hak untuk tidak melihat milik orang lain, tidak berlangganan itu tidak mungkin. Tetapi, setelah mempelajari lebih lanjut situs tersebut, ternyata para pengembang membuat kesalahan kecil.
Di profil, Anda dapat menemukan bagian tentang mengelola tiket Anda, itu menunjukkan orang-orang yang berlangganan atau sebelumnya berlangganan.
Jika kami mengirim permintaan untuk berhenti berlangganan dari tiket orang lain, kami, seperti yang diharapkan, diberitahu bahwa kami tidak memiliki hak untuk tindakan ini. Tetapi pada saat yang sama, itu termasuk dalam daftar tiket kami, sebagai salah satu dari yang kami berlangganan sebelumnya. Dengan demikian, kami mendapatkan kesempatan untuk mengetahui nama dan url format "ticket_name_name_in_translate". Kerugian ini, tentu saja, tidak membawa apa-apa. Dalam kasus yang sangat jarang, adalah mungkin untuk mempelajari sesuatu yang penting dan berharga dari namanya. Tapi itu lebih baik daripada tidak punya apa-apa sama sekali.
Setelah beberapa minggu, bug diperbaiki.
Saya berterima kasih kepada semua orang yang membaca sampai akhir!