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: <script>alert(0)</script>
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: <script> alert (0) </ script> 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 <adalah yang paling umum digunakan html karakter yang digunakan dalam Cross Site Scripting. Namun, jika kita ingin
menjadi benar-benar teliti maka kita dapat juga menambahkan )(][}{% ke string yang kita gunakan untuk fuzzsitus target.
Alasan mengapa tidak ada dua "atau 'adalah karena hal ini dapat memicu WAF, IPS atau apa pun berjaga-jagasitus
mungkin telah mencoba untuk melaksanakan terhadap XSS bukan menggunakan skema pengkodean yang aman / rencana / siklus pengembangan.
Alasan mengapa semua karakter yang ditulis sebagai> <bukan <> adalah karena ini adalah bypass umum terhadap XSS-filter!
Dengan pemikiran, kita menggunakan string berikut: "haxxor '/ \> <untuk fuzz medan pencarian:
Mari kita melihat kembali HTML-code:
PHP Code:
...
<input type="text" name="search" value=""haxxor'/\><" /> <br /> You searched for \"haxxor\'/\\>< which returned no results.
... ditambahkan garis miring yang tidak apa-apa dalam kasus ini. Pada dasarnya kita dapat melewati ini dengan mudah dengan: "> <script> alert (0) </ script>
Jika kita akan menampilkan eksternal javascript kita harus menghindari penggunaan "dan" tentu saja.
Terakhir kita XSS-url dapat: http://yetanothersite.tld/search.php?query = "> <script> alert (0) </ script> jika GET-variabel yang digunakan.
[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:
...
<input type="text" name="search" value=""haxxor'/\><"> You searched for ""haxxor'/\><" which returned no results.
... (further down)
<script>
...
s.prop1="prettysecure";
s.prop2="\"haxxor%39/\%3E%3C";
s.prop3="adspace";
...
</script> ditambahkan garis miring yang tidak apa-apa dalam kasus ini. Pada dasarnya kita dapat melewati ini dengan mudah dengan: "> <script> alert (0) </ script>
Jika kita akan menampilkan eksternal javascript kita harus menghindari penggunaan "dan" tentu saja.
Terakhir kita XSS-url dapat: http://yetanothersite.tld/search.php?query = "> <script> alert (0) </ script> jika GET-variabel yang digunakan.
[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)
}
... Contoh URL serangan bisa terlihat seperti: http://testz.tld/index.php?view_profile=1&name = <script> alert (0) </ script>
[KERAS] Contoh Kasus - B:
File berikut (search.php) memiliki beberapa kode yang menarik:
PHP Code:
...
if($_GET['set_flag']==1) {
$var = "checked";
}
echo "<input type='radio' value='flag' checked='" .htmlentities($var). "' />";
... 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 <input> 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;'
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: <input type='radio' value='flag' checked='$var' />
Di dalam nilai memeriksa variabel kami ($ var) dikodekan, tetapi hanya "> dan <yang disandikan, bukan 'karena ENT_QUOTES
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.
Sebuah contoh dapat XSSR: http://somesite.tld/redirect.php?link=data:text/html, <script> alert (0) </ script>
Dan jika skema URI Javascript digunakan: http://somesite.tld/redirect.php?link=javascript:alert (0);
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:
<input type="hidden" name="anti-csrf" value="random token value" />
Referensi :
[1] http://ha.ckers.org/xss.html
[2] http://en.wikipedia.org/wiki/Cross-site_scripting
[3] http://firecat.intern0t.net/
[0] http://deadhackers.eu/boards/viewtopic.php?f=9&t=22
0 komentar:
Post a Comment