Berbagai Serangan Terhadap Aplikasi Web dari Sisi Aplikasi Web

Apa yang dimaksud dengan serangan dari sisi aplikasi web? Tentu saja serangan macam ini tidak diakibatkan oleh kurangnya keamanan dari segi infrastruktur. Beberapa permasalahan yang dapat menjadi peluang diserangnya suatu aplikasi web antara lain:

• Tidak adanya tindakan preventif terhadap suatu jenis serangan
• Kurangnya penggunaan token yang aman saat mengembangkan RESTful API
• Tidak menggunakan SSL certificate
• Tidak mampunya memvalidasi apakah data yang masuk ke suatu aplikasi web dikirimkan dari client-nya atau dari sumber lain yang tidak terpercaya
• dan masih banyak lagi

Ada beberapa jenis serangan yang perlu diperhatikan oleh para backend web developer maupun frontend web developer agar terhindar dari serangan tersebut dengan mengenal karakteristik setiap serangan yagn ditujukan kepada aplikasi web yang dibangun.

SQL Injection

SQL Injection adalah salah satu teknik yang cukup berbahaya. Mengapa demikian? ada beberapa potensi kerusakan yang dapat terjadi karena serangan ini:

• Terungkapnya data sensitif dari suatu user dari aplikasi web atau bahkan informasi lainnya dengan memanfaatkan query join dan query kompleks lainnya
• Membuat database kebanjiran data karena query insert yang ditembakkan ke aplikasi web menjadi faktor pelemah database dari aplikasi web
• Membuat kinerja database menjadi lambat, karena ada banyak query yang dapat memberatkan kinerja datbase dalam jumlah banyak
• Dan masih banyak lagi

Pada dasarnya SQL Injection dilakukan penyerang dengan menembakkan query yang dapat dijalankan di dalam kode aplikasi web tanpa sepengetahuan developer yang terjadi karena kelalaian developer itu sendiri. Biasanya tidak adanya fasilitas validasi dan pemeriksa request body atau form data yang seharusnya tidak boleh berisi sintaks SQL.
Bila developer memiliki awareness terhadap masalah ini, maka kode yang dibuat akan dipersiapkan untuk menangkal nilai yang ternyata bisa diisi dengan sintaks SQL yang berbahaya.

Cross-Site Scripting

Hampir mirip dengan SQL Injection, hanya saja sintaks berbahaya yang dikirimkan ke aplikasi web dapat berupa Javascript dan HTML yang nantinya malah akan di-render di halaman web kita kepada user. Sehinga user berpikir tampilan tersebut berasal dari kita. Potensi kerusakan apa saja yang bakal terjadi?

• Hilangnya kepercayaan dari user karena website menjadi kurang nyaman, misal halaman web menjadi banyak sekali popup yang tampil tapi bukan dari aplikasi web kita
• Data user diambil oleh penyerang karena ada form yang ternyata disimpan oleh orang lain di dalam halaman web kita tanpa disadari
• Kerusakan pada tampilan web yang tidak sesuai dengan spesifikasi

Salah satu hal yang harus diperhatikan oleh developer adalah, memastikan bahwa kode HTML atau Javascript yang disimpan di dalam database memang benar peruntukannya, dan selalu pastikan bahwa tidak ada kode berbahaya yang disimpan di dalam tabel yang tidak semestinya menyimpan kode HTML atau Javascript.

Cross-Site Request Forgery

Permasalahan ini terjadi ketika aplikasi web kita ternyata menerima request dari halaman web atau client yang bukan semestinya. Bisa jadi ada penyerang yang sengaja melihat celah ini untuk beberapa tujuan berikut:

• Membuat isi database menjadi kotor
• Menyisipkan berbagai sintaks berbahaya seperti SQL Injection
• Menyisipkan kode Javascript yang ternyata disimpan di dalam aplikasi web dan menjebak client dari aplikasi web itu sendiri
• Mengacaukan analisis para pengolah data atau manajerial ketika database dari aplikasi web berisi banyak data yang salah

Sebaiknya, baik backend atau frontend developer harus bekerja sama untuk bisa memastikan bahwa halaman web yang dibuat benar - benar akan dikirimkan ke aplikasi backend yang sesuai. Begitupun dengan backend harus memastikan bahwa client yang mengirimkan data benar - benar dari server-nya sendiri.

Cookies Injection

Permasalahan ini terjadi dari sisi client dimana cookies yang kita simpan di web browser milik user dirusak dan dimodifikasi oleh penyerang dan berujung pada misinformasi dan penangkapan data user. Hal ini sangat beresiko untuk keamanan data user yang seharusnya dikirimkan ke aplikasi web kita malah dialihkan ke website si penyerang.

Request Exploitation

Ajax

Kadangkala ada saja developer yang tidak menggunakan token sehingga setiap orang dapat menembak endpoint dari AJAX tersebut dengan data yang mereka sengaja kirimkan. Tentu saja datanya dapat berupa malicious code atau pun data yang tidak semestinya.
Selain itu request body yang terlalu mudah ditebak pun dapat menjadi pemicu serangan, sehingga orang dapat membacanya untuk melakukan reverse engineering, sekalipun penyerangnya adalah user itu sendiri. Seperti yang terjadi pada game Pokemon Go, dimana hacker membuat aplikasi bot dengan memanfaatkan endpoint yang tidak terlindungi dengan baik.
Selain itu exploitation dapat terjadi juga karena aplikasi web tidak menggunakan SSL certificate.

Query Params

Penggunaan query params yang terlalu verbose, dapat membuat penyerang mencoba - coba endpoint yang bekerja dengan menggunakan query params, misal ketika user dapat melihat dokumen miliknya saja. Ternyata malah bisa melihat dokumen milik orang lain dengan mengubah nilai pada query params.
Salah satu mitigasinya yang termudah adalah dengan menerapkan sistem role-based access control dan juga access rule pada user dari aplikasi web.

Penggunaan Web Token yang Beresiko

Saat mengembangkan RESTful API, pastikan bahwa developer harus menggunakan token yang sangat kuat dan tidak mudah dibajak ataupun dirusak oleh penyerang. Berikut ini adalah beberapa potensi serangan yang muncul dari permasalah web token:

• Tidak menggunakan web token, tak sedikit developer yang memanfaatkan fitur AJAX malah tidak menggunakan token untuk kunci saat melakukan request dari client ke server melalui AJAX. Hal ini tentu saja sangat mempermudah penyerang untuk melakukan aksi yang berbahaya. Selalu gunakanlah web token untuk RESTful API kamu!
• Unexpired Token, token yang tidak pernah basi memang menjadi problematika sendiri. Di satu sisi mungkin ada senior developer yang tidak mau direpotkan dengan membuat kode yang memfasilitasi sebuah token untuk menjadi kadaluarsa. Atau juga ada developer yang gengsi menggunakan library penghasil token. Dengan membuat token yang tak pernah basi, tentu saja seseorang dapat melihatnya di masa mendatang dan menggunakannya untuk keperluan jahat. Tentu saja token dapat dilihat dari web browser dengan melihat cookies atau local storage dari aplikasi web.
• Untrusted Token, dengan tidak memberikan salt ataupun tanda bahwa token yang dikirim dan digunakan memang benar - benar dari aplikasi web kita bisa jadi sebuah potensi serangan. Misal ada token abcdef ternyata dari website lain token tersebut abcdef juga, ketika digunakan untuk mengakses aplikasi web kita, ternyata bisa digunakan. Harusnya token dari luar tidak boleh digunakan oleh aplikasi web kita.
• Algoritma Hashing yang lemah, yah gunakanlah algoritma hashing yang terbaik dan terkuat tentu saja lihat apakah bahasa pemrograman yang digunakan mendukung algoritma hashing terbaru atau tidak. Tentu saja baca dahulu paper terkait, seberapa kuat algoritma hashing yang akan digunakan.

Library Javascript yang sudah Kadaluarsa

Library yang kadaluarsa dapat berupa suatu library tapi versi yang digunakannya sudah terlalu jauh dari versi terbaru. Atau memang library yang sudah ditinggalkan lama oleh pembuatnya. Mengapa library Javascript yang sudah kadaluarsa dapat menjadi pintu serangan? Perhatikan beberapa hal berikut:

• Dalam jangka waktu yang lama, para penyerang akan tahu kelemahan library yang sudah kadaluarsa tersebut.
• Dengan tidak memperbaharui versi atau patch dari library yang digunakan maka kita sudah membiarkan para penyerang memasuki bagian rahasia aplikasi web kita dari backdoor ini
• Library yang terbaru saja sering memiliki celah keamanan, sehingga kamu tetap harus menunggu dan memperbaikinya sendiri sampai akhirnya kita dapat menggunakan versi terbaru yang lebihaman

Ada baiknya sebelum kita menggunakan, baca dahulu dokumentasi dari library tersebut beserta changelog yang disertakan dalam setiap rilis lbrary tersebut.

Kesimpulan

Dari beberapa permasalahan yang disebutkan diatas, pastikan selalu membaca informasi terbaru dari OWASP untuk melihat berbagai potensi serangan lain yang tidak dituliskan oleh postingan ini.