Analisis Kode Sumber Statis untuk Aplikasi Web, Kasing

Tren dan Temuan

Selama beberapa tahun terakhir, kami telah mengidentifikasi sejumlah fitur dan tren umum dalam keamanan sistem, serangan jahat, dan pengujian aplikasi web umum. Dari jumlah tersebut, sejumlah masalah pengujian keamanan menarik perhatian dan dapat diatasi dari waktu ke waktu melalui pendekatan yang ditargetkan.

Dalam 18 bulan terakhir kami telah melakukan respons insiden dan manajemen insiden untuk sejumlah besar klien besar. Melalui ini, jelas bahwa sekitar 50% dari kompromi yang telah terjadi telah melakukannya melalui serangan tingkat aplikasi. Secara umum, akar penyebab serangan itu adalah:

1. Vendor menyediakan perangkat lunak (termasuk dari rak dan custom) yang memiliki sejumlah ketidakamanan dan kerentanan perangkat lunak yang tidak disadari oleh pelanggan

2. Satu kesalahan konfigurasi yang menghasilkan kompromi penuh yang mengindikasikan kurangnya pertahanan dalam strategi dan implementasi yang mendalam

Poin lain yang kami amati adalah:

Serangan tingkat Server dan Sistem Operasi cenderung meningkat, dengan perusahaan besar secara signifikan lebih buruk daripada perusahaan kecil dalam mengelola kerentanan dan ketidakamanan.

Hanya ada sedikit serangan “zero-day”; sebagian besar serangan adalah hasil dari serangan pemindaian alat otomatis.

Deteksi serangan berada dalam kepalang utama, dengan kompromi hanya terdeteksi sebagai akibat dari perilaku menyimpang oleh sistem.

Kami juga telah melakukan sejumlah besar pengujian intrusi jaringan dan aplikasi (pengujian penetrasi) selama beberapa tahun terakhir, dengan sejumlah tren yang muncul:

Pengujian tingkat infrastruktur mengalami pengurangan rasa tidak aman, sebagian besar disebabkan oleh tren peningkatan seputar manajemen kerentanan.

Penerapan aplikasi web oleh klien (baru) baru cenderung memiliki sejumlah besar masalah keamanan aplikasi web, dengan segala sesuatu mulai dari basis data yang terpapar hingga serangan tingkat injeksi SQL dimungkinkan. Pengujian lebih lanjut dari waktu ke waktu menunjukkan bahwa hubungan dengan perusahaan keamanan untuk tujuan pengujian keamanan sumber menghasilkan pengurangan rasa tidak aman dalam aplikasi web.

“Semakin besar mereka, semakin sulit mereka jatuh”. Tampaknya ada kecenderungan yang pasti terhadap perusahaan-perusahaan besar yang memiliki jumlah rasa tidak aman yang lebih tinggi, khususnya dalam ruang aplikasi web. Akar penyebab ini tidak jelas; namun ada hubungan dengan outsourcing, dan perlunya organisasi besar untuk “mengamankan semuanya”. Ini juga berlaku untuk perusahaan kecil; namun perusahaan kecil cenderung memiliki infrastruktur yang jauh lebih sedikit untuk dikhawatirkan.

Tentu saja kita telah melihat manajemen dan analisis kerentanan mulai diterapkan dalam organisasi; Namun itu hanya benar-benar jaringan, sistem operasi, dan tingkat server yang sedang dikerjakan oleh sebagian besar perusahaan. Ini sebagian besar didasarkan pada gagasan bahwa pemindaian kerentanan dan produk dan layanan remediasi semakin matang di ruang ini. Tentu saja sementara ada alat yang matang dalam ruang pengujian keamanan aplikasi, mereka masih cukup reaktif, dan akan memakan waktu beberapa tahun untuk menjadi dewasa dan mainstream.

Dari riset kerentanan dan analisis yang telah kami lakukan, tampak jelas bahwa pengembangan aplikasi masih buruk dalam hal keamanan. Tidak semua ini dapat disalahkan langsung pada pengembang; dengan begitu banyak tekanan untuk mengeluarkan produk, keamanan sering diberikan kursi belakang. Kita juga perlu fokus melatih para pengembang perangkat lunak kita untuk membuat kode dengan aman, tetapi saat ini kita sedang melakukan pekerjaan yang buruk. Sejumlah kerentanan keamanan lapisan aplikasi yang kita lihat di rak dan sistem sumber terbuka hanyalah contoh baru kerentanan yang sudah terkenal. Berapa lama kita tahu tentang buffer overflows dan masalah injeksi SQL? Jadi mengapa kita masih melihat mereka? Untuk diskusi lebih lanjut tentang beberapa hal ini, lihat presentasi Ruxcon dari Brett Moore tentang “bug yang sama, aplikasi yang berbeda”.

Sebagai catatan terakhir untuk bagian ini, sebagai sebuah organisasi kami benar-benar hebat dalam pengujian aplikasi dan analisis kode sumber, tetapi benar-benar benci menjadi orang yang merusak sistem 2 hari sebelum dijadwalkan untuk ditayangkan. Statistik ada di sana; rancang keamanan pada tahap awal proyek, dan biaya serta dampak remediasi jauh lebih sedikit daripada mencoba memperbaikinya saat Anda baru akan meluncurkannya, dan secara dramatis lebih murah daripada mencoba memperbaikinya sekali dalam produksi. Kami mulai melihat tren menuju kepatuhan dan jaminan keamanan mendaki rantai nilai siklus hidup pengembangan sistem. Lama semoga terus …!

Ranjang bayi

Jadi siapa yang menguji produk vendor (Common Off The Shelf) untuk masalah keamanan aplikasi web sebelum dimasukkan ke dalam lingkungan produksi? Khususnya di mana sebelumnya telah digunakan ke situs klien lain? Betulkah? Berapa banyak dari Anda yang meninjau keamanan kode sumber dalam kode yang dikembangkan oleh agen outsourcing Anda dan / atau tim pengembangan?

Kami telah melihat yang baik dan yang buruk di ruang ini. Dalam sejumlah kasus, kami telah menguji dan merusak aplikasi web yang digunakan secara luas di seluruh dunia, dan ternyata sangat kurang. Ini tidak selalu hanya sebuah plug untuk seberapa baik kita; ini lebih merupakan tuduhan terhadap kurangnya pengujian keamanan aplikasi yang dilakukan oleh perusahaan lain yang telah membeli dan mengimplementasikan produk-produk ini. Sungguh teman-teman, beberapa serangan dan eksploitasi hanyalah dasar biasa …

Pesannya adalah setidaknya untuk melakukan review kode sumber jika memungkinkan, atau tes intrusi aplikasi di mana Anda bisa. Sistem COTS tidak otomatis aman hanya karena seberapa luas mereka dikerahkan. Jika Anda khawatir tentang keamanan suatu produk, minta pengembang untuk merilis kode sumber kepada Anda untuk jaminan dan pengujian. Berdasarkan temuan kami, setidaknya 20-30% dari aplikasi web (baik COTS disediakan atau di-outsource) memiliki kerentanan signifikan.

Bagaimana dengan pengembangan aplikasi outsourcing Anda? Tentu saja Anda menyadari bahwa Anda bertanggung jawab atas keamanan perangkat lunak yang buruk dan melakukan audit kode sumber dengan tepat ketika kode dikirimkan? Serius meskipun, ada kurangnya due diligence dalam meninjau sistem yang disampaikan baik pada tingkat

www.technicaltalk.net atau kode sumber, yang kami percaya alasan utamanya adalah kurangnya akuntabilitas yang diterapkan, dan (hingga saat ini) hal ini belum tentu murah untuk diuji. Masalah besar lainnya yang kami temukan adalah kurangnya standar pengujian keamanan, dan standar keamanan dalam pengembangan aplikasi.

Produk dan alat mencapai titik di mana dimungkinkan sekarang untuk melakukan pemeriksaan kepatuhan yang wajar dan audit keamanan terhadap sistem vendor / pemasok yang disediakan tanpa biaya yang melekat terkait dengan audit kode sumber manual. Ukur kinerja mereka! Pertanggungjawaban bukanlah sesuatu yang dapat di-outsourcing-kan dengan mudah, dan praktik yang wajar adalah memastikan bahwa kontrak Anda dengan vendor / agen outsourcing Anda setidaknya mencakup ekspektasi Anda akan standar dan praktik pengkodean web (atau setidaknya meninjau dan meneliti dengan cermat), dan melakukan beberapa bentuk kepatuhan memeriksa standar-standar ini terhadap kode yang disampaikan. Bagaimana jika Anda tahu apakah aplikasi yang dikirim aman? Kepercayaan buta dan iman?

Sumber Terbuka

Ada beberapa perdebatan signifikan mengenai keamanan sistem sumber terbuka atau tertutup dan jelas bahwa, dalam ruang keamanan aplikasi web khususnya, tampaknya tidak ada perbedaan yang signifikan. Dari ulasan kode kami menggunakan CodeScan, jumlah masalah yang ditemukan dalam produk COTS dan Open Source tampak serupa.

Di seluruh aplikasi Open Source yang telah kami uji dengan CodeScan, kami menemukan semua tersangka umum; Cross Site Scripting merajalela, dan SQL Injection masih ada untuk derajat yang agak menarik. Dan sistem ini digunakan dan dieksploitasi secara global. Kami akan merilis saran dan statistik terhadap temuan kerentanan kami dalam aplikasi web open source, khususnya dalam ruang ASP dan PHP segera, jadi perhatikan ruang ini!

Beberapa masalah yang sangat menarik muncul dari penggunaan aplikasi Open Source. Meskipun ini merupakan cara penting untuk menempatkan aplikasi yang bermanfaat ke dalam ruang online, jelas bahwa tingkat pengawasan keamanan yang ditempatkan pada aplikasi web tidak cukup. Pada dasarnya, kontributor untuk proyek-proyek ini berfokus pada fungsionalitas dan fitur aplikasi, dan masalah keamanan tidak mendapatkan tingkat perhatian atau audit yang diperlukan. Sebagian penyebabnya adalah kurangnya kepatuhan atau alat otomatis yang dapat memberikan pengembalian cepat atas masalah tersebut; itu adalah salah satu kekuatan pendorong di belakang CodeScan kami yang dikembangkan untuk digunakan sendiri dalam mengotomatisasi beberapa analisis kode sumber.

Masalah lain yang sangat menarik yang muncul dari komunitas Open Source adalah bahwa sebagian besar tim pengembangan secara global menggunakan teknik “cut and paste” untuk memasukkan fungsionalitas ke dalam pengembangan aplikasi mereka sendiri. Ini memiliki keuntungan untuk memungkinkan pengembangan perangkat lunak / aplikasi web yang relatif cepat terjadi, tetapi ujung lain dari pedang adalah bahwa itu juga dapat menduplikasi kode yang berpotensi tidak aman. Berapa banyak orang yang benar-benar melakukan audit kode sumber terhadap kode yang mereka impor untuk menentukan bahwa mereka sebenarnya tidak mengimpor kerentanan ke dalam aplikasi mereka pada saat yang sama ketika mereka membawa fungsionalitas?

Alat dan Tren

Proaktif vs reaktif; bug perlu dihancurkan dalam pengembangan. Ada sejumlah vendor, termasuk kami, yang bergerak menjauh dari pengurangan eksposur dan masalah yang lebih tradisional dan lebih ke pencegahan kerentanan yang dikembangkan dalam sistem. Pengujian kerentanan aplikasi dapat diterapkan pada aplikasi produksi, dan alat tambahan diimplementasikan untuk mengontrol visibilitas dan eksploitasi kerentanan perangkat lunak (deteksi / pencegahan intrusi, firewall yang sadar aplikasi, sistem manajemen tambalan, dll), tetapi semuanya masih bersifat reaktif. Jika Anda mencoba untuk memperbaiki masalah keamanan perangkat lunak, mengapa tidak mengembangkannya agar aman? Security At The Source adalah satu-satunya ukuran proaktif sejati yang akan menghasilkan sistem yang aman dari waktu ke waktu.

Pengujian yang didorong oleh kebijakan keamanan juga muncul sebagai tren kebutuhan. Kami terus melihat driver untuk dapat dengan mudah menguji kebijakan keamanan standar dan kustom dalam pengembangan aplikasi web. Mengapa pelanggan harus memasang kode yang bahkan tidak mematuhi kebijakan mereka sendiri atau pengembang mereka untuk pengembangan yang aman?

Ada juga kecenderungan besar dari pengujian aplikasi statis sebelum produksi menuju menggabungkan pengujian keamanan dan pengukuran kepatuhan di seluruh siklus hidup pengembangan perangkat lunak. Ada sejumlah penelitian yang dilakukan yang mengidentifikasi hal ini secara khusus, dan biaya untuk perbaikan kode buruk dalam sistem produksi telah terbukti tinggi.

“Sekitar 40-100 kali lebih mahal untuk memperbaiki masalah pada fase pemeliharaan suatu program daripada pada fase desain.”

Ada juga kecenderungan kuat sekarang untuk melihat bagaimana keamanan dapat dirancang, dan diuji sebagai bagian dari keseluruhan lingkungan pengujian perangkat lunak. Mengapa tidak mulai menguji keamanan kode pada fase prototipe? Masalah dan masalah yang terkait dengan desain jauh lebih mudah untuk diambil dan diperbaiki pada tahap itu. Kami telah melihat (secara anekdot) penurunan yang signifikan dalam biaya pengujian keamanan awal vs pengujian di negara “ready to go live”. Terlalu sering pengujian pada akhirnya akan menghasilkan “kami akan memperbaiki keamanan di versi berikutnya” atau alasan lumpuh yang serupa, dengan masalah keamanan tidak ditangani, atau dieksploitasi di negara produksi. Tidak hebat, tetapi situasinya pasti membaik.

Manajemen kepatuhan mungkin akan menjadi driver “besar” berikutnya untuk kepatuhan perangkat lunak. Sudah kita telah melihat semakin banyak peraturan yang memberatkan mengontrol audit dan pelaporan (Basel II, Sarbanes – Oxley) dan privasi (Gramm – Leach – Blilley, HIPAA, Undang-Undang Privasi Australia), ISO 17799, dan perdagangan (program MasterCard / Visa AIS) mendorong adopsi pedoman praktik terbaik TI yang komprehensif, yang pada intinya merupakan audit andal dan pengukuran kepatuhan yang sesuai dengan baseline minimum. Sebagai contoh, MasterCard SDP berupaya menguji kerentanan OWASP Top 10 di aplikasi web khusus atau yang disesuaikan. Tren ini kemungkinan akan berlanjut, dengan kepatuhan mendorong sejumlah perubahan perilaku dalam organisasi dan pengembangan perangkat lunak.

Ringkasan Akhir

Saat ini, dalam lingkungan ini, metode pemindaian kerentanan yang ada, termasuk ulasan manual, tidak akan memotongnya. Saat ini, sebagai profesional keamanan, kami khawatir tentang masalah ini. Ketika undang-undang yang baru dan yang baru muncul ini menerapkan praktik yang sudah mapan, carilah keamanan untuk melekatkan diri dengan kuat dengan staf jaminan kualitas, perancang aplikasi, dan akhirnya para programmer sendiri, untuk menjadi lebih terlibat dalam mengelola keamanan perangkat lunak dan memastikan kepatuhan.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *