Jangan gunakan WAF (Web Application Firewall)

• Tidak banyak orang yang menentang penggunaan WAF, jadi tulisan ini dibuat. Hasil pencarian tentang WAF kebanyakan ditulis oleh vendor WAF
• WAF dibuat pada masa awal internet, dan bekerja dengan mencegat semua permintaan HTTP lalu mengevaluasi ratusan regular expression untuk memblokir permintaan yang mirip SQL, shell code, dan sebagainya
• Pada masa awal keamanan siber, WAF tampak seperti ide yang bagus, tetapi saat ini tidak lagi demikian
• Karena masalah performa, kemudahan untuk dilewati, risikonya sebagai vektor serangan, dan tingginya tingkat false positive, kini ada teknologi keamanan yang lebih baik

Performa WAF buruk sekali

• WAF menjalankan ratusan regular expression untuk setiap permintaan, sehingga menimbulkan penurunan performa
• Penggunaan WAF membutuhkan RAM tambahan yang cukup besar, serta meningkatkan rata-rata waktu upload, kecepatan pemrosesan permintaan, penggunaan CPU, dan juga menyebabkan pemblokiran yang keliru

WAF mudah dilewati

• Dalam persaingan tanpa henti antara WAF dan penyerang, penyerang berada di pihak yang lebih unggul
• Dengan menggunakan sintaks yang kompleks dan teknik encoding, aturan WAF bisa dilewati
• Misalnya, serangan Log4shell tidak bisa diblokir dengan pemeriksaan string sederhana, dan penyerang dapat memakai berbagai teknik bypass (Log4J Lookup)
• Selain itu, jika string serangan diisi dengan sekitar 8KB karakter yang tidak berguna tetapi tidak berbahaya, WAF tidak bisa terus melakukan buffering di RAM sehingga akan terpotong dan menjadi tidak berguna

WAF adalah vektor serangan

• Pada 2019, CapitalOne mengalami insiden kebocoran 100 juta pengajuan kredit akibat salah konfigurasi WAF
  • Penyerang dilaporkan menipu WAF agar mengirim permintaan ke layanan metadata EC2 dan memperoleh kredensial yang memungkinkan pembacaan file sensitif dari S3
• Artinya, insiden keamanan dapat terjadi akibat konfigurasi WAF yang salah
• Sebagian besar WAF bersifat kompleks dan sering kali ditulis sebagai closed source, sehingga memperluas attack surface
  • Karena merupakan produk "enterprise" yang mahal, perusahaan sering menjejalkan fitur yang tidak perlu agar terlihat lebih menonjol daripada pesaing
• Prinsip dasar keamanan untuk produk keamanan sering diabaikan

Tingginya tingkat false positive pada WAF

• Selama 20 tahun terakhir, set aturan WAF open source telah berkembang cukup besar untuk mendeteksi tipe serangan modern. WAF proprietary kemungkinan juga melakukan hal yang sama
• Ini berarti semakin banyak string yang dapat memicu WAF untuk berjalan dan memblokir permintaan
• Setiap kali aturan baru muncul seperti ini, perluasan aturan WAF meningkatkan tingkat false positive
• WAF "generasi berikutnya" mengklaim dapat menyelesaikan masalah ini dengan memeriksa beberapa permintaan sekaligus atau menggunakan sistem reputasi IP
  • Itu mungkin dapat meningkatkan false positive rates, tetapi tidak bisa sepenuhnya menyelesaikan masalah false positive
• Akibat false positive, pengguna dan tim support bisa tidak memiliki prosedur penyelesaian yang jelas

Alternatif untuk WAF

• Isolasi (Isolation): teknik untuk memastikan bahwa meskipun satu bagian sistem dikompromikan, bagian lain tidak ikut terdampak
  • Browser melakukan ini dengan menjalankan semua kode di dalam proses sandbox khusus yang tidak memiliki akses arbitrer ke cookie, kata sandi tersimpan, atau tab lain
  • Arsitektur microservices dirancang dengan mempertimbangkan isolasi, tetapi hal serupa juga bisa diterapkan dalam monolit dengan berbagai library dan bahasa
• Immutability: menghilangkan kategori serangan melalui file system read-only, package manager yang memerlukan reboot, backup yang hanya bisa ditambahkan, dan sebagainya
• Static Analysis: mencegah SQL injection dengan prepared statements dan memeriksa kode melalui static analysis di pipeline CI
• Capability-based Security: tidak semua API endpoint perlu memiliki akses tanpa batas ke database dan file system; terapkan pendekatan pemberian hanya izin yang benar-benar diperlukan

[roxie]

:+1:

[devpain]

Kalau kombinasi nginx + naxsi, sepertinya tidak termasuk beberapa hal di atas.
Pengelolaan ruleset WAF harus dibawa dengan cara yang dilakukan oleh pengembang layanan.
Pakar keamanan, tanpa pemahaman terhadap layanan, akhirnya membuat pengaturan yang umum, sehingga menghasilkan tingkat false positive yang tinggi, lalu menghapus ruleset satu per satu sesuai permintaan, dan pada akhirnya membuat WAF kehilangan fungsi aslinya.

[nosookja]

Saya setuju sebagian soal bypass dan false positive, tetapi secara keseluruhan terasa kuat bahwa informasi yang belum tentu akurat disusun seolah-olah sebagai fakta. Kalau sempat, saya juga perlu melihat isi tulisan aslinya. Terutama, menjadikan kasus CapitalOne sebagai masalah WAF menunjukkan bahwa penulis aslinya tampak sangat kurang memahami WAF. WAF bukan solusi yang memitigasi kerentanan secara mendasar. Kerentanan yang muncul dari kode seharusnya diselesaikan di kode; itulah penyelesaian yang benar. Namun kenyataannya sering tidak demikian, sehingga dibutuhkan sesuatu yang tepat di lapisan depan untuk memeriksa input yang mencurigakan atau berbahaya. Jika dikelola dengan baik, ini bisa menjadi alat yang sangat bagus, dan jika tidak dikelola dengan baik, bisa menjadi pisau yang melukai diri sendiri. Sifat dua sisi dari sebuah alat memang selalu ada, tetapi topik ini terasa terlalu menonjolkan sisi buruknya saja.

[xguru]

Ada berbagai pendapat dan bantahan tentang hal ini di komentar Hacker News. Silakan lihat juga. https://news.ycombinator.com/item?id=38255004