Changelog: Proyek 10 Teratas OWASP

Aplikasi web telah meledak dalam kompleksitas selama dekade terakhir. Mereka telah berevolusi dari wadah sederhana untuk formulir kontak dan polling menjadi aplikasi lengkap. Kami dapat membandingkannya dengan aplikasi desktop yang berat, baik dalam ukuran maupun kinerja. Dengan peningkatan tajam dalam kompleksitas dan peningkatan jumlah aplikasi kaya fitur, telah menjadi kebutuhan untuk menginvestasikan banyak waktu dan perhatian untuk membuat semua komponen aplikasi seaman mungkin. Peningkatan besar-besaran pengguna Internet telah membuatnya semakin penting untuk mengatasi masalah melindungi data dan pengguna aplikasi. Ada banyak ancaman yang mencoba menyusup dan menyebabkan sakit kepala parah bagi semua orang yang terlibat.

Pada tahun 2001, sebuah organisasi baru memasuki panggung. Tujuannya adalah untuk memerangi masalah keamanan yang memengaruhi situs web dan aplikasi. Itu tepat bernama Proyek Keamanan Aplikasi Web Terbuka (OWASP). Saat ini, ia menerbitkan sumber daya, menyelenggarakan konferensi, dan mengusulkan standar keamanan web dan aplikasi. Standar de facto untuk keamanan aplikasi web adalah Proyek Sepuluh Teratas OWASP. Ini daftar sepuluh ancaman keamanan yang paling umum. Faktor yang berpengaruh dalam memutuskan apa yang masuk adalah sejumlah besar data dan umpan balik komunitas. Pada akhir 2017, ada pembaruan proyek. Beberapa masalah baru yang penting untuk banyak aplikasi web modern mendapatkan tempat mereka, sementara beberapa telah lolos dari daftar.

Artikel ini melengkapi daftar asli dan mengilustrasikan perubahan terbaru pada daftar. Ini menggambarkan ancaman, mencoba memberikan contoh yang jelas untuk pemahaman yang lebih mudah, dan mengusulkan cara untuk memerangi ancaman keamanan.

Masalah Dihapus dari Daftar 10 Teratas OWASP

Sebelum pembaruan 2017, daftar dari 2013 adalah yang terbaru. Mengingat perubahan cara aplikasi web sekarang dibangun dan digunakan, masuk akal untuk melakukan revisi menyeluruh. Layanan mikro mengambil bagian mereka, dan kerangka kerja baru yang keren dan berkilau menggantikan peralatan pertempuran kode vanila. Fakta-fakta ini berarti bahwa beberapa ancaman yang disebutkan sebelumnya telah dihapus dan beberapa ancaman baru menggantikannya.

Kami akan memastikan untuk menyegarkan ingatan kami tentang masalah yang telah lama terlupakan dalam artikel ini, serta memperkenalkan serigala jahat yang baru. Belajar tentang sejarah adalah satu-satunya cara pasti untuk tidak mengulangi kesalahan yang sama.

Pemalsuan Permintaan Lintas Situs

Pemalsuan permintaan lintas situs (CSRF) adalah salah satu "pecundang" dalam iterasi proyek baru-baru ini. Itu hilang karena banyak kerangka kerja web modern menyertakan mekanisme pertahanan CSRF. Probabilitas mengekspos aplikasi Anda ke ancaman dengan demikian menurun dengan cepat.

Terlepas dari CSRF yang keluar dari daftar, ada baiknya untuk menyegarkan ingatan kita. Mari kita pastikan itu tidak kembali lebih kuat dari sebelumnya.

Intinya, CSRF adalah sebuah eksploit yang terasa seperti bom asap. Penyerang menipu pengguna yang tidak menaruh curiga untuk menjalankan permintaan atau tindakan yang tidak diinginkan dalam aplikasi web. Sederhananya, penyerang memaksa korbannya untuk mengirim permintaan ke aplikasi pihak ketiga, dan korban tidak menyadari permintaan yang pernah dikirim. Permintaan tersebut bisa berupa permintaan HTTP GET untuk mengambil sumber daya, atau lebih buruk lagi, permintaan HTTP POST yang mengubah sumber daya di bawah kendali korban. Selama serangan, korban berpikir bahwa semuanya baik-baik saja, paling sering bahkan tanpa menyadari bahwa ada sesuatu yang terjadi di latar belakang. Setelah udara bersih, kerusakan terjadi atau ada sesuatu yang hilang, dan tidak ada yang tahu apa yang terjadi.

Otentikasi pengguna sebelumnya yang berhasil dalam aplikasi target adalah yang memungkinkan jebakan menjadi efektif. Pengguna telah di beberapa titik sebelum serangan masuk ke aplikasi. Aplikasi tersebut mengirimkan cookie kepada korban untuk mengingatnya. Setelah browser web mengirimkan permintaan jahat, cookie secara otomatis dikirim bersama dengan muatan potensial apa pun dan aplikasi tidak keberatan untuk melayani permintaan tersebut kepada pengguna yang sudah dikenalnya.

Salah satu contoh paling terkenal adalah menipu pengguna untuk mentransfer uang dari akun mereka ke akun yang dikendalikan penyerang. Seorang pengguna masuk ke sistem e-banking untuk memeriksa saldo rekening mereka. Setelah itu, mereka mengunjungi forum online untuk memeriksa ulasan ponsel baru. Seorang penyerang, memancing dengan dinamit, memposting ulasan termasuk gambar dengan hyperlink gambar yang tampaknya rusak. Alih-alih hyperlink nyata, penyerang menggunakan hyperlink yang digunakan sistem e-banking secara internal untuk mentransfer uang dari akun A ke akun B: https://payments.dummybank.com?receiver=attacker&amount=100 . Sistem perbankan menjadikan pengguna yang diautentikasi sebagai pengirim dan nilai dari parameter "penerima" sebagai penerima dana. Tentu saja, penyerang menentukan akun luar negeri mereka sebagai penerima.

Karena browser secara otomatis memuat gambar saat merender halaman, permintaan terjadi di latar belakang. Jika sistem pembayaran bank menerapkan transfer uang menggunakan permintaan HTTP GET, tidak ada yang menghentikan bencana terjadi. Perhatikan bahwa contohnya sederhana dan kemungkinan besar transfer tidak ditangani melalui HTTP GET. Namun, penyerang dapat, dengan sedikit lebih banyak kesulitan, mengubah atribut "tindakan" di formulir posting pesan HTML forum. Browser kemudian mengirimkan permintaan ke sistem pembayaran bank, bukan ke back-end forum.

Mencuri uang hanyalah salah satu dari banyak contoh di luar sana. Mengubah alamat email pengguna atau melakukan pembelian yang tidak diinginkan juga termasuk dalam kategori ini. Seperti yang sering terjadi, rekayasa sosial dan beberapa pengetahuan teknis merupakan pengaruh yang efektif terhadap kesalahan rekayasa perangkat lunak.

Saat merancang sistem Anda, ingatlah hal-hal berikut:

• Jangan gunakan permintaan HTTP GET untuk mengenkapsulasi tindakan yang memodifikasi sumber daya. Anda hanya boleh menggunakan permintaan ini untuk mengambil informasi. Ingat, aturan praktisnya adalah membuat permintaan GET idempoten.
• Lakukan , saat mentransfer data secara internal menggunakan permintaan HTTP POST, cenderung mengirim data dalam JSON, XML, atau format lain selain mengkodekan parameter sebagai string kueri. Menggunakan format data non-sepele mengurangi bahaya seseorang membuat formulir HTML palsu yang akan mengirimkan data ke layanan Anda.
• Pastikan untuk membuat dan menyertakan token unik dan tak terduga ke dalam formulir HTML Anda. Token ini juga harus unik untuk setiap permintaan. Memeriksa keberadaan dan kebenaran token tersebut akan menurunkan risiko ancaman yang terjadi. Untuk mengetahui token dan menggunakannya dalam permintaan palsu mereka, penyerang perlu mengakses sistem Anda dan mengambil token langsung dari sana. Karena token hanya untuk satu kali, mereka tidak dapat menggunakannya kembali dalam kode berbahaya.

Kerentanan ini memiliki efek yang lebih buruk jika digabungkan dengan skrip lintas situs (XSS). Jika penyerang dapat menyuntikkan kode berbahaya ke situs web atau aplikasi favorit, cakupan serangan menjadi jauh lebih signifikan dan berbahaya. Bahkan yang lebih kritis, penyerang dapat menghindari beberapa mekanisme perlindungan terhadap CSRF jika serangan XSS memungkinkan.

Perlu diingat bahwa CSRF belum hilang, hanya saja tidak biasa seperti dulu.

Pengalihan dan Penerusan yang Tidak Divalidasi

Banyak aplikasi, setelah menyelesaikan suatu tindakan, mengarahkan atau meneruskan pengguna ke bagian lain dari aplikasi yang sama, atau bahkan beberapa lainnya. Misalnya, berhasil masuk ke aplikasi memicu pengalihan ke halaman beranda atau halaman yang pertama kali dikunjungi pengguna. Sangat sering, tujuan adalah bagian dari tindakan formulir atau alamat tautan. Jika komponen yang menangani pengalihan atau penerusan tidak memastikan bahwa alamat tujuan memang yang dibuat oleh aplikasi, potensi ancaman akan muncul. Ini adalah kerentanan keamanan yang disebut "pengalihan dan penerusan yang tidak divalidasi."

Dua alasan utama mengapa pengalihan dan penerusan yang tidak divalidasi dianggap berbahaya adalah phishing dan pembajakan kredensial. Penyerang dapat mengatur untuk mengubah lokasi target redirect/forward dan mengirim pengguna ke aplikasi berbahaya yang hampir tidak dapat dibedakan dari yang asli. Pengguna yang tidak curiga mengungkapkan kredensial dan informasi rahasia mereka kepada pihak ketiga yang jahat. Sebelum mereka menyadari apa yang telah terjadi, semuanya sudah terlambat.

Sebagai contoh, aplikasi web sangat sering menerapkan sign-in dengan dukungan untuk pengalihan ke halaman yang terakhir dikunjungi. Agar dapat melakukannya dengan mudah, atribut tindakan formulir HTML mungkin terlihat seperti http://myapp.example.com/signin?url=http://myapp.example.com/puppies . Anda adalah pengagum berat anak anjing, jadi masuk akal untuk memasang ekstensi browser yang menggantikan favicon situs web dengan thumbnail anak anjing favorit Anda. Sayangnya, ini adalah dunia anjing-makan-anjing. Penulis ekstensi browser memutuskan untuk menguangkan cinta tanpa syarat Anda dan memperkenalkan "fitur" tambahan. Setiap kali Anda mengunjungi situs penggemar anak anjing favorit Anda, itu akan menggantikan parameter "url" di atribut tindakan formulir dengan tautan ke situs mereka sendiri. Karena situsnya terlihat persis sama, ketika Anda memberikan detail kartu kredit Anda untuk membeli kartu bermain anak anjing, Anda sebenarnya membiayai penyerang jahat, bukan hobi Anda.

Memecahkan kerentanan melibatkan memeriksa lokasi tujuan dengan memastikan itu yang dimaksud. Jika kerangka kerja atau pustaka melakukan pengalihan lengkap atau logika penerusan, ada baiknya untuk memeriksa implementasi dan memperbarui kode jika perlu. Jika tidak, Anda perlu melakukan pemeriksaan manual untuk melindungi dari serangan tersebut.

Ada beberapa jenis pemeriksaan yang bisa Anda lakukan. Untuk perlindungan terbaik, gunakan kombinasi beberapa pendekatan alih-alih hanya menggunakan salah satunya.

• Validasi URL keluar untuk memastikannya mengarah ke domain yang Anda kontrol.
• Alih-alih menggunakan alamat eksplisit, encode di front-end dan kemudian decode dan validasi di back-end.
• Siapkan daftar putih URL tepercaya. Mengizinkan penerusan dan pengalihan hanya ke lokasi yang diizinkan. Lebih suka pendekatan ini untuk mempertahankan daftar hitam. Daftar hitam biasanya diisi dengan item baru hanya ketika sesuatu yang buruk terjadi. Daftar putih lebih membatasi.
• Gunakan pendekatan yang digunakan oleh LinkedIn dan beberapa aplikasi lain: Berikan halaman kepada pengguna Anda yang meminta mereka untuk mengonfirmasi pengalihan/penerusan, memperjelas bahwa mereka meninggalkan aplikasi Anda.

Masalah yang Digabungkan

Sebagian besar masalah dalam daftar dapat dilabeli sebagai cacat dalam implementasi, baik karena kurangnya pengetahuan atau investigasi yang tidak cukup mendalam terhadap potensi ancaman. Kedua alasan ini dapat dikaitkan dengan kurangnya pengalaman dan solusi untuk mempertimbangkannya di masa depan adalah mudah—pastikan untuk belajar lebih banyak dan lebih teliti. Yang sangat rumit bergantung pada kombinasi dari sifat berbahaya (tapi sangat manusiawi) membuat terlalu banyak asumsi ditambah dengan kesulitan mengembangkan dan memelihara sistem komputer yang kompleks. Kerentanan yang sesuai dengan kategori ini adalah "kontrol akses rusak".

Kontrol Akses Rusak

Kerentanan disebabkan oleh tidak memadainya, atau tidak lengkap, otorisasi dan kontrol akses untuk bagian tertentu dari aplikasi. Dalam iterasi sebelumnya dari Proyek Sepuluh Teratas OWASP, ada dua masalah: referensi objek langsung yang tidak aman dan kontrol akses tingkat fungsi yang hilang. Mereka sekarang digabung menjadi satu karena kesamaan mereka.

Referensi Objek Langsung

Referensi objek langsung sering digunakan dalam URL untuk mengidentifikasi sumber daya yang dioperasikan. Misalnya, ketika pengguna masuk, mereka dapat mengunjungi profil mereka dengan mengeklik tautan yang berisi pengenal profil mereka. Jika pengidentifikasi yang sama disimpan dalam database dan digunakan untuk mengambil informasi profil, dan aplikasi mengasumsikan bahwa orang dapat membuka halaman profil hanya melalui halaman masuk, mengubah pengidentifikasi profil di URL memperlihatkan informasi profil pengguna lain.

Aplikasi yang menyetel URL formulir profil hapus http://myapp.example.com/users/15/delete memperjelas bahwa setidaknya ada 14 pengguna lain di dalam aplikasi. Mencari tahu bagaimana cara mendapatkan bentuk penghapusan pengguna lain bukanlah ilmu roket dalam kasus ini.

Solusi untuk masalah ini adalah melakukan pemeriksaan otorisasi untuk setiap sumber daya tanpa mengasumsikan bahwa hanya jalur tertentu yang dapat diambil untuk sampai ke beberapa bagian aplikasi. Selain itu, menghapus referensi langsung dan menggunakan referensi tidak langsung merupakan langkah maju lainnya karena mempersulit pengguna jahat untuk mengetahui bagaimana referensi dibuat.

Selama pengembangan, sebagai tindakan pencegahan, tuliskan diagram state machine sederhana. Biarkan status mewakili halaman yang berbeda dalam aplikasi Anda dan transisi tindakan yang dapat dilakukan pengguna. Ini memudahkan untuk membuat daftar semua transisi dan halaman yang membutuhkan perhatian khusus.

Kontrol Akses tingkat Fungsi Tidak Ada

Kontrol akses tingkat fungsi yang hilang sangat mirip dengan referensi objek langsung yang tidak aman. Dalam hal ini, pengguna memodifikasi URL atau parameter lain untuk mencoba mengakses bagian aplikasi yang dilindungi. Jika tidak ada kontrol akses yang tepat yang memeriksa tingkat akses, pengguna dapat memperoleh akses istimewa ke sumber daya aplikasi atau setidaknya beberapa pengetahuan tentang keberadaannya.

Meminjam dari contoh untuk referensi objek langsung, Jika aplikasi mengasumsikan bahwa pengguna yang mengunjungi formulir penghapusan adalah pengguna super hanya karena pengguna super dapat melihat tautan ke formulir penghapusan, tanpa membuat otorisasi lebih lanjut, celah keamanan besar akan terbuka. Mengandalkan ketersediaan beberapa elemen UI bukanlah kontrol akses yang tepat.

Masalah ini diselesaikan dengan selalu memastikan untuk melakukan pemeriksaan di semua lapisan aplikasi Anda. Antarmuka front-end mungkin bukan satu-satunya cara pengguna jahat dapat mengakses lapisan domain Anda. Selain itu, jangan mengandalkan informasi yang diteruskan dari pengguna tentang tingkat akses mereka. Lakukan kontrol sesi yang tepat dan selalu periksa kembali data yang diterima. Hanya karena badan permintaan mengatakan pengguna adalah admin, itu tidak berarti mereka benar-benar admin.

Kontrol akses yang rusak sekarang menggabungkan semua masalah yang terkait dengan kontrol akses yang tidak memadai, baik itu pada tingkat aplikasi atau tingkat sistem, seperti kesalahan konfigurasi sistem file.

Isu Baru dalam Daftar 10 Teratas OWASP

Munculnya kerangka kerja front-end baru dan adopsi praktik pengembangan perangkat lunak baru mengalihkan masalah keamanan ke topik yang sama sekali baru. Teknologi baru juga berhasil memecahkan beberapa masalah umum yang sebelumnya kami tangani secara manual. Oleh karena itu, menjadi bermanfaat untuk merevisi daftar dan menyesuaikannya dengan tren modern.

Entitas Eksternal XML

Standar XML menawarkan ide yang kurang dikenal yang disebut entitas eksternal, yang merupakan bagian dari definisi tipe data (DTD) dokumen. Ini memungkinkan penulis dokumen untuk menentukan tautan ke entitas luar yang kemudian dapat dirujuk dan dimasukkan dalam dokumen utama. Contoh yang sangat sederhana adalah:

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

Selama penguraian, referensi &bar; diganti dengan konten dari entitas yang ditentukan, sehingga menghasilkan <foo>baz</foo> .

Jika aplikasi mengambil input eksternal dan memasukkannya, tanpa pemeriksaan apa pun, langsung ke dalam definisi dokumen XML, berbagai kebocoran dan serangan data akan mungkin terjadi.

Hal ajaibnya adalah entitas tidak harus berupa string sederhana—itu bisa menjadi referensi ke file di sistem file. Pengurai XML akan dengan senang hati mengambil konten file yang ditentukan dan memasukkannya ke dalam respons yang dihasilkan, yang berpotensi mengungkapkan informasi sistem yang sensitif. Seperti yang diilustrasikan oleh OWASP, akan sangat mudah untuk mendapatkan informasi tentang pengguna sistem dengan mendefinisikan entitas sebagai:

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

“Fitur” yang sangat merepotkan dari kerentanan ini adalah kemungkinan untuk dengan mudah mengeksekusi serangan penolakan layanan. Salah satu cara mudah untuk melakukannya adalah dengan membuat daftar isi file tanpa akhir seperti /dev/random . Yang lainnya adalah membuat urutan entitas, masing-masing mereferensikan yang sebelumnya berkali-kali. Ini mengubah referensi terakhir menjadi akar dari pohon yang berpotensi sangat lebar dan dalam yang penguraiannya dapat menghabiskan memori sistem. Serangan ini bahkan dikenal sebagai Billion Laughs. Seperti yang ditunjukkan di Wikipedia, serangkaian entitas dummy didefinisikan, menghasilkan peluang bagi penyerang untuk memasukkan satu miliar lol ke dalam dokumen akhir.

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

Mencegah eksploitasi entitas eksternal XML dapat dilakukan dengan menggunakan format data yang tidak terlalu rumit. JSON adalah pengganti yang baik, asalkan beberapa tindakan pencegahan juga diambil karena kemungkinan serangan terhadapnya. Memperbarui pustaka XML adalah suatu keharusan, ditambah dengan menonaktifkan pemrosesan entitas eksternal dan DTD. Seperti biasa, validasi dan bersihkan data yang berasal dari sumber yang tidak tepercaya sebelum menggunakannya atau memasukkannya ke dalam dokumen Anda.

Deserialisasi Tidak Aman

Saat menulis kode, pengembang memiliki kekuatan untuk mengontrol sistem yang mereka kembangkan menggunakan kode yang mereka tulis. Betapa hebatnya mengendalikan perilaku sistem pihak ketiga yang hanya menulis sedikit atau bahkan tanpa kode? Berkat fakta bahwa manusia tidak sempurna dan perpustakaan memiliki kekurangan, ini pasti mungkin.

Status dan konfigurasi aplikasi sering diserialkan dan disimpan. Kadang-kadang browser berfungsi sebagai mesin penyimpanan jika data serial digabungkan dengan pengguna saat ini. Aplikasi yang mencoba menjadi pintar dan menghemat waktu pemrosesan dapat menggunakan cookie untuk menandai bahwa pengguna telah masuk. Karena cookie hanya dapat dibuat setelah proses masuk berhasil, masuk akal untuk menyimpan nama pengguna di dalam cookie. Seorang pengguna kemudian diautentikasi dan disahkan berdasarkan keberadaan dan konten cookie. Jika orang tidak bermaksud buruk, tidak ada yang bisa salah. Sejujurnya, mereka juga tidak boleh penasaran.

Jika pengguna yang penasaran menemukan cookie di mesin mereka, mereka dapat melihat sesuatu seperti ini:

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

Kamus Python yang sangat valid diserialisasikan ke JSON, tidak ada yang istimewa tentang itu. Pengguna yang selalu ingin tahu mungkin mengubah tanggal kedaluwarsa agar aplikasi tidak memaksa keluar. Pengguna yang lebih penasaran mungkin mencoba mengubah nama pengguna menjadi "jane.doe" . Jika nama pengguna ini ada, itu akan membuka dunia baru bagi pengguna yang tidak curiga yang sekarang memiliki akses ke data pribadi.

Contoh sederhana dari serialisasi data ke JSON dan menjaga semuanya transparan jauh dari hal terburuk yang dapat terjadi pada Anda. Jika penyerang berhasil memodifikasi beberapa data serial, mereka mungkin dapat memodifikasinya dengan cara yang memaksa sistem Anda untuk mengeksekusi kode arbitrer.

Katakanlah Anda sedang membangun REST API yang memungkinkan orang untuk menulis model pembelajaran mesin mereka sendiri dengan Python dan mengunggahnya ke layanan Anda. Layanan akan mengevaluasi model yang diunggah dan melatihnya menggunakan kumpulan data Anda. Hal ini memungkinkan orang untuk menggunakan sumber daya komputasi Anda dan sejumlah besar kumpulan data yang tersedia untuk pembuatan model yang cepat dan mudah.

Layanan tidak menyimpan kode dalam format teks biasa. Pengguna mengambil kode mereka, mengenkripsinya menggunakan kunci pribadi mereka, dan mengirimkannya ke API untuk pelatihan. Ketika layanan perlu menjalankan model, itu mendekripsi kode, membukanya, dan menjalankannya. Bagian yang sulit adalah bahwa protokol acar tidak aman. Kode dapat dibangun dengan cara yang memungkinkan eksekusi kode berbahaya sewenang-wenang selama deserialisasi.

Protokol acar Python memungkinkan kelas untuk mendefinisikan metode __reduce__ , yang mengembalikan informasi tentang cara membatalkan serialisasi objek khusus. Salah satu nilai pengembalian yang didukung adalah tupel dari dua argumen: callable dan tuple argumen untuk diteruskan ke callable. Mempertimbangkan bahwa sistem pelatihan model ML Anda bertujuan untuk memberikan fleksibilitas maksimum pada struktur kode, kode berikut dapat ditulis:

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

Setelah objek perlu dideserialisasi (tidak diawetkan), list fungsi dipanggil dengan hanya satu argumen. list fungsi adalah konstruktor daftar dengan Python, dan fungsi itertools.count menghasilkan iterator nilai yang tak terbatas, dimulai dengan parameter yang diteruskan. Mengubah iterator tak terbatas menjadi daftar terbatas dapat memiliki konsekuensi yang merusak kinerja dan stabilitas sistem Anda.

Satu-satunya obat nyata untuk jenis kerentanan ini adalah memilih untuk tidak menghapus serial data yang berasal dari sumber eksternal. Jika hal ini tidak memungkinkan, disarankan untuk menggunakan checksum atau tanda tangan digital untuk mencegah deserialisasi data yang berpotensi dimodifikasi oleh pengguna jahat. Selain itu, coba siapkan lingkungan kotak pasir yang dipisahkan dari sistem utama Anda untuk membatasi efek masalah yang mungkin muncul.

Saat menggunakan pustaka eksternal untuk deserializing data, misalnya dari XML atau JSON, coba pilih yang memungkinkan Anda melakukan pemeriksaan tipe objek sebelum prosedur deserialisasi aktual dijalankan. Ini bisa menangkap jenis objek tak terduga yang tujuan utamanya adalah untuk merusak sistem Anda.

Seperti semua tindakan lain yang dilakukan aplikasi Anda, terapkan pencatatan dan pemantauan ekstensif. Deserialisasi yang sering terjadi atau gagal lebih dari biasanya adalah sinyal bahwa sesuatu yang buruk sedang terjadi. Tangkap masalah lebih awal.

Pencatatan dan Pemantauan Tidak Memadai

Berapa banyak waktu yang Anda habiskan untuk memastikan Anda mencatat semua peringatan dan kesalahan yang terjadi di aplikasi Anda? Apakah Anda hanya menyimpan kesalahan yang terjadi dalam kode atau apakah Anda juga mencatat kesalahan validasi? Apa yang terjadi jika aturan bisnis domain Anda tidak terpenuhi? Kegagalan untuk mempertahankan semua aktivitas yang salah dan mencurigakan dalam aplikasi Anda menghadirkan kompromi keamanan dan data.

Bayangkan skenario berikut. Aplikasi Anda berisi halaman masuk, seperti kebanyakan. Formulir memiliki dua bidang, satu untuk memasukkan email dan yang lainnya untuk kata sandi. Jika pengguna mencoba masuk dan mereka memberikan sandi yang salah, mereka dapat mencoba lagi. Sayangnya, jumlah upaya yang salah tidak dibatasi, sehingga halaman masuk tidak akan dikunci setelah N upaya yang gagal. Penyerang dapat memanfaatkan kesempatan ini dan, dengan satu email yang benar, terus memasukkan kata sandi dari tabel pelangi sampai satu kombinasi akhirnya berhasil. Asalkan aplikasi Anda cukup aman dan Anda meng-hash kata sandi sebelum memasukkannya ke dalam database, serangan khusus ini tidak akan berfungsi. Namun, apakah Anda memiliki mekanisme untuk mengidentifikasi penyusupan?

Hanya karena upaya yang satu ini gagal untuk membuka halaman masuk Anda, bukan berarti yang lain tidak. Halaman masuk mungkin juga bukan satu-satunya pintu belakang potensial yang Anda miliki. Jika bukan karena hal lain, seseorang mungkin mencoba menggunakan kontrol akses yang rusak terhadap Anda. Bahkan aplikasi yang dibuat dengan sempurna harus tahu bahwa seseorang sedang mencoba untuk menyerang mereka, meskipun itu mungkin tidak mungkin. Itu selalu begitu.

Untuk melakukan yang terbaik untuk melindungi diri Anda dari serangan semacam itu, lakukan langkah-langkah berikut:

• Catat semua kegagalan dan peringatan yang terjadi dalam aplikasi, baik itu pengecualian yang dilemparkan ke dalam kode atau kontrol akses, validasi, dan kesalahan manipulasi data. Semua informasi yang disimpan harus direplikasi dan bertahan cukup lama sehingga inspeksi dan analisis retrospektif dapat dilakukan.
• Menentukan format dan lapisan ketekunan adalah penting. Memiliki file besar dengan format teks arbitrer mudah dilakukan; memprosesnya nanti tidak. Pilih opsi penyimpanan yang memudahkan untuk menyimpan dan membaca data dan format yang memungkinkan serialisasi (de) yang mudah dan cepat. Menyimpan JSON dalam database yang memungkinkan akses cepat memudahkan penggunaan. Jaga agar basis data tetap kecil dengan mencadangkannya secara teratur.
• Jika Anda berurusan dengan data penting dan berharga, simpan jejak tindakan yang dapat diikuti untuk mengaudit keadaan akhir. Menerapkan mekanisme untuk mencegah gangguan data.
• Minta sistem latar belakang menganalisis log dan memperingatkan Anda jika terjadi sesuatu. Pemeriksaan—yang sesederhana pengujian jika pengguna berulang kali mencoba mengakses bagian aplikasi yang dilindungi—bantuan. Namun, jangan membebani sistem dengan pemeriksaan dummy. Sistem pemantauan harus dijalankan sebagai layanan terpisah dan tidak boleh mempengaruhi kinerja sistem utama.

Saat memecahkan masalah, berhati-hatilah agar tidak membocorkan log kesalahan ke pengguna eksternal. Gagal melakukannya membuat Anda rentan terhadap paparan informasi sensitif. Logging dan pemantauan akan membantu Anda dalam memecahkan masalah, bukan penyerang dalam melakukan pekerjaan mereka dengan lebih efisien.

Langkah selanjutnya

Menyadari potensi ancaman dan kerentanan dalam aplikasi web adalah penting. Lebih penting lagi untuk mulai mengidentifikasinya di aplikasi Anda dan menerapkan tambalan untuk menghapusnya.

Perhatian terhadap keamanan aplikasi merupakan bagian penting dari semua langkah proyek pengembangan perangkat lunak. Arsitek, pengembang, dan penguji perangkat lunak harus memasukkan prosedur pengujian perangkat lunak ke dalam alur kerja mereka. Adalah bermanfaat untuk memanfaatkan daftar periksa keamanan dan pengujian otomatis ke dalam langkah-langkah yang tepat dari proses pengembangan perangkat lunak untuk mengurangi risiko keamanan.

Baik Anda menganalisis aplikasi yang sudah ada atau mengembangkan aplikasi baru yang baru, Anda harus melihat Proyek Standar Verifikasi Keamanan Aplikasi (ASVS) OWASP. Tujuan dari proyek ini adalah untuk mengembangkan standar untuk verifikasi keamanan aplikasi. Standar menyebutkan pengujian dan persyaratan untuk mengembangkan aplikasi web yang aman. Tes diberikan tingkat dari satu hingga tiga, di mana satu berarti jumlah bahaya paling sedikit dan tiga berarti potensi ancaman tertinggi. Klasifikasi memungkinkan manajer aplikasi untuk memutuskan ancaman mana yang lebih mungkin dan penting. Tidak perlu menyertakan setiap pengujian dalam setiap aplikasi.

Baik proyek aplikasi web baru maupun yang sudah ada, terutama yang mengikuti prinsip Agile, mendapat manfaat dari perencanaan terstruktur upaya untuk mengamankan aplikasi mereka. Perencanaan tes ASVS OWASP lebih mudah jika Anda memutuskan untuk menggunakan Kerangka Pengetahuan Keamanan OWASP. Ini adalah aplikasi untuk mengelola sprint berorientasi pengujian keamanan, hadir dengan serangkaian contoh tentang cara memecahkan masalah keamanan umum, dan daftar periksa yang mudah diikuti berdasarkan OWASP ASVS.

Jika Anda baru saja mulai menjelajahi keamanan aplikasi web dan membutuhkan tempat bermain sandbox yang aman, gunakan implementasi aplikasi web dari OWASP—WebGoat. Ini adalah implementasi aplikasi web yang sengaja tidak aman. Aplikasi ini memandu Anda melalui pelajaran, dengan setiap pelajaran terkonsentrasi pada satu ancaman keamanan.

Selama pengembangan aplikasi, pastikan Anda:

• Identifikasi dan prioritaskan ancaman. Tentukan ancaman mana yang secara realistis dapat terjadi dan menimbulkan risiko bagi aplikasi Anda. Prioritaskan ancaman dan putuskan mana yang paling layak mendapatkan upaya pengembangan dan pengujian. Tidak ada gunanya melakukan banyak upaya untuk memecahkan pencatatan dan pemantauan yang tidak memadai jika Anda melayani blog statis.
• Evaluasi arsitektur dan desain aplikasi Anda. Beberapa kerentanan sangat sulit untuk dipecahkan selama fase pengembangan aplikasi selanjutnya. Misalnya, jika Anda bermaksud untuk mengeksekusi kode pihak ketiga, dan tidak memiliki rencana untuk menggunakan lingkungan kotak pasir, akan sangat sulit untuk mempertahankan diri dari serangan deserialisasi dan injeksi yang tidak aman.
• Perbarui proses pengembangan perangkat lunak. Pengujian terhadap ancaman aplikasi web harus, sebanyak mungkin, menjadi proses otomatis. Akan bermanfaat untuk menambah alur kerja CI/CD Anda dengan pengujian otomatis yang mencoba menemukan celah keamanan. Anda bahkan dapat menggunakan sistem pengujian unit yang ada untuk mengembangkan pengujian keamanan dan menjalankannya secara berkala.
• Pelajari dan tingkatkan. Daftar masalah dan kerentanan tidak statis dan jelas tidak terbatas pada sepuluh atau lima belas ancaman. Fungsi dan ide baru membuka pintu untuk jenis serangan baru. Penting untuk membaca tentang tren saat ini di dunia keamanan aplikasi web agar tetap terkini. Terapkan apa yang Anda pelajari; jika tidak, Anda membuang-buang waktu Anda.

Kesimpulan

Meskipun, seperti namanya, Proyek Sepuluh Teratas OWASP hanya mencantumkan sepuluh kerentanan keamanan, ada ribuan kemungkinan jebakan dan pintu belakang yang mengancam aplikasi Anda dan, yang terpenting, pengguna Anda dan data mereka. Pastikan untuk waspada dan terus-menerus menyegarkan pengetahuan Anda karena perubahan dan peningkatan teknologi memiliki kelebihan dan kekurangan.

Oh, dan, jangan lupa, dunia ini tidak hitam dan putih. Kerentanan keamanan tidak datang sendiri; mereka sering terjalin. Terkena satu sering berarti bahwa sekelompok orang lain ada di tikungan, menunggu untuk mengangkat kepala jelek mereka dan kadang-kadang, meskipun itu bukan salah Anda, sebagai pengembang keamanan sistem, Anda masih dimaksudkan untuk menambal celah untuk mengekang kejahatan dunia maya. Sebagai contoh, lihat Nomor Kartu Kredit yang Diretas Masih, Masih Bisa Google .