Lindungi kode Anda dengan sepuluh tips keamanan yang harus diketahui setiap pengembang

Anda akan mendapatkan halaman web dengan kotak dialog bertuliskan "Halo!" Anda mungkin berkata, "Jadi apa?" Bayangkan penyerang dapat mengelabui pengguna agar mengeklik tautan seperti ini, namun string kueri berisi beberapa skrip dan HTML yang sangat berbahaya, sehingga memperoleh cookie pengguna dan mengirimkannya ke situs web milik pengguna. penyerang; sekarang penyerang memiliki akses ke informasi cookie pribadi Anda, atau lebih buruk lagi.
Untuk menghindari hal ini, ada dua cara. Yang pertama adalah tidak mempercayai masukan dan membatasi secara ketat isi nama pengguna. Misalnya, Anda dapat menggunakan ekspresi reguler untuk memeriksa apakah nama hanya berisi subkumpulan karakter umum dan tidak terlalu besar. Cuplikan kode C# berikut menunjukkan cara melakukan langkah ini:

Regex r = new Regex(@"^[w]{1,40}$")

;
// Bagus! Talinya oke
} kalau tidak {
// tidak bagus! String tidak valid
}

Kode ini menggunakan ekspresi reguler untuk memverifikasi bahwa string hanya berisi 1 hingga 40 huruf atau angka. Ini adalah satu-satunya cara aman untuk menentukan apakah suatu nilai benar.
Tidak mungkin HTML atau skrip dapat menipu ekspresi reguler ini! Jangan gunakan ekspresi reguler untuk mencari karakter yang tidak valid dan menolak permintaan jika ditemukan karakter yang tidak valid tersebut, karena mudah untuk melewatkan sesuatu.

Tindakan pencegahan kedua adalah mengkodekan HTML semua masukan sebagai keluaran. Hal ini mengurangi tag HTML berbahaya menjadi karakter escape yang lebih aman. Anda dapat menggunakan HttpServerUtility.HtmlEncode di ASP.NET, atau Server.HTMLEncode di ASP untuk menghindari string yang berpotensi bermasalah.

4. Jangan meminta izin sa

Serangan kepercayaan input terakhir yang akan kita bahas adalah penyisipan kode SQL. Banyak pengembang menulis kode yang mengambil masukan dan menggunakan masukan tersebut untuk membuat kueri SQL yang berkomunikasi dengan penyimpanan data backend seperti Microsoft® SQL Server™ atau Oracle.

Perhatikan cuplikan kode berikut:

void DoQuery(string Id) {
SqlConnection sql=SqlConnectionbaru(@"sumber data=localhost;" +
"id pengguna=sa;kata sandi=kata sandi;");
sql.Buka();
sqlstring= "PILIH telah dikirim" +
" DARI pengiriman DIMANA id='" + Id + "'";
SqlCommand cmd = baru SqlCommand(sqlstring,sql);
•••
Kode ini memiliki tiga kelemahan serius. Pertama, membuat sambungan dari layanan Web ke SQL Server sebagai akun administrator sistem sa. Anda akan segera melihat kelemahannya. Poin kedua, perhatikan praktik cerdas menggunakan "kata sandi" sebagai kata sandi akun sa!
Namun kekhawatiran sebenarnya adalah rangkaian string yang menyusun pernyataan SQL. Jika pengguna memasukkan 1001 untuk ID, Anda mendapatkan pernyataan SQL berikut, yang sepenuhnya valid.

SELECT hasshipped FROM pengiriman WHERE id = '1001'

Namun penyerang jauh lebih kreatif dari itu. Mereka akan memasukkan "pengiriman tabel DROP '1001' --" untuk ID, yang akan menjalankan kueri seperti ini:
PILIH telah dikirim DARI
pengiriman DIMANA id = '1001'
DROP table pengiriman -- ';

Ini mengubah cara kerja kueri. Kode ini tidak hanya mencoba menentukan apakah sesuatu telah dikirimkan, tetapi juga menghapus (menghapus) tabel pengiriman! Operator -- adalah operator komentar dalam SQL, yang memudahkan penyerang membuat serangkaian pernyataan SQL yang valid namun berbahaya!
Saat ini, Anda mungkin bertanya-tanya bagaimana setiap pengguna dapat menghapus tabel di database SQL Server. Tentu saja Anda benar, hanya administrator yang dapat melakukan pekerjaan seperti itu. Tapi di sini Anda terhubung ke database sebagai sa, dan sa dapat melakukan apapun yang dia inginkan pada database SQL Server. Jangan pernah menyambung ke SQL Server sebagai sa dari aplikasi apa pun; pendekatan yang benar adalah menggunakan Otentikasi Terintegrasi Windows, jika sesuai, atau menyambungkan sebagai akun yang telah ditentukan sebelumnya dengan izin yang sesuai.

Memperbaiki masalah kode penyisipan SQL itu mudah. Dengan menggunakan prosedur dan parameter tersimpan SQL, kode berikut menunjukkan cara membuat kueri seperti itu - dan cara menggunakan ekspresi reguler untuk mengonfirmasi bahwa masukan valid, karena transaksi kami menetapkan bahwa ID pengiriman hanya boleh terdiri dari 4 hingga 10 digit:

Regex r = Regex baru(@"^d{4,10}$");
if (!r.Match(Id).Sukses)
melempar Pengecualian baru("ID Tidak Valid");

SqlConnection sqlConn= new SqlConnection(strConn);
string str="sp_Telah Dikirim";
SqlCommand cmd = baru SqlCommand(str,sqlConn);
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add("@ID",Id);

Buffer overflow, skrip lintas situs, dan serangan kode penyisipan SQL adalah contoh masalah input tepercaya. Semua serangan ini dimitigasi oleh mekanisme yang menganggap semua masukan berbahaya kecuali terbukti sebaliknya.
5. Perhatikan kode enkripsinya!

Mari kita lihat sesuatu yang mungkin mengejutkan kita. Saya menemukan bahwa lebih dari tiga puluh persen kode keamanan yang kami periksa memiliki kerentanan keamanan. Mungkin kerentanan paling umum adalah kode enkripsi Anda sendiri, yang mungkin rentan. Jangan pernah membuat kode enkripsi Anda sendiri, itu adalah tugas yang bodoh. Jangan berpikir bahwa hanya karena Anda memiliki algoritma enkripsi sendiri maka orang lain tidak dapat memecahkannya. Penyerang memiliki akses ke debugger, dan mereka juga memiliki waktu dan pengetahuan untuk menentukan cara kerja sistem - seringkali merusaknya dalam beberapa jam. Anda harus menggunakan Win32® CryptoAPI, namespace System.Security.Cryptography menyediakan sejumlah algoritma enkripsi yang sangat baik dan teruji.

6. Mengurangi kemungkinan diserang.

Jika lebih dari 90% pengguna tidak memintanya, suatu fitur tidak boleh diinstal secara default. Layanan Informasi Internet (IIS) 6.0 mengikuti rekomendasi penginstalan ini, yang dapat Anda baca di artikel Wayne Berry "Inovasi dalam Layanan Informasi Internet Memungkinkan Anda Menjaga Keamanan Data dan Proses Server," yang dirilis bulan ini. Ide di balik strategi instalasi ini adalah Anda tidak akan memperhatikan layanan yang tidak Anda gunakan, dan jika layanan tersebut berjalan, layanan tersebut dapat dieksploitasi oleh orang lain. Jika suatu fitur diinstal secara default, fitur tersebut harus dijalankan berdasarkan prinsip otorisasi paling sedikit. Artinya, jangan izinkan aplikasi berjalan dengan hak administrator kecuali diperlukan. Sebaiknya ikuti saran ini.

7. Gunakan prinsip otorisasi paling sedikit

Sistem operasi dan runtime bahasa umum memiliki kebijakan keamanan karena beberapa alasan. Banyak orang berasumsi bahwa alasan utama kebijakan keamanan ini ada adalah untuk mencegah pengguna melakukan tindakan yang merugikan secara sengaja: mengakses file yang tidak boleh mereka akses, mengkonfigurasi ulang jaringan agar sesuai dengan kebutuhan mereka, dan perilaku buruk lainnya. Ya, jenis serangan orang dalam ini umum terjadi dan perlu diwaspadai, namun ada alasan lain untuk tetap berpegang pada strategi keamanan ini. Artinya, membangun penghalang defensif di sekitar kode untuk mencegah pengguna membuat kekacauan di jaringan melalui tindakan yang disengaja atau (seperti yang sering terjadi) tidak disengaja. Misalnya, lampiran yang diunduh melalui email, ketika dijalankan pada mesin Alice, dibatasi pada sumber daya yang dapat diakses Alice. Jika lampiran berisi kuda Troya, strategi keamanan yang baik adalah membatasi kerusakan yang dapat ditimbulkannya.

Saat Anda merancang, membangun, dan menyebarkan aplikasi server, Anda tidak dapat berasumsi bahwa semua permintaan berasal dari pengguna yang sah. Jika orang jahat mengirimi Anda permintaan jahat (mudah-mudahan tidak) dan kode Anda berperilaku buruk, Anda ingin aplikasi Anda memiliki semua pertahanan yang memungkinkan untuk membatasi kerusakan. Oleh karena itu, kami yakin perusahaan Anda menerapkan kebijakan keamanan bukan hanya karena perusahaan tidak mempercayai Anda atau kode Anda, namun juga untuk melindungi dirinya dari kode luar yang berbahaya.

Prinsip otorisasi paling sedikit menyatakan bahwa izin minimum yang disyaratkan oleh kode harus diberikan dalam waktu sesingkat-singkatnya. Oleh karena itu, pasanglah sebanyak mungkin dinding pelindung di sekitar kode Anda setiap saat. Ketika sesuatu yang buruk terjadi - seperti yang dijamin oleh Hukum Murphy - Anda akan senang karena tembok pelindung tersebut ada. Oleh karena itu, berikut adalah beberapa metode khusus untuk menjalankan kode menggunakan prinsip otorisasi paling sedikit.

Pilih lingkungan aman untuk kode server Anda yang hanya mengizinkannya mengakses sumber daya yang diperlukan untuk melakukan tugasnya. Jika beberapa bagian kode Anda memerlukan izin tinggi, pertimbangkan untuk mengisolasi bagian kode tersebut dan menjalankannya secara terpisah dengan izin yang lebih tinggi. Untuk memisahkan kode ini dengan aman yang berjalan dengan informasi autentikasi sistem operasi berbeda, yang terbaik adalah menjalankan kode ini dalam proses terpisah (berjalan di lingkungan aman dengan hak istimewa lebih tinggi). Ini berarti Anda memerlukan komunikasi antar-proses (seperti COM atau Microsoft .NET remoting), dan Anda perlu merancang antarmuka ke kode tersebut untuk meminimalkan bolak-balik.

Jika Anda memisahkan kode ke dalam rakitan di lingkungan .NET Framework, pertimbangkan tingkat izin yang diperlukan untuk setiap bagian kode. Anda akan menemukan bahwa ini adalah proses yang mudah: Pisahkan kode yang memerlukan hak istimewa lebih tinggi ke dalam rakitan terpisah yang memberikan lebih banyak hak istimewa, sambil membiarkan sebagian besar rakitan lainnya berjalan dengan hak istimewa lebih rendah sehingga Anda dapat menambahkan lebih banyak penjaga di sekitar kode Anda. Saat melakukan ini, jangan lupa bahwa, karena tumpukan Keamanan Akses Kode (CAS), Anda membatasi izin tidak hanya pada rakitan Anda sendiri, tetapi juga pada rakitan mana pun yang Anda panggil.

Banyak orang membangun aplikasi mereka sendiri sehingga komponen baru dapat dipasang ke produk mereka setelah diuji dan tersedia bagi pelanggan. Mengamankan aplikasi jenis ini sangat sulit karena Anda tidak dapat menguji setiap jalur kode yang mungkin untuk menemukan bug dan lubang keamanan. Namun, jika aplikasi Anda dihosting, CLR menyediakan fitur luar biasa yang dapat digunakan untuk menutup titik ekstensibilitas ini. Dengan mendeklarasikan objek izin atau kumpulan izin dan memanggil PermitOnly atau Deny, Anda menambahkan tanda ke tumpukan Anda yang akan memblokir pemberian izin ke kode apa pun yang Anda panggil. Dengan melakukan ini sebelum memanggil plugin, Anda dapat membatasi tugas yang dapat dilakukan plugin tersebut. Misalnya, plugin untuk menghitung pembayaran cicilan tidak memerlukan akses apa pun ke sistem file. Ini hanyalah contoh lain dari hak istimewa yang paling rendah, di mana Anda melindungi diri Anda sendiri sebelumnya. Pastikan untuk mencatat pembatasan ini, dan ketahuilah bahwa plugin dengan hak istimewa lebih tinggi dapat menggunakan pernyataan Assert untuk menghindari pembatasan ini.

8. Waspadai pola kegagalan

dan terimalah. Yang lain benci menulis kode penanganan kesalahan seperti halnya Anda. Ada begitu banyak alasan mengapa kode bisa gagal, dan memikirkannya saja bisa membuat frustasi. Kebanyakan programmer, termasuk kami, lebih memilih untuk fokus pada jalur eksekusi normal. Di situlah pekerjaan benar-benar selesai. Mari selesaikan penanganan kesalahan ini secepat dan semudah mungkin, lalu lanjutkan ke baris kode sebenarnya berikutnya.

Sayangnya, emosi ini tidak aman. Sebaliknya, kita perlu lebih memperhatikan pola kegagalan dalam kode kita. Kode ini sering kali ditulis dengan sedikit perhatian mendalam dan sering kali tidak diuji sepenuhnya. Ingat kapan terakhir kali Anda benar-benar yakin telah men-debug setiap baris kode dalam suatu fungsi, termasuk setiap penangan kesalahan kecil di dalamnya?

Kode yang belum diuji sering kali menyebabkan kerentanan keamanan. Ada tiga hal yang dapat membantu Anda mengurangi masalah ini. Pertama, berikan perhatian yang sama kepada penangan kesalahan kecil itu seperti kode normal Anda. Pertimbangkan keadaan sistem saat kode penanganan kesalahan Anda dijalankan. Apakah sistem dalam keadaan efisien dan aman? Kedua, setelah Anda menulis sebuah fungsi, telusuri fungsi tersebut dan debug secara menyeluruh beberapa kali, pastikan untuk menguji setiap penangan kesalahan. Perhatikan bahwa bahkan dengan teknik seperti itu, kesalahan pengaturan waktu yang sangat halus mungkin tidak ditemukan. Anda mungkin perlu meneruskan parameter kesalahan ke fungsi Anda, atau menyesuaikan keadaan sistem dengan cara tertentu agar penangan kesalahan dapat dijalankan. Dengan meluangkan waktu untuk menelusuri kode Anda, Anda dapat memperlambat dan memiliki cukup waktu untuk melihat kode Anda dan status sistem Anda saat dijalankan. Dengan hati-hati menelusuri kode di debugger, kami menemukan banyak kelemahan dalam logika pemrograman kami. Ini adalah teknologi yang terbukti. Silakan gunakan teknik ini. Terakhir, pastikan rangkaian pengujian Anda menyebabkan fungsi Anda gagal. Cobalah untuk memiliki rangkaian pengujian yang memeriksa setiap baris kode dalam fungsi. Ini dapat membantu Anda mengenali pola, terutama saat mengotomatiskan pengujian dan menjalankannya setiap kali Anda membuat kode.

Ada satu hal yang sangat penting untuk dikatakan tentang mode kegagalan. Pastikan sistem Anda berada dalam kondisi seaman mungkin ketika kode Anda gagal. Beberapa kode yang bermasalah ditunjukkan di bawah ini:

bool accessGranted = true; // Terlalu optimis!
mencoba {
// Lihat apakah kita dapat mengakses c:test.txt
FileStream baru(@"c:test.txt",
FileMode.Buka,
FileAccess.Baca).Tutup();
}
tangkapan (SecurityException x) {
// Akses ditolak
accessGranted = salah;
}
menangkap (...) {
// Ada hal lain yang terjadi
}

Walaupun kita menggunakan CLR, kita tetap diperbolehkan mengakses file tersebut. Dalam hal ini, SecurityException tidak dilempar. Namun bagaimana jika, misalnya, Daftar Kontrol Akses Diskresioner (DACL) file tidak mengizinkan kita mengaksesnya? Pada saat ini, jenis pengecualian lain akan dilempar. Namun karena asumsi optimis pada baris kode pertama, kita tidak akan pernah mengetahui hal ini.
Cara yang lebih baik untuk menulis kode ini adalah dengan berhati-hati:

bool accessGranted = false;
mencoba {
// Lihat apakah kita dapat mengakses c:test.txt
FileStream baru(@"c:test.txt",
FileMode.Buka,
FileAccess.Baca).Tutup();
// Kalau kita masih di sini, bagus!
accessGranted = benar;
}
catch (...) {}

Ini akan lebih stabil karena betapa pun gagalnya kita, kita akan selalu kembali ke mode paling aman.
9. Peniruan Identitas sangat rentan

Saat menulis aplikasi server, Anda akan sering menggunakan, secara langsung atau tidak langsung, fitur praktis Windows yang disebut peniruan identitas. Peniruan identitas memungkinkan setiap thread dalam suatu proses berjalan di lingkungan keamanan yang berbeda, biasanya lingkungan klien. Misalnya, ketika pengalihan sistem file menerima permintaan file melalui jaringan, ia mengautentikasi klien jarak jauh, memeriksa untuk mengonfirmasi bahwa permintaan klien tidak melanggar DACL pada pembagian, dan kemudian melampirkan tanda klien ke thread yang menangani permintaan tersebut. . untuk mensimulasikan klien. Thread ini kemudian dapat mengakses sistem file lokal di server menggunakan lingkungan keamanan klien. Ini nyaman karena sistem file lokal sudah aman. Ia melakukan pemeriksaan akses dengan mempertimbangkan jenis akses yang diminta, DACL pada file, dan tanda peniruan identitas pada thread. Jika pemeriksaan akses gagal, sistem file lokal melaporkannya ke pengalihan sistem file, yang kemudian mengirimkan kesalahan ke klien jarak jauh. Hal ini tidak diragukan lagi nyaman untuk pengalihan sistem file, karena ia hanya meneruskan permintaan ke sistem file lokal dan membiarkannya melakukan pemeriksaan aksesnya sendiri, sama seperti jika kliennya adalah klien lokal.

Ini semua baik dan bagus untuk gateway sederhana seperti pengalihan file. Namun simulasi sering kali digunakan dalam aplikasi lain yang lebih kompleks. Ambil aplikasi web sebagai contoh. Jika Anda menulis program ASP klasik yang tidak dikelola, ekstensi ISAPI, atau aplikasi ASP.NET dan memiliki spesifikasi berikut dalam file Web.config-nya

maka lingkungan berjalan Anda akan memiliki dua lingkungan Keamanan yang berbeda: Anda akan memiliki tag proses dan tag thread. Secara umum, tag thread akan digunakan untuk pemeriksaan akses (lihat Gambar 3). Dengan asumsi Anda sedang menulis aplikasi ISAPI yang berjalan dalam proses server web, dan dengan asumsi bahwa sebagian besar permintaan tidak diautentikasi, tag thread Anda mungkin IUSR_MACHINE, namun tag proses Anda adalah SYSTEM! Misalkan kode Anda dapat dieksploitasi oleh pelaku kejahatan melalui buffer overflow. Apakah menurut Anda akan puas hanya dengan berjalan sebagai IUSR_MACHINE? Tentu saja tidak. Kode serangannya kemungkinan besar memanggil RevertToSelf untuk menghapus tanda peniruan identitas dengan harapan meningkatkan tingkat hak istimewanya. Dalam hal ini, dia akan berhasil dengan mudah. Dia juga dapat menghubungi CreateProcess. Itu tidak menyalin tag proses baru dari tag peniruan identitas, tetapi dari tag proses sehingga proses baru dapat berjalan sebagai SISTEM.

Lalu bagaimana cara mengatasi masalah kecil ini? Selain memastikan bahwa tidak ada buffer overflow yang terjadi, ingatlah prinsip otorisasi paling sedikit. Jika kode Anda tidak memerlukan hak istimewa sebesar SYSTEM, jangan konfigurasikan aplikasi web Anda untuk berjalan dalam proses server web. Jika Anda hanya mengonfigurasi aplikasi web Anda untuk berjalan di lingkungan isolasi menengah atau tinggi, tag proses Anda adalah IWAM_MACHINE. Anda sebenarnya tidak memiliki izin apa pun, jadi serangan ini hampir tidak berpengaruh. Perhatikan bahwa di IIS 6.0 (segera menjadi komponen Windows .NET Server), kode yang ditulis pengguna tidak akan dijalankan sebagai SISTEM secara default. Berdasarkan pemahaman bahwa pengembang memang melakukan kesalahan, bantuan apa pun yang dapat diberikan server web dalam mengurangi izin yang diberikan pada kode akan berguna jika ada masalah keamanan pada kode.

Inilah kendala lain yang mungkin dihadapi oleh pemrogram COM. COM memiliki kecenderungan buruk untuk mengabaikan thread. Jika Anda memanggil server COM yang sedang dalam proses dan model threadnya tidak cocok dengan model thread pemanggil, COM akan melakukan panggilan pada thread lain. COM tidak menyebarkan tanda peniruan identitas pada thread pemanggil, sehingga hasilnya adalah panggilan tersebut dieksekusi dalam konteks keamanan proses, bukan dalam konteks keamanan thread pemanggil. Sungguh mengejutkan!

Berikut contoh lain dari jebakan simulasi. Asumsikan bahwa server Anda menerima permintaan yang dikirim melalui pipa bernama, DCOM, atau RPC. Anda mengautentikasi klien dan meniru identitas mereka, membuka objek kernel atas nama mereka melalui peniruan identitas. Dan Anda lupa menutup salah satu objek (seperti file) ketika klien terputus. Saat klien berikutnya masuk, Anda mengautentikasi dan meniru identitasnya, dan coba tebak apa yang terjadi? Anda masih dapat mengakses file yang "dilewatkan" oleh klien sebelumnya, meskipun klien baru tidak mendapatkan akses ke file tersebut. Untuk alasan kinerja, kernel hanya melakukan pemeriksaan akses pada suatu objek saat pertama kali dibuka. Anda masih dapat mengakses file ini meskipun nanti Anda mengubah lingkungan keamanan karena Anda meniru identitas pengguna lain.

Situasi yang disebutkan di atas mengingatkan Anda bahwa simulasi memberikan kemudahan bagi pengembang server, namun kemudahan ini memiliki bahaya besar yang tersembunyi. Saat Anda menjalankan program dengan flag tiruan, pastikan untuk memperhatikan kode Anda dengan cermat.

10. Menulis aplikasi yang benar-benar dapat digunakan oleh pengguna non-admin

. Hal ini merupakan akibat wajar dari prinsip otorisasi paling sedikit. Jika pemrogram terus mengembangkan kode yang memerlukan administrator agar dapat berjalan dengan baik di Windows, kita tidak dapat berharap untuk meningkatkan keamanan sistem. Windows memiliki serangkaian fitur keamanan yang sangat solid, namun pengguna tidak dapat memanfaatkannya jika mereka harus menjadi administrator untuk mengoperasikannya.

Bagaimana Anda bisa meningkatkannya? Pertama, coba sendiri, tanpa menjalankannya sebagai administrator. Anda akan segera menyadari betapa sulitnya menggunakan program yang tidak dirancang dengan mempertimbangkan keamanan. Suatu hari, saya (Keith) menginstal perangkat lunak yang disediakan oleh produsen perangkat genggam saya yang menyinkronkan data antara komputer desktop dan perangkat genggam saya. Seperti biasa, saya keluar dari akun pengguna normal saya, masuk lagi menggunakan akun administrator bawaan, menginstal perangkat lunak, lalu masuk lagi ke akun normal saya, dan mencoba menjalankan perangkat lunak. Akibatnya, aplikasi memunculkan kotak dialog yang menyatakan bahwa file data yang diperlukan tidak dapat diakses, dan kemudian memberikan pesan pelanggaran akses. Teman, ini adalah produk perangkat lunak dari produsen perangkat genggam besar. Apakah ada alasan untuk kesalahan ini?