"User are Evil"; SQL Injection berlanjut
Posted by y3dips on November 16 2007 00:00:54
SQL injection bahkan sempat dibahas oleh kevin mitnick dalam buku art of intrusion miliknya dan terlepas dari kontroversi "Query" yang dia gunakan, hal ini membuktikan bahwa SQL injection merupakan salah satu jenis serangan yang sangat-sangat amat lawas. K-159 yang sangat aktif melakukan research baik secara online (production web) atau offline terhadap berbagai CMS opensource yang beredar di internet pun hampir setiap hari menemukan celah SQL injection di beberapa aplikasi yang dia research.
Extended News
SQL injection sangat awal sekali dibahas pada echo|zine issue 2 oleh the_day 4 tahun yang lalu, sedangkan jenis serangan yang lebih terkenal dengan sebutan SQL injection ini sudah lebih lama lagi dikenal, di saat berbagai aplikasi sudah mulai mempergunakan jasa database untuk menyimpan dan mengolah data, di saat para programmer memanfaatkannya dan mencoba untuk membuat aplikasinya bekerja dengan baik menggunakan database, maka di waktu yang sama para hacker mengharapkan hasil sebaliknya, mereka berusaha mendapatkan hasil yang sama sekali berbeda dengan memanfaatkan "fasilitas" yang disediakan oleh para programmer.

SQL injection bahkan sempat dibahas oleh kevin mitnick dalam buku art of intrusion miliknya dan terlepas dari kontroversi "Query" yang dia gunakan dalam melakukan "injection", hal ini membuktikan bahwa SQL injection merupakan salah satu jenis serangan yang sangat-sangat amat lawas. K-159 yang sangat aktif melakukan riset baik secara online (production web) atau offline terhadap berbagai CMS opensource yang beredar di internet pun hampir setiap hari menemukan celah SQL injection di beberapa aplikasi yang dia research.

Banyak sekali kasus pengambil alihan suatu server atau hanya sekedar pergantian tampilan dari suatu halaman situs akibat SQL injection seharusnya merupakan suatu hal yang tidak masuk akal, mengingat jenis serangan ini sudah terpublikasi cukup lama. Banyaknya dokumentasi tentang bagaimana serangan ini terjadi dan bagaimana mengamankanya pun bertebaran gratis di internet, ditambah lagi dukungan konfigurasi untuk menambah keamanan dari server database, seharusnya dapat semakin mengurangi celah dari suatu aplikasi yang di ciptakan para programmer tersebut di dalam aplikasinya.

Tak ada yang salah dengan pola pikir para programmer yang sebisa mungkin memberikan kemudahan kepada user, karena "kemungkinan" itulah misi mereka (membahagiakan user? ), yang salah adalah pemberian porsi yang sangat sedikit sekali pada segi keamanan pada aplikasi (secure programming). Pada sebuah diskusi internal melalui mailing list, seorang staff sempat memberikan pendapat yang sedikit berkaitan dengan hal ini, dia mengatakan "bahwa dalam daur hidup suatu aplikasi itu harus dimasukkan siklus audit aplikasi, hal ini harus dilakukan sebelum apikasi tersebut digunakan untuk produksi", jadi?.(apakah beo berhenti mengulangi?)

Bagaimana pula dengan aplikasi rumahan atau bahkan aplikasi yang dibuat secara "single fighter" yang di rilis karena bosan dengan banyaknya sinetron di televisi lalu kemudian di publish ke umum (sourceforge)?, maka seharusnya para "bug hunter" cukup layak untuk dijadikan teman yang secara gratis meng-audit aplikasi mereka, meskipun terkadang berlebihan. Bahkan RFP (RainForrestPuppy) yang sangat terkenal dengan whisker libwhisker-nya mengeluarkan RFPolicy yang merupakan petunjuk bagi para peneliti dengan pembuat aplikasi (developer/maintener) dalam berinteraksi pada proses "free audit" yang nantinya kan memberikan pelajaran pada kedua belah pihak.

Di tahun 2007 ini bahkan Robert Hansen yang lebih dikenal dengan RSnake juga telah merilis RSPolicy yang di tujukan untuk Web Application Security Responsible Disclousure, RSnake memutuskan untuk merilis ini karena maraknya celah yang di temukan pada web aplikasi dan tidak adanya "guideline" yang pasti tentang apa yang harus dilakukan oleh kedua belah pihak, dan di versi yang pertama ini dia menjadikan OWASP TOP 10 sebagai basis dari RSPolicy, dan kesemuanya memberikan "timeline = 0 weeks"

Kedua policy yang di rilis secara independen tersebut merupakan salah satu upaya dalam hal responsible disclosure, tetapi dikarenakan banyaknya para researcher/pentester/bughunter yang "harus" melakukan ujicoba pada aplikasi web yang beroperasi (live/production state), sehingga membuat mereka tidak mau mengungkap jati diri sesungguhnya (dikarenakan permasalahan hukum dsb), yang akhirnya membuat mereka sangat malas untuk berhubungan dengan pihak pengembang (vendor/developer).

Kembali ke masalah SQL injection tadi, ada baiknya para programmer mulai lebih menempatkan user sebagai "potential attacker", karena semakin berkuasa seorang user maka semakin berbahayalah ia, dan membiarkan apa yang di inputkan oleh user diterima mentah-mentah oleh aplikasi yang di buat adalah suatu kesalahan. User adalah sekaligus "evil" bagi aplikasi yang dibuat, pastikan apa yang dimasukkan user adalah yang benar-benar dibutuhkan oleh aplikasi dan musnahkan semua "bantuan" anda dalam melakukan "debuging" (Seperti menampilkan error, dsb) apabila sudah memasuki tahap produksi.

Berikut adaah beberapa Cheat Sheet dalam melakukan Database injection, karena saya cukup bosan menampilkan referensi bagaimana dasar-dasar serangan SQL injection dan bagaimana mengamankan aplikasi anda dari serangan ini, maka silahkan menikmati:

1. The Hacker Webzine mySQL Injection cheat sheet
2. Ferruh mavituna *SQL/oracle injection Cheat Sheet
3. RSnake SQL Injection cheat sheet (Esp: for filter evasion)
4. MS Access SQL Injection Cheat Sheet.

Baiklah, sekarang jika anda adalah seorang programmer maka anda bisa mulai merubah sudut pandang, dan jika anda seorang user, maka anda tahu apa yang dapat anda lakukan ;).
Stupidity Continues :)