- Daftar
- 4 Oct 1988
- Post
- ★
- Like diterima
- 9.157
Berdasarkan atas pertanyaan suhu @Yuiyu1929 via DM ke ane tentang :
Saya coba sedikit memberikan pencerahan tentang client side desync, untuk nosql injectiom dan web cache Miss configuration mungkin lain waktu sebab saya lebih cenderung sering bermain ke CSD .
Menyerang / attack itu kelompok dan satu kelompok bisa terdiri dari lebih 20 orang dengan masing2 tugasnya tergantung dari ilmu yang di kuasai .tugas dibagi 4/5 tergantung tujuan :
1 menentukan sisi target yang paling lemah.
2 pentesting dan eksploitasi
3 mempertahankan akses dan merumuskan laporan patch.
4 menghapus log .
Serangan desync ada 2 :
1 serangan desync sisi client / penyelundupan permintaan sisi server.
2 serangan desync dengan berbasis jeda /
Dari kedua teknik itu tujuannya sama yaitu mendapatkan Request smuggling vulnerabilities.
Catatan :
Urutan serangan :
1 . Langkah pertama dalam pengujian kerentanan desync sisi klien adalah mengidentifikasi atau menyusun permintaan yang menyebabkan server mengabaikan Content-Length.
Pengamatan :
2 Anda mungkin dapat memperoleh perilaku ini dengan memicu kesalahan server. Dalam hal ini, ingatlah bahwa Anda masih memerlukan permintaan agar browser mengirim domain silang. Dalam praktiknya, ini berarti Anda hanya dapat merusak URL, bodi, ditambah beberapa peluang dan tujuan seperti Referer header dan bagian terakhir dari Content-Type.
Catatan
Lakukan ini :
Cara kerja :
Tentukan post -> mode: 'no-cors' ( agar ID koneksi dari setiap permintaan terlihat pada Jaringan tab) -> credentials: 'include' (sebab kita memerlukan cookies untuk eksploitasi)
****
ubah permintaan tindak lanjut menjadi permintaan langsung untuk file JavaScript target.
5 . Terakhir manipulasi header HTTP dengan cara yang hanya mungkin menggunakan alat seperti Burp Repeater.
salam
Saya coba sedikit memberikan pencerahan tentang client side desync, untuk nosql injectiom dan web cache Miss configuration mungkin lain waktu sebab saya lebih cenderung sering bermain ke CSD .
Menyerang / attack itu kelompok dan satu kelompok bisa terdiri dari lebih 20 orang dengan masing2 tugasnya tergantung dari ilmu yang di kuasai .tugas dibagi 4/5 tergantung tujuan :
1 menentukan sisi target yang paling lemah.
2 pentesting dan eksploitasi
3 mempertahankan akses dan merumuskan laporan patch.
4 menghapus log .
Serangan desync ada 2 :
1 serangan desync sisi client / penyelundupan permintaan sisi server.
2 serangan desync dengan berbasis jeda /
Dari kedua teknik itu tujuannya sama yaitu mendapatkan Request smuggling vulnerabilities.
Catatan :
Agar serangan ini berhasil, penting untuk dicatat bahwa server web target tidak boleh mendukung HTTP / 2. Desyncs sisi klien bergantung pada penggunaan kembali koneksi HTTP / 1.1, dan browser umumnya menyukai HTTP / 2 jika tersedia. Satu pengecualian untuk aturan ini adalah jika Anda mencurigai bahwa korban yang Anda tuju akan mengakses situs melalui proxy forward yang hanya mendukung HTTP / 1.1. |
Urutan serangan :
1 . Langkah pertama dalam pengujian kerentanan desync sisi klien adalah mengidentifikasi atau menyusun permintaan yang menyebabkan server mengabaikan Content-Length.
Pengamatan :
- Jika permintaan hanya hang atau time out, ini menunjukkan bahwa server sedang menunggu byte yang tersisa dijanjikan oleh header.
- Jika Anda mendapatkan respons langsung, Anda berpotensi menemukan vektor CSD. Ini membutuhkan penyelidikan lebih lanjut
2 Anda mungkin dapat memperoleh perilaku ini dengan memicu kesalahan server. Dalam hal ini, ingatlah bahwa Anda masih memerlukan permintaan agar browser mengirim domain silang. Dalam praktiknya, ini berarti Anda hanya dapat merusak URL, bodi, ditambah beberapa peluang dan tujuan seperti Referer header dan bagian terakhir dari Content-Type.
Catatan
|
Lakukan ini :
- Pergi ke situs dari mana Anda berencana untuk meluncurkan serangan terhadap korban. Ini harus pada domain yang berbeda dengan situs yang rentan dan diakses melalui HTTPS. Anda dapat menggunakan server exploit yang disediakan.
- Buka alat pengembang browser dan pergi ke Jaringan tab.
- Lakukan penyesuaian berikut:
- Pilih Pertahankan log pilihan.
- Klik kanan pada tajuk dan aktifkan ID koneksi kolom.
- Ini memastikan bahwa setiap permintaan yang dikirim browser dicatat pada Jaringan tab, bersama dengan detail koneksi mana yang digunakan. Ini dapat membantu memecahkan masalah nanti.
- Beralih ke Konsol tab dan gunakan fetch() untuk mereplikasi probe desync yang Anda uji di Burp. Kode harus terlihat seperti ini:
Code:
fetch('https://vulnerable-website.com/vulnerable-endpoint', {
method: 'POST',
body: 'GET /hopefully404 HTTP/1.1\r\nFoo: x', // malicious prefix
mode: 'no-cors', // ensures the connection ID is visible on the Network tab
credentials: 'include' // poisons the "with-cookies" connection pool
}).then(() => {
location = 'https://vulnerable-website.com/' // uses the poisoned connection
})
Cara kerja :
Tentukan post -> mode: 'no-cors' ( agar ID koneksi dari setiap permintaan terlihat pada Jaringan tab) -> credentials: 'include' (sebab kita memerlukan cookies untuk eksploitasi)
****
ubah permintaan tindak lanjut menjadi permintaan langsung untuk file JavaScript target.
Code:
<script>
fetch('https://vulnerable-website.com/desync-vector', {
method: 'POST',
body: 'GET /redirect-me HTTP/1.1\r\nFoo: x',
credentials: 'include',
mode: 'no-cors'
}).then(() => {
location = 'https://vulnerable-website.com/resources/target.js'
})
</script>
5 . Terakhir manipulasi header HTTP dengan cara yang hanya mungkin menggunakan alat seperti Burp Repeater.
salam
Terakhir diubah: