10 Kerentanan Keamanan Web Paling Umum

Untuk terlalu banyak perusahaan, baru setelah pelanggaran keamanan terjadi, praktik terbaik keamanan web menjadi prioritas. Selama bertahun-tahun saya bekerja sebagai profesional Keamanan TI, saya telah melihat berkali-kali betapa tidak jelasnya dunia masalah keamanan pengembangan web bagi banyak rekan programmer saya.

Pendekatan yang efektif untuk ancaman keamanan web harus, menurut definisi, proaktif dan defensif. Untuk itu, posting ini bertujuan untuk memicu pola pikir keamanan, semoga menyuntikkan para pembaca dengan dosis paranoia yang sehat.

Secara khusus, panduan ini berfokus pada 10 jebakan keamanan web yang umum dan signifikan yang harus diperhatikan, termasuk rekomendasi tentang bagaimana mereka dapat dimitigasi. Fokusnya adalah pada 10 Kerentanan Web Teratas yang diidentifikasi oleh Open Web Application Security Project (OWASP), sebuah organisasi nirlaba internasional yang bertujuan untuk meningkatkan keamanan perangkat lunak di seluruh dunia.

Sedikit primer keamanan cyber sebelum kita mulai – otentikasi dan otorisasi

Ketika berbicara dengan programmer lain dan profesional TI, saya sering mengalami kebingungan mengenai perbedaan antara otorisasi dan otentikasi. Dan tentu saja, fakta bahwa singkatan auth sering digunakan untuk keduanya membantu memperburuk kebingungan umum ini. Kebingungan ini sangat umum sehingga mungkin masalah ini harus dimasukkan dalam posting ini sebagai "Nol Kerentanan Web Umum".

Jadi sebelum kita melanjutkan, mari kita perjelas perbedaan antara kedua istilah ini:

• Otentikasi: Memverifikasi bahwa seseorang adalah (atau setidaknya tampaknya) pengguna tertentu, karena dia telah memberikan kredensial keamanan mereka dengan benar (kata sandi, jawaban atas pertanyaan keamanan, pemindaian sidik jari, dll.).
• Otorisasi: Mengonfirmasi bahwa pengguna tertentu memiliki akses ke sumber daya tertentu atau diberikan izin untuk melakukan tindakan tertentu.

Dengan kata lain, otentikasi adalah mengetahui siapa suatu entitas, sedangkan otorisasi adalah mengetahui apa yang dapat dilakukan entitas tertentu. Dengan mengingat hal ini, mari masuk ke 10 masalah keamanan internet teratas.

Kesalahan Keamanan Web Umum #1: Cacat injeksi

Cacat injeksi dihasilkan dari kegagalan klasik untuk memfilter input yang tidak tepercaya. Ini dapat terjadi ketika Anda meneruskan data yang tidak difilter ke server SQL (injeksi SQL), ke browser (XSS – kita akan membicarakannya nanti), ke server LDAP (injeksi LDAP), atau di mana pun. Masalahnya di sini adalah penyerang dapat menyuntikkan perintah ke entitas ini, yang mengakibatkan hilangnya data dan pembajakan browser klien.

Apa pun yang diterima aplikasi Anda dari sumber yang tidak tepercaya harus difilter, sebaiknya menurut daftar putih. Anda hampir tidak boleh menggunakan daftar hitam, karena mendapatkan hak itu sangat sulit dan biasanya mudah dilewati. Produk perangkat lunak antivirus biasanya memberikan contoh luar biasa dari daftar hitam yang gagal. Pencocokan pola tidak berfungsi.

Pencegahan: Kabar baiknya adalah bahwa melindungi terhadap injeksi adalah "hanya" masalah memfilter input Anda dengan benar dan memikirkan apakah input dapat dipercaya. Tetapi kabar buruknya adalah bahwa semua masukan perlu disaring dengan benar, kecuali jika tidak diragukan lagi dapat dipercaya (tetapi pepatah "tidak pernah mengatakan tidak pernah" muncul di pikiran di sini).

Dalam sistem dengan 1.000 input, misalnya, memfilter 999 di antaranya tidak cukup, karena ini masih menyisakan satu bidang yang dapat berfungsi sebagai penyembuhan Achilles untuk menjatuhkan sistem Anda. Dan Anda mungkin berpikir bahwa memasukkan hasil kueri SQL ke kueri lain adalah ide yang bagus, karena databasenya tepercaya, tetapi jika perimeternya tidak, masukannya datang secara tidak langsung dari orang-orang yang memiliki niat jahat. Ini disebut Injeksi SQL Orde Kedua jika Anda tertarik.

Karena pemfilteran cukup sulit dilakukan dengan benar (seperti kripto), yang biasanya saya sarankan adalah mengandalkan fungsi pemfilteran kerangka kerja Anda: mereka terbukti berfungsi dan diperiksa secara menyeluruh. Jika Anda tidak menggunakan kerangka kerja, Anda benar-benar harus berpikir keras tentang apakah tidak menggunakannya benar-benar masuk akal dalam konteks keamanan server Anda. 99% dari waktu tidak.

Kesalahan Keamanan Web Umum #2: Otentikasi Rusak

Ini adalah kumpulan beberapa masalah yang mungkin terjadi selama autentikasi rusak, tetapi tidak semuanya berasal dari akar penyebab yang sama.

Dengan asumsi bahwa ada orang yang masih ingin menggulung kode otentikasi mereka sendiri pada tahun 2014 (apa yang Anda pikirkan??), Saya menyarankan untuk tidak melakukannya. Sangat sulit untuk memperbaikinya, dan ada banyak sekali kemungkinan jebakan, hanya untuk menyebutkan beberapa:

1. URL mungkin berisi id sesi dan membocorkannya di header rujukan ke orang lain.
2. Kata sandi mungkin tidak dienkripsi baik dalam penyimpanan atau transit.
3. ID sesi mungkin dapat diprediksi, sehingga mendapatkan akses adalah hal yang sepele.
4. Fiksasi sesi mungkin dilakukan.
5. Pembajakan sesi mungkin terjadi, batas waktu tidak diterapkan dengan benar atau menggunakan HTTP (tanpa keamanan SSL), dll…

Pencegahan: Cara paling mudah untuk menghindari kerentanan keamanan web ini adalah dengan menggunakan kerangka kerja. Anda mungkin dapat menerapkan ini dengan benar, tetapi yang pertama jauh lebih mudah. Jika Anda ingin menggulung kode Anda sendiri, jadilah sangat paranoid dan pelajari diri Anda sendiri tentang apa jebakannya. Ada beberapa.

Kesalahan Keamanan Web Umum #3: Cross Site Scripting (XSS)

Ini adalah kegagalan sanitasi masukan yang cukup luas (pada dasarnya kasus khusus dari kesalahan umum #1). Penyerang memberikan tag JavaScript aplikasi web Anda pada input. Ketika input ini dikembalikan ke pengguna yang tidak bersih, browser pengguna akan menjalankannya. Ini bisa sesederhana membuat tautan dan membujuk pengguna untuk mengkliknya, atau itu bisa menjadi sesuatu yang jauh lebih jahat. Pada halaman memuat skrip berjalan dan, misalnya, dapat digunakan untuk mengirim cookie Anda ke penyerang.

Pencegahan: Ada solusi keamanan web sederhana: jangan kembalikan tag HTML ke klien. Ini memiliki manfaat tambahan untuk bertahan melawan injeksi HTML, serangan serupa di mana penyerang menyuntikkan konten HTML biasa (seperti gambar atau pemutar flash tak terlihat yang keras) – tidak berdampak tinggi tetapi pasti mengganggu (“tolong hentikan!”). Biasanya, solusinya hanya dengan mengonversi semua entitas HTML, sehingga <script> dikembalikan sebagai <script> . Metode sanitasi lain yang sering digunakan adalah menggunakan ekspresi reguler untuk menghapus tag HTML menggunakan ekspresi reguler pada < dan > , tetapi ini berbahaya karena banyak browser akan menafsirkan HTML yang rusak parah dengan baik. Lebih baik mengonversi semua karakter ke rekan-rekan mereka yang lolos.

Kesalahan Umum Keamanan Web #4: Referensi Objek Langsung Tidak Aman

Ini adalah kasus klasik mempercayai masukan pengguna dan membayar harga dalam kerentanan keamanan yang dihasilkan. Referensi objek langsung berarti bahwa objek internal seperti file atau kunci database diekspos ke pengguna. Masalah dengan ini adalah penyerang dapat memberikan referensi ini dan, jika otorisasi tidak ditegakkan (atau rusak), penyerang dapat mengakses atau melakukan hal-hal yang seharusnya dilarang.

Misalnya, kode memiliki modul download.php yang membaca dan memungkinkan pengguna mengunduh file, menggunakan parameter CGI untuk menentukan nama file (misalnya, download.php?file=something.txt ). Entah karena kesalahan atau karena kemalasan, pengembang menghilangkan otorisasi dari kode. Penyerang sekarang dapat menggunakan ini untuk mengunduh file sistem apa pun yang dapat diakses oleh pengguna yang menjalankan PHP, seperti kode aplikasi itu sendiri atau data lain yang tertinggal di server, seperti cadangan. Uh oh.

Contoh kerentanan umum lainnya adalah fungsi pengaturan ulang kata sandi yang bergantung pada input pengguna untuk menentukan kata sandi siapa yang kami atur ulang. Setelah mengklik URL yang valid, penyerang hanya dapat memodifikasi bidang username di URL untuk mengatakan sesuatu seperti "admin".

Kebetulan, kedua contoh ini adalah hal yang saya sendiri sering lihat muncul "di alam liar".

Pencegahan: Lakukan otorisasi pengguna dengan benar dan konsisten, dan daftar putih pilihannya. Lebih sering daripada tidak, seluruh masalah dapat dihindari dengan menyimpan data secara internal dan tidak bergantung pada data yang dikirimkan dari klien melalui parameter CGI. Variabel sesi di sebagian besar kerangka kerja sangat cocok untuk tujuan ini.

Kesalahan Keamanan Web Umum #5: Kesalahan konfigurasi keamanan

Dalam pengalaman saya, server web dan aplikasi yang salah dikonfigurasi jauh lebih umum daripada yang dikonfigurasi dengan benar. Mungkin ini karena tidak ada kekurangan cara untuk mengacau. Beberapa contoh:

1. Menjalankan aplikasi dengan debug diaktifkan dalam produksi.
2. Memiliki daftar direktori yang diaktifkan di server, yang membocorkan informasi berharga.
3. Menjalankan perangkat lunak usang (pikirkan plugin WordPress, PhpMyAdmin lama).
4. Memiliki layanan yang tidak perlu berjalan di mesin.
5. Tidak mengubah kunci dan kata sandi default. (Terjadi jauh lebih sering daripada yang Anda yakini!)
6. Mengungkapkan informasi penanganan kesalahan kepada penyerang, seperti jejak tumpukan.

Pencegahan: Miliki proses “build and deploy” yang baik (sebaiknya otomatis), yang dapat menjalankan pengujian saat penerapan. Solusi kesalahan konfigurasi keamanan orang miskin adalah kait pasca-komit, untuk mencegah kode keluar dengan kata sandi default dan/atau hal-hal pengembangan bawaan.

Kesalahan Keamanan Web Umum #6: Paparan data sensitif

Kerentanan keamanan web ini adalah tentang kripto dan perlindungan sumber daya. Data sensitif harus dienkripsi setiap saat, termasuk saat transit dan saat istirahat. Tidak ada pengecualian. Informasi kartu kredit dan kata sandi pengguna tidak boleh bepergian atau disimpan tanpa enkripsi, dan kata sandi harus selalu di-hash. Jelas bahwa algoritma kripto/hashing tidak boleh lemah – jika ragu, standar keamanan web merekomendasikan AES (256 bit ke atas) dan RSA (2048 bit ke atas).

Dan meskipun tidak perlu dikatakan bahwa ID sesi dan data sensitif tidak boleh berjalan di URL dan cookie sensitif harus memiliki tanda aman, ini sangat penting dan tidak dapat terlalu ditekankan.

Pencegahan:

• Dalam perjalanan: Gunakan HTTPS dengan sertifikat dan PFS (Perfect Forward Secrecy) yang sesuai. Jangan menerima apa pun melalui koneksi non-HTTPS. Memiliki bendera aman pada cookie.

• Dalam penyimpanan: Ini lebih sulit. Pertama dan terpenting, Anda perlu menurunkan eksposur Anda. Jika Anda tidak membutuhkan data sensitif, hancurkan. Data yang tidak Anda miliki tidak dapat dicuri. Jangan pernah menyimpan informasi kartu kredit , karena Anda mungkin tidak ingin berurusan dengan kepatuhan PCI. Daftar dengan pemroses pembayaran seperti Stripe atau Braintree. Kedua, jika Anda memiliki data sensitif yang benar-benar Anda butuhkan, simpan dengan terenkripsi dan pastikan semua kata sandi telah di-hash. Untuk hashing, penggunaan bcrypt dianjurkan. Jika Anda tidak menggunakan bcrypt, pelajari tabel pengasinan dan pelangi.

Dan dengan risiko menyatakan yang sudah jelas, jangan simpan kunci enkripsi di sebelah data yang dilindungi . Itu seperti menyimpan sepeda Anda dengan kunci yang memiliki kunci di dalamnya. Lindungi cadangan Anda dengan enkripsi dan jaga kerahasiaan kunci Anda. Dan tentu saja, jangan sampai kehilangan kuncinya!

Kesalahan Keamanan Web Umum # 7: Kontrol akses tingkat fungsi tidak ada

Ini hanyalah kegagalan otorisasi. Ini berarti bahwa ketika suatu fungsi dipanggil di server, otorisasi yang tepat tidak dilakukan. Seringkali, pengembang mengandalkan fakta bahwa sisi server menghasilkan UI dan mereka berpikir bahwa fungsionalitas yang tidak disediakan oleh server tidak dapat diakses oleh klien. Ini tidak sesederhana itu, karena penyerang selalu dapat memalsukan permintaan ke fungsi "tersembunyi" dan tidak akan terhalang oleh fakta bahwa UI tidak membuat fungsi ini mudah diakses. Bayangkan ada panel /admin , dan tombol hanya ada di UI jika pengguna sebenarnya adalah admin. Tidak ada yang menghalangi penyerang untuk menemukan fungsi ini dan menyalahgunakannya jika otorisasi tidak ada.

Pencegahan: Di sisi server, otorisasi harus selalu dilakukan. Ya selalu. Tidak ada pengecualian atau kerentanan yang akan mengakibatkan masalah serius.

Kesalahan Umum Keamanan Web #8: Pemalsuan Permintaan Lintas Situs (CSRF)

Ini adalah contoh bagus dari serangan deputi yang membingungkan di mana browser ditipu oleh beberapa pihak lain untuk menyalahgunakan otoritasnya. Situs pihak ketiga, misalnya, dapat membuat browser pengguna menyalahgunakan wewenangnya untuk melakukan sesuatu bagi penyerang.

Dalam kasus CSRF, situs pihak ketiga mengeluarkan permintaan ke situs target (misalnya, bank Anda) menggunakan browser Anda dengan cookie/sesi Anda. Jika Anda masuk pada satu tab di beranda bank Anda, misalnya, dan mereka rentan terhadap serangan ini, tab lain dapat membuat browser Anda menyalahgunakan kredensialnya atas nama penyerang, yang mengakibatkan masalah deputi yang membingungkan. Deputi adalah browser yang menyalahgunakan wewenangnya (cookie sesi) untuk melakukan sesuatu yang diperintahkan penyerang.

Pertimbangkan contoh ini:

Penyerang Alice ingin meringankan dompet target Todd dengan mentransfer sebagian uangnya kepadanya. Bank Todd rentan terhadap CSRF. Untuk mengirim uang, Todd harus mengakses URL berikut:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

Setelah URL ini dibuka, halaman sukses disajikan ke Todd, dan transfer selesai. Alice juga tahu, bahwa Todd sering mengunjungi situs di bawah kendalinya di blog.aliceisawesome.com, di mana dia menempatkan cuplikan berikut:

<img src=http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 width=0 height=0 />

Saat mengunjungi situs web Alice, browser Todd mengira bahwa Alice menautkan ke sebuah gambar, dan secara otomatis mengeluarkan permintaan HTTP GET untuk mengambil gambar, tetapi ini sebenarnya menginstruksikan bank Todd untuk mentransfer $1500 ke Alice.

Kebetulan, selain menunjukkan kerentanan CSRF, contoh ini juga menunjukkan pengubahan status server dengan permintaan HTTP GET idempoten yang merupakan kerentanan serius. Permintaan HTTP GET harus idempoten (aman), artinya permintaan tersebut tidak dapat mengubah sumber daya yang diakses. Jangan pernah menggunakan metode idempoten untuk mengubah status server.

Fakta menyenangkan: CSRF juga merupakan metode yang digunakan orang untuk mengisi kue di masa lalu hingga afiliasi menjadi lebih bijak.

Pencegahan: Simpan token rahasia di bidang formulir tersembunyi yang tidak dapat diakses dari situs pihak ke-3. Anda tentu saja harus selalu memverifikasi bidang tersembunyi ini. Beberapa situs meminta kata sandi Anda juga ketika mengubah pengaturan sensitif (seperti email pengingat kata sandi Anda, misalnya), meskipun saya menduga ini ada untuk mencegah penyalahgunaan sesi yang Anda tinggalkan (di warnet misalnya).

Kesalahan Keamanan Web Umum #9: Menggunakan komponen dengan kerentanan yang diketahui

Judul mengatakan itu semua. Saya akan mengklasifikasikan ini lagi sebagai masalah pemeliharaan/penyebaran. Sebelum memasukkan kode baru, lakukan riset, mungkin audit. Menggunakan kode yang Anda dapatkan dari orang acak di GitHub atau beberapa forum mungkin sangat nyaman, tetapi bukan tanpa risiko kerentanan keamanan web yang serius.

Saya telah melihat banyak contoh, misalnya, di mana situs dimiliki (yaitu, di mana orang luar memperoleh akses administratif ke suatu sistem), bukan karena pemrogramnya bodoh, tetapi karena perangkat lunak pihak ketiga tetap tidak ditambal selama bertahun-tahun dalam produksi. Ini terjadi sepanjang waktu dengan plugin WordPress misalnya. Jika menurut Anda mereka tidak akan menemukan instalasi phpmyadmin tersembunyi Anda, izinkan saya memperkenalkan Anda ke dirbuster.

Pelajaran di sini adalah bahwa pengembangan perangkat lunak tidak berakhir ketika aplikasi dikerahkan. Harus ada dokumentasi, pengujian, dan rencana tentang cara memelihara dan memperbaruinya, terutama jika mengandung komponen pihak ketiga atau sumber terbuka.

Pencegahan:

• Berhati-hatilah. Selain berhati-hati saat menggunakan komponen seperti itu, jangan menjadi pembuat kode salin-tempel. Periksa dengan saksama potongan kode yang akan Anda masukkan ke dalam perangkat lunak Anda, karena kode tersebut mungkin rusak dan tidak dapat diperbaiki (atau dalam beberapa kasus, sengaja berbahaya—serangan keamanan web terkadang tanpa disadari diundang dengan cara ini).

• Tetap terkini. Pastikan Anda menggunakan versi terbaru dari semua yang Anda percayai, dan rencanakan untuk memperbaruinya secara teratur. Setidaknya berlangganan buletin kerentanan keamanan baru terkait produk.

Kesalahan Keamanan Web Umum #10: Pengalihan dan penerusan yang tidak valid

Ini sekali lagi merupakan masalah penyaringan input. Misalkan situs target memiliki modul redirect.php yang menggunakan URL sebagai parameter GET . Memanipulasi parameter dapat membuat URL di targetsite.com yang mengarahkan browser ke malwareinstall.com . Ketika pengguna melihat tautan, mereka akan melihat targetsite.com/blahblahblah yang menurut pengguna tepercaya dan aman untuk diklik. Sedikit yang mereka tahu bahwa ini benar-benar akan mentransfer mereka ke halaman malware drop (atau berbahaya lainnya). Atau, penyerang mungkin mengalihkan browser ke targetsite.com/deleteprofile?confirm=1 .

Perlu disebutkan, bahwa memasukkan input yang ditentukan pengguna yang tidak bersih ke dalam header HTTP dapat menyebabkan injeksi header yang sangat buruk.

Pencegahan: Pilihannya meliputi:

• Jangan lakukan pengalihan sama sekali (jarang diperlukan).
• Miliki daftar statis lokasi yang valid untuk diarahkan.
• Daftar putih parameter yang ditentukan pengguna, tetapi ini bisa rumit.

Epilog

Saya harap saya telah berhasil sedikit menggelitik otak Anda dengan posting ini dan untuk memperkenalkan dosis paranoia yang sehat dan kesadaran kerentanan keamanan situs web.

Kesimpulan inti di sini adalah bahwa praktik perangkat lunak kuno ada karena suatu alasan dan apa yang diterapkan pada masa lalu untuk buffer overflows, masih berlaku untuk string acar dengan Python hari ini. Protokol keamanan membantu Anda menulis (lebih) program yang benar, yang harus dicita-citakan oleh semua programmer.

Harap gunakan pengetahuan ini secara bertanggung jawab, dan jangan menguji halaman tanpa izin!

Untuk informasi lebih lanjut dan serangan sisi server yang lebih spesifik, lihat: https://www.owasp.org/index.php/Category:Attack.

Umpan balik pada posting ini dan saran mitigasinya diterima dan dihargai. Posting terkait di masa mendatang direncanakan, terutama tentang masalah kerentanan keamanan TI terdistribusi (DDoS) dan sekolah lama (bukan web). Jika Anda memiliki permintaan khusus tentang jenis perlindungan web apa yang harus ditulis, jangan ragu untuk menghubungi saya langsung di [email protected].

Ini untuk keamanan situs web! Bersulang.