Jumlah posting : 201 Join date : 19.10.10 Age : 33 Lokasi : Padang
Subyek: Joomla component cinema SQL injection Vulnerability Mon Oct 25, 2010 4:33 am
___ -:: Pendahuluan:: - ____________ Apa itu XSS dan apa yang mengacu kepada? Alias XSS Cross Site Scripting adalah sisi klien serangan di mana seorang penyerang menciptakan link jahat, script berisi kode yang kemudian dilaksanakan dalam browser korban. Kode script bisa bahasa apapun yang didukung oleh browser, tetapi sebagian besar HTML dan Javascript yang digunakan bersama dengan embedded Flash, Java atau ActiveX.
Apa yang bisa Cross Site Scripting digunakan untuk? Cross Site Scripting dapat digunakan untuk berbagai hal, seperti sesi-pembajakan, browser serangan, phishing, propaganda dan bahkan cacing! Namun masih memerlukan korban untuk mengklik link jahat diciptakan oleh penyerang.
Bagaimana bisa Satu mendapatkan korban untuk mengklik link XSS? Cara termudah untuk membuat orang meng-klik link berbahaya adalah untuk membuat mereka terlihat otentik dan non - jahat. Memberi mereka alasan kemudian adalah rekayasa sosial-bagian yang harus mudah kecuali jika korban sadar serangan tersebut dan / atau memiliki tindakan terhadap Cross Site Scripting, seperti NoScript.
Bagaimana Satu menghindari XSS-links tampak mencurigakan? Hal ini biasanya dilakukan dengan penyandian, layanan url pendek, mengarahkan dan bahkan flash!
Yang tipe Cross Site Scripting yang ada? Jenis yang paling umum adalah GET dan POST berbasis XSS. Namun Cross Site Scripting juga bisa dipicu melalui cookie. Beberapa individu mengklaim bahwa XSS juga dapat dibagi menjadi gigih dan non-persistent tetapi juga jenis-jenis dan harus disebut sebagai injeksi yang berbeda kelas bug / kerentanan.
Apa perbedaan antara GET-POST-XSS? Perbedaannya adalah bahwa ketika GET-variabel yang digunakan adalah mungkin untuk melakukan serangan XSS normal mana penyerang mengirimkan crafted URL jahat kepada korban yang kemudian dijalankan ketika korban membuka link dalam browser.
Dengan variabel POST-penyerang dapat f.ex. menggunakan flash untuk mengirim korban ke POST-XSS situs rentan karena tidak mungkin untuk membuat URL ketika POST-variabel yang sedang digunakan.
Apakah ada sub-kategori dari Cross Site Scripting? Pada saat ada XSSR dan XSSQLI. Orang bisa mengatakan bahwa XSRF / CSRF milik yang sama kategori, namun metode serangan terlalu banyak berbeda dari tradisional Cross Site Scripting. CSSR alias XSSR atau Cross Site Redirection Script digunakan untuk mengarahkan korban kepada halaman lain enggan. Halaman bisa misalnya berisi phishing template, kode serangan browser atau beberapa kasus di mana data atau skema URI javascript digunakan: sesi-pembajakan. XSSQLI adalah campuran Cross Site Scripting dan SQL Injection, di mana korban ketidaktahuan mengklik link berbahaya SQL Injection berisi instruksi untuk suatu daerah di website yang membutuhkan hak istimewa yang tamu atau anggota tidak memiliki. XSRF atau CSRF (kadang-kadang disebut sebagai C-Surf) berdiri untuk Cross Site Request Pemalsuan yang digunakan untuk mengirim masukan dari pihak ke-3 situs ke situs target. XSRF dapat dalam beberapa kasus dipicu hanya dengan melihat gambar yang dirancang khusus tetapi yang paling sering digunakan adalah URL. Dengan Cross Site Request Pemalsuan itu mungkin untuk f.ex. mengubah password korban jika situs target tidak diamankan dengan baik dengan bukti dll
Apa itu XST dan dapat digunakan untuk apa saja? XST juga dikenal sebagai Cross Site (Script) Tracing adalah suatu cara untuk menyalahgunakan HTTP Trace (Debug) protokol. Apa pun yang seorang penyerang mengirimkan ke web-server yang telah diaktifkan akan mengirim TRACE jawaban yang sama kembali. Jika penyerang mengirimkan berikut: Code: TRACE / HTTP/1.0 Host: target.tld Custom-header: alert(0) Maka penyerang akan menerima sama "Custom-header: Namun setelah update browser terbaru tahun berikutnya (s) XST telah semakin sulit untuk DNS dan berfungsi dengan benar.
Bagaimana mungkin menemukan bug XSS dalam website? Ada 2 metode: kode / script audit atau fuzzing yang digambarkan di bawah ini.
Alat macam apa yang diperlukan untuk menemukan bug XSS? (REQ = Required, OPT = Optional) - REQ: Internet Browser (seperti FireFox) dalam kasus Anda fuzzing. - REQ:-penampil teks (seperti notepad) dalam kasus Anda audit. - KPT: Sebuah proxy mencegat dalam kasus yang sedang Anda lakukan lebih maju XSS. (Dalam FireFox adalah mungkin untuk menggunakan Tamper Data). - KPT: Browser Addons, untuk FireFox berikut ini adalah terutama bermanfaat: pembakar, JSView dan LiveHTTP Header.
Apa lagi yang berguna untuk mengetahui apakah Kita ingin menemukan bug XSS? - Browser keterbatasan mengenai Cross Site Scripting [1] - HTTP Headers dan bagaimana protokol HTTP bekerja. - HTML + Javascript dan mungkin tertanam serangan script. (flash dll) - Mencegat proxy (Burp dll), alat diferensial (berbaur, ExamDiff, dll) - Useful browser-addons (lihat FireCat [3]) - Website scanner (Nikto, W3AF, Grendel, Directory-fuzzers dll)
Mana-bug XSS biasanya terletak? Hal ini biasanya terletak di masukan pengguna yang diajukan baik melalui GET atau POST variabel, dimana hal itu tercermin pada situs target sebagai teks di luar tag, tag di dalam nilai-nilai atau dalam javascript. Dapat juga dalam beberapa kasus disampaikan melalui cookie, http header atau dalam kasus-kasus yang jarang upload.
Bagaimana Satu melindungi sebuah situs terhadap XSS? Cara terbaik adalah untuk memastikan bahwa semua pengguna input dan output divalidasi dengan benar. Namun dalam beberapa kasus WAF yang IPS atau juga dapat melindungi terhadap XSS meskipun masih cara terbaik untuk memvalidasi input pengguna-dan-output dengan benar.
___ -:: Menemukan Bug - Dengan Fuzzing:: - ____________ [EASY] Contoh Kasus - A: Kami berada di http://buggysite.tld di mana kita melihat "Cari-lapangan" di kanan atas. Karena kita tidak tahu kode sumber nyata tapi hanya HTML-output dari situs kita harus fuzz apa-apa mana mungkin untuk mengirimkan data. Dalam beberapa kasus, data akan tercermin di situs tersebut dan dalam beberapa kasus wont. Jika tidak kita beralih ke kue berikutnya, header, mendapatkan / post variabel atau apa pun yang kita fuzzing.
Yang paling efektif untuk bulu adalah untuk tidak menulis: alert (0) karena banyak situs yang berbeda pencegahan terhadap Cross Site Scripting. Sebaliknya kita menciptakan string kustom yang dalam banyak kasus wont memicu apa pun yang bisa mengubah output dari kesalahan menjadikan situs atau halaman yang tidak rentan.
Contoh string yang efektif yaitu: "kata kunci '/ \> <
" '/ \> Dan menjadi benar-benar teliti maka kita dapat juga menambahkan )(][}{% ke string yang kita gunakan untuk fuzz situs target.
Alasan mengapa tidak ada dua "atau 'adalah karena hal ini dapat memicu WAF, IPS atau apa pun berjaga-jaga situs mungkin telah mencoba untuk melaksanakan terhadap XSS bukan menggunakan skema pengkodean yang aman / rencana / siklus pengembangan. Alasan mengapa semua karakter yang ditulis sebagai> adalah karena ini adalah bypass umum terhadap XSS-filter!
Dengan pemikiran, kita menggunakan string berikut: "haxxor '/ \> Mari kita melihat kembali HTML-code: PHP Code: ... <" /> You searched for "haxxor'/\\>< which returned no results. ... Dalam kasus ini setelah tag string string disandikan dengan benar, namun di dalam string tag hanya punya beberapa ditambahkan garis miring yang tidak apa-apa dalam kasus ini. Pada dasarnya kita dapat melewati ini dengan mudah dengan: "> alert (0)
Jika kita akan menampilkan eksternal javascript kita harus menghindari penggunaan "dan" tentu saja.
[Ringan] Contoh Kasus - C: Kami berada di http://prettysecure.tld di mana kita menemukan kolom pencarian lain, sudah waktunya untuk mengirimkan string fuzzing kami.
Berikut kode HTML-dikembalikan setelah string diajukan kami: PHP Code: ... <"> You searched for ""haxxor'/><" which returned no results. ... (further down) ... s.prop1="prettysecure"; s.prop2=""haxxor%39/\%3E%3C"; s.prop3="adspace"; ...
Dalam kasus ini setelah tag string string disandikan dengan benar, namun di dalam string tag hanya punya beberapa ditambahkan garis miring yang tidak apa-apa dalam kasus ini. Pada dasarnya kita dapat melewati ini dengan mudah dengan: "> alert (0)
Jika kita akan menampilkan eksternal javascript kita harus menghindari penggunaan "dan" tentu saja.
[Ringan] Contoh Kasus - C: Kami berada di http://prettysecure.tld di mana kita menemukan kolom pencarian lain, sudah waktunya untuk mengirimkan string fuzzing kami.
Berikut kode HTML-dikembalikan setelah string diajukan kami: PHP Code: ... if($_GET['view_profile']==1) { echo $_GET['name']; ... (more code) } ... Dengan melihat kode diatas kita dapat melihat bahwa jika view_profile adalah sama dengan 1 maka skrip akan mencetak "nama" variabel. Contoh URL serangan bisa terlihat seperti: http://testz.tld/index.php?view_profile=1&name = alert (0)
[KERAS] Contoh Kasus - B:
File berikut (search.php) memiliki beberapa kode yang menarik: PHP Code: ... if($_GET['set_flag']==1) { $var = "checked"; } echo ""; ... Ini adalah kerentanan bersyarat di mana dalam php.ini register_globals harus diatur ke Aktif. (Off factory default). Register_globals pada dasarnya memungkinkan seorang individu untuk mengatur variabel dengan cepat, bahkan jika mereka tidak dimaksudkan untuk ditetapkan.
Hal ini hanya berlaku untuk variabel yang TIDAK ditetapkan seperti dalam contoh di atas. Masalah lain yang kami temui htmlentities Namun adalah karena kesalahan coding, kita masih bisa menyalahgunakan tag tanpa membuat yang baru. Kita perlu menggunakan event handler dalam tag dan beberapa CSS (Cascading Style Sheet) untuk memastikan bahwa memicu korban tidak peduli apa eventhandler. Ada beberapa cara untuk melakukan itu, salah satunya adalah: Code: style='display:block;width:99999px;height:99999px;' Sebuah eventhandler yang dapat kita gunakan dalam kasus ini bisa onmouseover, onblur meskipun mungkin lebih baik.
Anda mungkin bertanya pada diri sendiri, mengapa script di atas tidak aman? Karena htmlentities () digunakan dengan cara yang tidak aman, karena bahwa tag terlihat seperti ini dalam bentuk html:
Di dalam nilai memeriksa variabel kami ($ var) dikodekan, tetapi hanya "> dan tidak diatur dalam fungsi htmlentities. Ini berarti bahwa kita dapat melepaskan diri dari checked =''dengan mudah.
Contoh serangan bisa URL: http://was-secure.tld/search.php?test = 'style =' display: block; width: 99999px; height: 99999px; 'onmouseover =' alert (0)
Tidak ada "Contoh Kasus - C" karena saya telah melalui sebagian besar penting Cross Site Scripting.
___ -:: Tambahan Informasi:: - ____________ XSSR Ketika itu adalah mungkin untuk mengirim pengguna ke data atau skema URI javascript baik melalui A) GET atau POST-variabel atau B) Pengguna disampaikan konten seperti link maka berlaku untuk kategori XSSR bug. Namun beberapa individu telah menyatakan bahwa situs yang hanya menerima HTTP atau HTTPS GET-link melalui variabel juga jatuh di bawah kategori XSSR.
Hal ini dalam beberapa kasus telah diketahui bocor cookie dan karena itu digunakan dalam sesi-pembajakan.
XSSQLI Ketika SQL Injection kerentanan ada dalam daerah istimewa situs target, XSSQLI menjadi berguna.
Contoh dapat menipu XSSQLI administrator "shouldbescure.tld" untuk mengklik baik SQL Injection klik link atau Cross Site Scripting link yang berisi panggilan ke SQL Injection di daerah istimewa situs tempat ini bisa menjadi rentan bagian: http://shouldbesecure.tld/admin.php?del=1 DAN 1 = 1 / *
XSRF Juga dikenal sebagai CSRF dan C-Surf dapat digunakan untuk melawan situs yang tidak menggunakan token yang biasanya tersembunyi di dalam tag. Sebuah cara yang umum untuk menggunakan token terhadap C-Surf serangan adalah untuk menyembunyikan mereka di dalam tag seperti: Code:
subma Moderator
Jumlah posting : 141 Join date : 01.11.10 Age : 34 Lokasi : medan
Subyek: Re: Joomla component cinema SQL injection Vulnerability Mon Nov 01, 2010 12:55 am
panjang banget ijin yimak dan di pelajari
tolong sertakan credit atau bypass agar tidak terjadi konflik terhadap forum lain maaf bukan sok ngatur
Calendar
![Admin [B0C4H]](https://2img.net/u/1813/19/11/20/avatars/1-48.jpg)
Subyek: Joomla component cinema SQL injection Vulnerability 
Mon Oct 25, 2010 4:33 am
