Apa yang harus diketahui oleh setiap programmer tentang keamanan? [Tutup]

427

Saya seorang mahasiswa IT dan saya sekarang memasuki tahun ke 3 di universitas. Hingga saat ini kami telah mempelajari banyak mata pelajaran yang terkait dengan komputer secara umum (pemrograman, algoritma, arsitektur komputer, matematika, dll).

Saya sangat yakin bahwa tidak ada yang bisa mempelajari segala sesuatu tentang keamanan tetapi yakin ada "minimum" pengetahuan yang harus diketahui oleh setiap programmer atau mahasiswa IT dan pertanyaan saya adalah apakah pengetahuan minimum ini?

Bisakah Anda menyarankan beberapa buku elektronik atau kursus atau apa pun yang dapat membantu memulai dengan jalan ini?

security 
— MH
sumber
6
— Thomas
118
Aturan # 1: Jangan pernah mempercayai input pengguna. Bahkan jika itu
— nenekmu
2
..dan utas ini juga memiliki informasi hebat - stackoverflow.com/questions/72394/…
— Sripathi Krishnan
pertanyaan saya bukan hanya tentang programmer dan kesalahan mereka, juga tentang IT dan mahasiswa ilmu komputer
— Mohamad Alhamoud
1
Tonton pesan kesalahan Anda. Meskipun Anda ingin menjadi ramah pengguna, perbedaan antara "Akun ini tidak ada" dan "Kata sandi tidak valid" dalam beberapa kasus bisa berbahaya.
— Michael Mior

Jawaban:

551

Prinsip yang perlu diingat jika Anda ingin aplikasi Anda aman:

  • Jangan pernah percaya masukan apa pun!
  • Validasi input dari semua sumber yang tidak tepercaya - gunakan daftar putih bukan daftar hitam
  • Rencanakan keamanan sejak awal - itu bukan sesuatu yang bisa Anda hubungkan pada akhirnya
  • Tetap sederhana - kompleksitas meningkatkan kemungkinan celah keamanan
  • Pertahankan agar permukaan serangan Anda menjadi minimum
  • Pastikan Anda gagal dengan aman
  • Gunakan pertahanan secara mendalam
  • Patuhi prinsip hak istimewa yang paling rendah
  • Gunakan pemodelan ancaman
  • Mengelompokkan - jadi sistem Anda tidak semuanya atau tidak sama sekali
  • Menyembunyikan rahasia itu sulit - dan rahasia yang tersembunyi dalam kode tidak akan tetap rahasia lama
  • Jangan menulis crypto Anda sendiri
  • Menggunakan crypto tidak berarti Anda aman (penyerang akan mencari tautan yang lebih lemah)
  • Waspadai buffer overflows dan cara melindunginya

Ada beberapa buku bagus dan artikel online tentang cara membuat aplikasi Anda aman:

Latih pengembang Anda tentang praktik terbaik keamanan aplikasi

Codebashing (berbayar)

Inovasi Keamanan (berbayar)

Kompas Keamanan (berbayar)

OWASP WebGoat (gratis)

— bignum
sumber
+1 "mengeksploitasi perangkat lunak: cara memecahkan kode" adalah buku yang bagus, namun tayangan slide yang Anda tautkan mengerikan.
— benteng
7
Namun, sayangnya hampir tidak mungkin untuk menerapkan prinsip hak istimewa yang paling rendah dalam sistem modern mana pun. Sebagai contoh, kernel Linux (sumber yang saya gunakan saat ini) mengandung lebih dari 9,4 juta baris kode C dan lebih dari 400 ribu baris perakitan, yang semuanya berjalan dalam konteks yang tidak dibatasi. Salah perhitungan sederhana (mungkin disengaja) di salah satu dari jutaan baris ini akan membahayakan keseluruhan sistem. Mungkin dalam satu atau dua abad mendatang sebuah solusi akan muncul, mungkin tidak, karena tidak ada yang benar-benar peduli untuk menciptakan OS / bahasa / kerangka kerja yang aman.
— L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
1
Saya akan menambahkan "Buku Panduan Peretas Aplikasi Web" ke daftar itu.
— aktif
34
Ganti "Jangan pernah percaya pada input pengguna!" ke "Jangan pernah percaya masukan apa pun!". Input yang berasal dari perangkat lunak lain harus diperlakukan sama dengan input pengguna - misalnya, dalam pembuatan log situs web kebanyakan orang tidak akan menganggap bidang User-Agent / browser ID sebagai 'input pengguna' tetapi dapat dengan mudah berisi, katakanlah, a Injeksi SQL.
— Peteris
2
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Ya, ada OS eksperimental Microsoft Research (Singularity) yang dibangun di atas .NET, yang menargetkan keselamatan sebagai tujuan utama (tidak ada buffer yang meluap, ya!). Tidak ada proses berbagi memori, tidak ada modifikasi kode diri, bahkan driver perangkat hanyalah proses terisolasi perangkat lunak lain di .NET. Konsep yang cukup menarik, tetapi akan sangat sulit untuk mendorong ini kepada orang-orang (yang paling penting, itu cukup banyak tidak dapat melakukan kompatibilitas dengan perangkat lunak yang ada atau bahkan driver; agak seperti 10 tahun pertama Linux: D).
— Luaan
102

Aturan # 1 keamanan untuk programmer: Jangan menggulung sendiri

Kecuali jika Anda sendiri seorang pakar keamanan dan / atau ahli kriptografi, selalu gunakan platform, kerangka kerja, atau perpustakaan keamanan yang dirancang dengan baik, dan matang untuk melakukan pekerjaan untuk Anda. Hal-hal ini telah bertahun-tahun dipikirkan, ditambal, diperbarui, dan diperiksa oleh para ahli dan peretas. Anda ingin mendapatkan keuntungan itu, tidak mengabaikannya dengan mencoba menciptakan kembali roda.

Sekarang, itu tidak berarti Anda tidak perlu belajar apa pun tentang keamanan. Anda tentu perlu cukup tahu untuk memahami apa yang Anda lakukan dan pastikan Anda menggunakan alat dengan benar. Namun, jika Anda menemukan diri Anda akan mulai menulis algoritma kriptografi Anda sendiri, sistem otentikasi, pembersih input, dll, berhentilah, mundur selangkah, dan ingat aturan # 1.

— Tyler McHenry
sumber
10
Ini adalah aturan yang buruk menurut saya. Anda pada dasarnya dapat ditargetkan hanya karena platform yang Anda pilih, daripada kepentingan nyata dalam aset Anda. Pikirkan semua lubang keamanan yang ditemukan di platform pihak ke-3, dan semua produk yang rentan secara instan hanya karena mereka menggunakannya. Saya tidak akan begitu cepat untuk mempercayai keamanan saya ke pihak ke-3.
— Fosco
9
Saya pikir ini adalah aturan yang baik untuk Crypto - menggulirkan enkripsi Anda sendiri adalah resep untuk bencana. Tetapi menggulung mesin blog Anda sendiri mungkin lebih aman seperti yang ditunjukkan Fosco - jika Anda menggulungnya sendiri, Anda cenderung tidak akan terkena serangan otomatis yang harus dihadapi oleh instalasi wordpress.
— James P McGrath
5
Ketika menyangkut crypto, aturan ini benar sekali. Jangan menulis crypto Anda sendiri, titik. Ketika datang untuk menggunakan platform pihak ke-3, itu tergantung. Beberapa platform secara inheren lebih aman, beberapa platform secara inheren kurang aman, dan sebagian besar platform mungkin menyediakan beberapa fitur keamanan tetapi juga beberapa vektor serangan yang dikenal. Ambil kerentanan Rails terbaru yang menyebabkan lubang keamanan di github . Tidak diragukan lagi Rails menyediakan banyak fitur keamanan, tetapi ia juga memiliki beberapa fitur canggih dengan default tidak aman.
— Michael Kopinsky
7
Ketika datang ke crypto, jangan roll sendiri - tetapi mengerti hal yang Anda gunakan. Jika Anda tidak mengerti mengapa menggunakan kunci enkripsi yang sama untuk RC4 untuk dua pesan adalah ide yang buruk, baca sebelum menggunakan stream cipher, misalnya.
— Christopher Creutzig
3
Bahkan setelah bug HeartBleed tampak jelas ini adalah aturan yang baik. Bayangkan betapa sulitnya menemukan bug seperti kepanasan dalam proyek kustom atau eksklusif. Jika Anda memutar sendiri, Anda hanya bersembunyi di balik ketidakjelasan dan tidak akan tahu bug apa yang bisa dieksploitasi.
— Sqeaky
71

Setiap programmer harus tahu cara menulis kode exploit.

Tanpa mengetahui bagaimana sistem dieksploitasi, Anda secara tidak sengaja menghentikan kerentanan. Mengetahui cara menambal kode sama sekali tidak ada artinya kecuali Anda tahu cara menguji tambalan Anda. Keamanan bukan hanya sekelompok eksperimen pikiran, Anda harus ilmiah dan menguji eksperimen Anda.

— rook
sumber
10
Saya berpendapat ini tidak perlu sama sekali. Patuhi saja prinsipnya: jika penyerang dapat menyebabkan memori rusak dalam bentuk apa pun, anggaplah diri Anda miliknya. Tidak perlu masuk ke rincian sebenarnya menulis eksploitasi (bekerja).
— berita baru
6
@newgre tidak setiap kerentanan adalah buffer overflow. Ada beberapa ribu kerentanan yang dicakup oleh sistem Enumerasi Kelemahan Umum. Seorang programmer perlu memahami pikiran penyerang atau dia tidak tahu akan melakukan kesalahan.
— Benteng
1
Saya tahu bahwa tidak semua dari mereka adalah buffer overflow, tetapi apa pun yang biasanya disebut sebagai "exploit" didasarkan pada beberapa jenis kerusakan memori: buffer overflows, double-frees, heap overflow, integer terkait overflow, format string , dll. Tentu saja ada hal-hal lain seperti bug logika, tapi itu bukan topik jawaban ini untuk memulai.
— berita baru
5
@newgre Itu adalah salah satu jenis eksploit, tetapi saat ini lebih banyak eksploit ditulis untuk meningkatkan kelemahan aplikasi web daripada masalah korupsi memori. Eksploitasi ditulis menggunakan SQL Injection, File Lokal termasuk, CSRF, dan XSS, ini adalah masalah umum. (Sumber: exploit-db.com )
— rook
1
Saya setuju untuk itu, jika Anda sendiri dapat menulis eksploit, Anda dapat memahami apa yang bisa masuk ke pikiran peretas maksimal!
— linuxeasy
42

Keamanan adalah proses, bukan produk.

Banyak yang tampaknya melupakan fakta yang jelas ini.

— ericteubert
sumber
23

Saya sarankan meninjau CWE / SANS TOP 25 Kesalahan Pemrograman Paling Berbahaya . Itu diperbarui untuk 2010 dengan janji pembaruan reguler di masa depan. The 2009 Revisi juga tersedia.

Dari http://cwe.mitre.org/top25/index.html

Kesalahan Pemrograman Paling Top 25 CWE / SANS 2010 adalah daftar kesalahan pemrograman paling luas dan kritis yang dapat menyebabkan kerentanan perangkat lunak yang serius. Mereka sering mudah ditemukan, dan mudah dieksploitasi. Mereka berbahaya karena mereka sering memungkinkan penyerang mengambil alih sepenuhnya perangkat lunak, mencuri data, atau mencegah perangkat lunak bekerja sama sekali.

Daftar Top 25 adalah alat untuk pendidikan dan kesadaran untuk membantu programmer untuk mencegah jenis kerentanan yang mengganggu industri perangkat lunak, dengan mengidentifikasi dan menghindari kesalahan yang terlalu umum yang terjadi sebelum perangkat lunak bahkan dikirim. Pelanggan perangkat lunak dapat menggunakan daftar yang sama untuk membantu mereka meminta perangkat lunak yang lebih aman. Para peneliti dalam keamanan perangkat lunak dapat menggunakan 25 Teratas untuk fokus pada subset yang sempit namun penting dari semua kelemahan keamanan yang diketahui. Akhirnya, manajer perangkat lunak dan CIO dapat menggunakan daftar Top 25 sebagai tolok ukur kemajuan dalam upaya mereka untuk mengamankan perangkat lunak mereka.

— Jschmier
sumber
1
Perhatikan bahwa 4 kesalahan teratas pada daftar itu (dan banyak yang lainnya juga) semuanya merupakan input yang sama dengan kesalahan - kepercayaan.
— Chris Dodd
13

Kursus pemula yang baik mungkin kursus MIT di Jaringan Komputer dan Keamanan . Satu hal yang saya sarankan adalah untuk tidak melupakan privasi. Privasi, dalam beberapa hal, sangat mendasar untuk keamanan dan tidak sering dibahas dalam kursus teknis tentang keamanan. Anda mungkin menemukan beberapa materi tentang privasi dalam kursus ini tentang Etika dan Hukum yang berkaitan dengan internet.

— tvanfosson
sumber
Tautan program MIT tidak berfungsi
— AntonioCS
1
Tautan diperbaiki (untuk saat ini). Terima kasih.
— tvanfosson
8

Pentingnya default aman dalam kerangka kerja dan API:

  • Banyak kerangka kerja web awal tidak lepas dari html secara default di templat dan mengalami masalah XSS karena hal ini
  • Banyak kerangka kerja web awal membuatnya lebih mudah untuk menggabungkan SQL daripada membuat query parameter yang mengarah ke banyak bug injeksi SQL.
  • Beberapa versi Erlang (R13B, mungkin yang lain) tidak memverifikasi sertifikat rekan ssl secara default dan mungkin ada banyak kode erlang yang rentan terhadap serangan SSL MITM
  • Transformator XSLT Java secara default memungkinkan eksekusi kode java yang arbitrer. Ada banyak bug keamanan serius yang dibuat oleh ini.
  • API parsing XML Java secara default memungkinkan dokumen yang diurai untuk membaca file arbitrer pada sistem file. Lebih menyenangkan :)
— benmmurphy
sumber
5

Anda harus tahu tentang tiga A. Otentikasi, Otorisasi, Audit. Kesalahan klasik adalah untuk mengotentikasi pengguna, sementara tidak memeriksa apakah pengguna berwenang untuk melakukan beberapa tindakan, sehingga pengguna dapat melihat foto pribadi pengguna lain, kesalahan yang dilakukan Diaspora. Banyak, lebih banyak lagi orang yang lupa tentang Audit, Anda perlu, dalam sistem yang aman, untuk dapat mengetahui siapa melakukan apa dan kapan.

— rapadura
sumber
1
Tidak semua otorisasi memerlukan otentikasi. "Dari ABAC ke ZBAC" kontras dengan kontrol akses NBAC (otentikasi) dengan solusi yang tidak memerlukan otentikasi. "IBAC, RBAC, ABAC, dan bahkan CBAC - Kontrol Akses Berbasis Klaim semua bergantung pada otentikasi ... Untuk kesederhanaan makalah ini memperlakukan mereka sebagai solusi tunggal dan mengabaikan versi yang telah menerapkan aspek arsitektur ZBAC. Mereka secara kolektif disebut sebagai autheNtikasi Berbasis Akses Kontrol (NBAC). "
— Mike Samuel
4
  • Ingat bahwa Anda (programmer) harus mengamankan semua bagian, tetapi penyerang hanya harus berhasil menemukan satu ketegaran di baju besi Anda.
  • Keamanan adalah contoh "tidak dikenal tidak dikenal". Terkadang Anda tidak akan tahu apa kelemahan keamanan yang mungkin terjadi (sampai sesudahnya).
  • Perbedaan antara bug dan lubang keamanan tergantung pada kecerdasan penyerang.
— Rory
sumber
4

Saya akan menambahkan yang berikut ini:

  • Bagaimana tanda tangan digital dan sertifikat digital bekerja
  • Apa itu sandboxing?

Memahami bagaimana berbagai vektor serangan bekerja:

  • Buffer overflows / underflows / etc pada kode asli
  • Insinyur sosial
  • Spoofing DNS
  • Manusia di tengah
  • CSRF / XSS et al
  • Injeksi SQL
  • Serangan Crypto (mis: mengeksploitasi algoritma crypto yang lemah seperti DES)
  • Kesalahan program / kerangka kerja (mis: cacat keamanan terbaru github )

Anda dapat dengan mudah google untuk semua ini. Ini akan memberi Anda dasar yang baik. Jika Anda ingin melihat kerentanan aplikasi web, ada proyek bernama google gruyere yang menunjukkan kepada Anda cara mengeksploitasi aplikasi web yang berfungsi.

— Miguel Ping
sumber
4

ketika Anda sedang membangun perusahaan atau perangkat lunak Anda sendiri, Anda harus berpikir seperti seorang peretas. Seperti kita tahu peretas juga tidak ahli dalam semua hal, tetapi ketika mereka menemukan kerentanan mereka mulai menggali ke dalamnya dengan mengumpulkan informasi tentang semua hal-hal dan akhirnya menyerang perangkat lunak kami. jadi untuk mencegah serangan seperti itu kita harus mengikuti beberapa aturan terkenal seperti:

  • selalu mencoba untuk memecahkan kode Anda (gunakan cheatsheets & google hal untuk informasi lebih lanjut).
  • diperbarui untuk kelemahan keamanan di bidang pemrograman Anda.
  • dan sebagaimana disebutkan di atas tidak pernah percaya pada jenis input pengguna atau otomatis.
  • gunakan aplikasi opensource (sebagian besar kelemahan keamanannya diketahui dan dipecahkan).

Anda dapat menemukan lebih banyak sumber daya keamanan di tautan berikut:

untuk informasi lebih lanjut google tentang alur keamanan vendor aplikasi Anda.

— rahul_pratap
sumber
3
  1. Mengapa itu penting?
  2. Ini semua tentang pertukaran.
  3. Kriptografi sebagian besar merupakan gangguan dari keamanan.
— Richard
sumber
3

Untuk informasi umum tentang keamanan, saya sangat merekomendasikan membaca Bruce Schneier . Dia punya situs web, buletin crypto-gram-nya , beberapa buku , dan telah melakukan banyak wawancara .

Saya juga akan terbiasa dengan rekayasa sosial (dan Kevin Mitnick ).

Untuk buku yang bagus (dan sangat menghibur) tentang bagaimana keamanan bermain di dunia nyata, saya akan merekomendasikan yang sangat baik (walaupun agak ketinggalan jaman) 'The Cuckoo's Egg' oleh Cliff Stoll.

— Dan Esparza
sumber
3

Pastikan juga untuk memeriksa Daftar Top 10 OWASP untuk kategorisasi semua vektor / kerentanan serangan utama.

Hal-hal ini menarik untuk dibaca. Belajar berpikir seperti seorang penyerang akan melatih Anda tentang apa yang harus dipikirkan saat Anda menulis kode Anda sendiri.

— Michael Kopinsky
sumber
2

Garam dan hash kata sandi pengguna Anda. Jangan pernah menyimpannya dalam plaintext di basis data Anda.

— Abdull
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.