Kalau ada penulis yang paling menginspirasi saya, orang tersebut adalah Dee. Bukan hanya tulisannya bagus dan sangat menyenangkan dibaca, Dee mampu membius saya. Membatalkan semua rencana dan janji saya yang telah dibuat untuk satu hari. Hanya untuk membaca karyanya. Berpetualang bersama pikirannya. Tidak ada satupun buku atau tulisannya yang tidak saya selesaikan dalam satu hari. Tulisan-tulisan Dee punya magic tersendiri. Membaca tulisannya membuat saya merasa terhubung dengannya. Kenal dengannya. Bersahabat dengannya. Aneh. Lucu. Hangat.

Saya pertama kali membaca karya Dee melalui bukunya, “Supernova: Ksatria, Puteri dan Bintang Jatuh”. Setelah membaca buku tersebut, saya tidak dapat berhenti. Saya mencari dan kemudian membaca dan membaca karya-karya lainnya dari Dee. Ada sensasi aneh dalam membaca karyanya. Thought provoking. Fun. Dan yang paling menarik, saya benar-benar terlibat dalam petualangannya. Saya ingat Ferre. Perjalanannya. Hidupnya. Sepinya. Pencerahannya. Saya ingat Bodhi. Kebebasannya. Cintanya. Kesedihannya. Bintangnya. Saya ingat Elektra. Keanehannya. Keluguannya.

Tokoh-tokoh dalam kisah Dee selalu unik. Rico de corro. Kugy. Semuanya selalu menarik saya ke dalam perjalanan, sebuah perjalanan yang merubah saya. Memabukkan, seperti ekstasi. Tulisan Dee membawa perubahan, dan penyegaran. It never failed to make me think – and rethink. Awalnya, saya ingin menuliskan review untuk mandre. Tetapi benar-benar tidak ada kata-kata yang dapat saya gunakan untuk mendeskripsikannya. Terdapat tulisan-tulisan yang sudah pernah saya baca entah di mana seperti “Semangkok Acar untuk Cinta dan Tuhan” dan “Menunggu Layang-Layang“. Membaca tulisan ini memberikan sensasi indah: pulang ke rumah. Pulang ke rumah setelah perjalanan panjang. Setelah petualangan yang melelahkan.

Rasa yang belum dapat saya ilustrasikan dengan baik. Rasa yang selalu muncul ketika membaca karya-karyanya. Tulisan Dee tidak pernah kehilangan sihir misterius tersebut. Tidak ada yang dapat saya katakan selain baca dan mabuklah!

Website modern pada umumnya bersifat dinamis: baik pemilik web maupun pengunjung dapat berkontribusi dalam memberikan konten untuk website tersebut. Hal ini tentunya telah membuka berbagai peluang dalam pengembangan web yang menarik, dan seperti peluang-peluang pada umumnya, ia datang dengan membawa beberapa konsekuensi “kecil”. Memperbolehkan pengunjung untuk berkontribusi dalam website berarti satu hal: sistem website yang dibangun harus siap untuk menerima masukan dari pengguna. Tentunya kita tahu bahwa hal ini tidak pernah berarti baik. Masukan data dari pengguna tidak pernah dapat dipercaya. Tidak dipercaya oleh pengembang sistem yang baik, setidaknya.

Website dinamis, yang memungkinkan penambahan konten dari pengunjung, telah membuka berbagai celah keamanan baru. CSRF. XSS. SQL Injection. Dan masih banyak lainnya. Kali ini kita hanya akan membahas bagaimana menangani salah satu jenis XSS. Cross Site Scripting (XSS) merupakan celah keamanan di mana pengguna diperbolehkan untuk mengisikan berbagai kode program client side pada website. Konsekuensinya? Seorang pengguna yang ingin mendapatkan semua cookie milik pengunjung situs anda akan memberikan ucapan selamat kepada anda.  Umumnya, terdapat dua jenis celah keamanan XSS, yaitu:

1. Non-Presistent: Celah keamanan yang memungkinkan pengguna jahat untuk memasukkan kode-kode program langsung ke dalam sistem anda: setiap pengunjung yang membuka website anda akan menjalankan kode program yang dibuat pengguna tersebut.
2. Presistent: Celah keamanan di mana memungkinkan pengguna jahat untuk menjalankan kode dari doman (website) lain ketika pengguna mengakses situs anda melalui link yang diberikan oleh pengguna jahat.

Pembahasan kali ini hanya akan mengupas XSS Non-Presistent.

Mengapa bisa terjadi XSS Non-Presistent?

Karena pengembang website memperbolehkan pengunjung menuliskan apa saja di dalam websitenya. “Apa saja” yang saya maksudkan bukan “apa saja” dalam artian topik tulisan, melainkan teks aktual dari tulisan pengunjung. Misalkan untuk kotak komentar dalam blog ini. Pengembang sistem yang optimis akan membayangkan bahwa isi komentar dari pengunjung selalu berupa teks, misalnya:

Wah penulis blog ini benar-benar ganteng. Saya terpesona melihat tulisan dan wajahnya.

Dan berbagai tulisan yang serupa, tanpa ada pengunjung yang mengerti HTML. Sehingga ketika muncul satu pengunjung dari Mars yang mengerti HTML dan menuliskan komentar seperti:

Wah, blog ini bagus sekali.

<script type="text/javascript">

// berbagai kode dari mars untuk mencuri cookie pengguna **sensor, red**

</script>

Boom. Mendadak seluruh pengunjung yang melihat blog ini berhasil dicuri cookie-nya oleh pengunjung dari Mars. Memungkinkan pengunjung untuk menulis di dalam website anda adalah sebuah ide yang bagus: komunikasi akan terbangun, dan pengunjung anda akan berkontribusi memberikan berbagai informasi yang terlewatkan oleh anda sewaktu menulis. Tetapi anda harus ingat, cepat atau lambat pasti akan ada pengunjung yang memanfaatkan kebebasan mereka dengan cara yang salah.

Jadi, Bagaimana Menanganinya?

Secara umum terdapat tiga cara untuk menangani tulisan yang dibuat oleh pengunjung, yaitu:

1. Tidak memperbolehkan semua tag HTML. Setiap < akan diubah menjadi kode “&lt” sehingga dianggap sebagai teks oleh browser.
2. Black list: dengan tidak memperbolehkan tag tertentu untuk masuk, misalnya memanfaatkan regular expression untuk membuang tag <script> dari pengguna.
3. White list: dengan memperbolehkan hanya tag tertentu saja dari tulisan yang diberikan pengguna.

Cara pertama akan memastikan anda aman dari serangan XSS Non-Presistent, tetapi konten yang diberikan oleh pengunjung anda akan menjadi kurang menarik. Tanpa adanya tag HTML, pengguna tidak dapat membuat tulisannya menjadi tebal untuk penekanan, maupun miring untuk istilah asing. Pengunjung juga tidak dapat membuat tabel, poin-poin tulisan, dan banyak hal lain. Jika memang tidak ingin hal-hal yang disebutkan sebelumnya, pilhan pertama adalah cara mudah dan cepat untuk menghindari XSS. Tetapi jika ingin memberikan sedikit kebebasan kepada pengguna, anda akan hanya memiliki dua pilihan: white list atau black list.

White list akan selalu lebih baik dibandingkan black list. Dengan memberikan black list, pengguna jahat akan selalu menemukan cara untuk melewati black list tersebut, seperti kita akan terus menemukan celah-celah dalam berbagai peraturan. Sesuatu yang bersifat melarang hanya pada kondisi tertentu sangat rentan oleh berbagai kelemahan dalam larangan tersebut. Hal ini menjadi lebih parah beberapa kali lipat dalam hal sistem komputer, karena komputer sangat baik dalam melakukan automasi: seorang perantas dapat membuat program otomatis untuk mencoba berbagai variasi input sampai sistem anda jebol.

Dengan white list, di lain pihak, hal tersebut tidak akan dapat dilakukan. Ketika membuat white list, anda memastikan bahwa tidak ada tag, atau pengguna, atau wanita, atau mobil yang dapat masuk ke tempat terlarang selain hal-hal yang telah anda perbolehkan masuk. Segala hal selain yang anda izinkan tidak boleh masuk. Karena daftar hal-hal yang anda izinkan sangat terbatas, maintenance dari hal-hal tersebut akan menjadi sangat mudah. Tag yang umumnya diperbolehkan yaitu:

address, a, abbr, acronym, area, b, big, blockquote, br, caption, cite,

class, code, col, del, dd, div, dl, dt, em, font, h1, h2, h3, h4, h5,

h6, hr, i, img, ins, kbd, li, map, ol, p, pre, q, s, span, strike,

strong, sub, sup, table, tbody, td, tfoot, tr, tt, ul, var

Kode Program

Cukup teorinya. Kita akan melihat bagaimana membuat fungsi untuk pencegahan XSS, melalui penyegelan seluruh tag HTML maupun white list. Kode program dibuat dalam PHP, karena PHP merupakan bahasa yang sangat populer dalam pengembangan web.

Larangan Terhadap Seluruh Tag HTML

Merupakan cara yang sangat mudah. Untuk membuat larangan seluruh tag HTML, gunakan fungsi htmlentities dari PHP:

function sanitizing($kontenPengguna)
{
    return htmlentities($kontenPengguna, ENT_QUOTES);
}

White List

Melakukan white list tag HTML adalah hal yang cukup sulit dilakukan. Meskipun PHP telah menyediakan fungsi strip_tags untuk hal tersebut. Sebagai bahasa paling populer untuk membangun web, PHP pastinya telah mengetahui kebutuhan para pengembangnya. Berikut adalah contoh pengunaan fungsi strip_tags:

function string_safe_output($text)
{
    // tag yang diperbolehkan.
    $tags = '<b><u><i><ul><ol><li><p><span>';
    return strip_tags($text, $tags);
}

Tetapi perlu diingat bahwa fungsi strip_tags tetap masih memiliki celah keamanan: atribut HTML tidak dihilangkan, sehingga pengguna yang ingin melakukan serangan tetap dapat melakukannya dengan memasukkan atribut pada tag legal. Misalnya, pada kode di atas pengguna dapat menuliskan:

<p onhover="javascript:cookieSteal()">Bla bla bla</p>

Karenanya, jangan pernah gunakan hanya fungsi strip_tags untuk melawan XSS. Berbagai validasi dalam DOM harus dilakukan untuk mendapatkan hasil output HTML yang benar-benar aman dari serangan. Karena kompleksitas kode yang sangat tinggi, sangat disarankan untuk menggunakan library atau framework yang telah teruji dengan baik seperti HTML Purifier.

Pengunaan HTML Purifier menyederhanakan pengamanan, yang awalnya membutuhkan ratusan baris menjadi hanya beberapa baris (tidak menghitung autoloader dan konfigurasi):

function string_safe_output($text)
{
    $HTMLPuirifier = new HTMLPurifier();
    $clean_html = $purifier->purify($text);
    return $clean_html;
}

Dan dalam sekejap, kode anda telah aman sepenuhnya dari XSS Non-Presistent. Selanjutnya kita akan membahas mengenai penanganan XSS Presistent. Tetapi tentunya, anda dapat mencoba berkesperimen dengan berbagai cara menangani XSS Non-Presistent. Have a fun coding season!

Bacaan lanjutan:

• http://web.mit.edu/Saltzer/www/publications/protection/
• http://htmlpurifier.org/docs

Because most of the time when I’m coding, I use what people call Rubber Duck Debugging, and I’m addicted to it, so I can’t code well when I’m not doing it. So what is this rubber duck debugging? It’s a technique where we do debugging while eating a rubber duck. *AHEM* Okay, seriously. It’s a technique of debugging where while debugging, a programmer read the code, line by line, aloud, to something. And because a great software developer loves rubber duck, that “something” is a rubber duck. Hence, the name.

What’s so special in rubber duck debugging, aside from it makes people think you’re a freak? It forces you to think, to explain your code line by line to the duck, because you know if you’re doing something wrong – some silly, deadly, sinful code – the duck will turn into a raptor and eats you. I don’t use a rubber duck by the way, I use a pencil, a pen, or whatever item within my reach. It’s a great way to debug, and it helps me more that Visual Studio or Eclipse ever did. I’ve done programming this way since I’m a kid and I’m also forced to do it when teaching, so I can’t just leave the habit. But it’s a great alternative way to debug when your IDE can’t help you. Trust me.

Another reason why I’m not so good when people surrounds me is I can’t get my mind to work when I’m not in trance. More on that in the next post. Meanwhile, happy debugging