it-swarm-id.com

Bagaimana saya bisa "memeriksakan" 120.000+ baris Composer PHP kode tidak ditulis oleh saya?

Saya bergantung pada PHP CLI untuk semua jenis pribadi dan "mudah-mudahan, segera) profesional/misi-kritis" logika bisnis ". (Ini bisa berupa bahasa lain dan masalah yang sama persis masih ada; Saya hanya menyatakan apa yang saya gunakan secara pribadi demi konteks.)

Sejauh mungkin, saya selalu kode semuanya sendiri. Hanya ketika benar-benar diperlukan, saya, dengan enggan, menggunakan perpustakaan pihak ketiga. Untuk beberapa hal, ini hanya perlu. Misalnya, penguraian email dan hal-hal lain yang sangat rumit seperti itu.

Untuk mengelola perpustakaan pihak ketiga tersebut, saya menggunakan PHP Composer . Ini adalah pengelola perpustakaan untuk PHP. Ia dapat mengunduh pustaka, dan dependensinya, dan memperbaruinya dengan perintah yang mirip dengan "manajer paket" lainnya. Dalam arti praktis, ini jauh lebih baik daripada secara manual melacak ini dan secara manual mengunduh file Zip dan membongkar mereka dan menangani segala macam masalah. Setidaknya menghemat banyak sakit kepala praktis.

Namun , masalah keamanan paling mendasar masih ada: Saya tidak tahu kode "diinstal" ini mengandung, saya juga tidak tahu apa yang ditambahkan/diubah dengan setiap pembaruan. Salah satu penulis perpustakaan dapat dengan mudah dikompromikan suatu hari ketika Composer saya mengambil pembaruan, menyebabkan PHP skrip CLI saya tiba-tiba mengirim Bitcoin wallet saya. Ke server jarak jauh, instal RAT/trojan di komputer saya, atau bahkan lebih buruk. Sebenarnya, itu bisa saja terjadi, dan saya tidak akan menjadi lebih bijak. Saya tidak tahu. Secara logis saya tidak bisa tahu.

Basis kode saya sendiri adalah total sekitar 15.000 baris. Butuh waktu lebih dari setahun untuk dengan susah payah melewati basis kode itu. Dan itu adalah kode yang [~ # ~] i [~ # ~] telah ditulis dan yang saya ketahui secara intim ...

Pohon direktori "Komposer" saya saat ini berada di lebih dari 120.000 baris kode . Dan itu untuk jumlah minimal dari krusial PHP perpustakaan yang saya butuhkan. Saya menggunakan sangat sedikit, tetapi mereka memiliki berbagai dependensi dan cenderung keseluruhan sangat membengkak/meningkat dibandingkan dengan kode saya sendiri.

Bagaimana aku bisa "memeriksa" semua ini ?! Itu tidak akan terjadi. Saya "zona" sangat singkat bahkan setelah mencoba. Saya bahkan tidak tahu bagaimana saya akan membuatnya melalui "putaran dokter hewan" lain dari kode saya sendiri - apalagi ini 10x lebih besar, dikodekan oleh orang lain.

Ketika orang mengatakan bahwa itu "harus" untuk "kode pihak ketiga", apa sebenarnya artinya? Saya juga setuju bahwa itu "harus", tetapi kemudian ada kenyataan sialnya. Saya tidak akan pernah punya waktu dan energi untuk melakukan ini. Juga, saya jelas tidak punya uang untuk membayar orang lain untuk melakukannya.

Saya menghabiskan banyak waktu mencoba untuk belajar tentang Docker dan melihat apakah ada beberapa cara saya bisa "merangkum" perpustakaan pihak ketiga yang tidak dipercaya ini entah bagaimana, tapi itu adalah pertempuran yang kalah. Saya merasa sangat tidak mungkin untuk melakukan itu, atau memiliki salah satu dari banyak pertanyaan saya mengenai hal itu dijawab. Saya bahkan tidak berpikir itu mungkin seperti yang saya bayangkan.

86

Anda tidak dapat memeriksa setiap baris kode. Anda akan mati saat mencoba melakukan itu.

Pada titik tertentu, Anda harus memercayai orang lain. Pada 1984, Ken Thompson, salah satu penemu banyak Unix, menulis artikel pendek tentang batasan trust . Pada titik tertentu, Anda harus memercayai orang lain, Anda harus percaya bahwa siapa pun yang menulis editor teks Anda tidak secara otomatis menyembunyikan beberapa kode Trojan yang penerjemah PHP akan mengeksekusi ke dalam beberapa malware pencuri Bitcoin mencuri .

Anda harus melakukan analisis biaya-manfaat untuk memprioritaskan apa yang Anda periksakan.

Untuk sebagian besar, Anda harus melakukan yang terbaik untuk memeriksa penulis kode, praktik keamanan internal proyek, dan bagaimana kode mencapai Anda. Sebenarnya mengkaji kode itu mahal dan sulit, sehingga mereka harus dicadangkan untuk bagian-bagian yang Anda anggap paling penting untuk proyek Anda.

Apakah perpustakaan itu perpustakaan populer yang digunakan oleh banyak orang dengan perusahaan terhormat atau proyek terkenal yang memimpinnya? Apakah proyek memiliki proses manajemen proyek yang tepat? Apakah perpustakaan memiliki sejarah masalah keamanan yang baik di masa lalu, dan bagaimana mereka menanganinya? Apakah ada tes untuk mencakup semua perilaku yang perlu ditangani? Apakah ia lulus tes sendiri? Maka risiko perpustakaan dikompromikan tanpa ada yang memperhatikan berkurang.

Ambil beberapa file sampel untuk pemeriksaan lebih dalam. Apakah Anda melihat sesuatu tentang sana? Jika beberapa file yang Anda ambil memiliki masalah besar, Anda mungkin dapat menyimpulkan bahwa basis kode lainnya memiliki masalah yang sama; jika mereka terlihat bagus, maka itu meningkatkan kepercayaan diri Anda bahwa sisa basis kode ditulis dengan baik. Perhatikan bahwa dalam basis kode yang sangat besar, akan ada area kode yang berbeda dengan berbagai tingkat kualitas kode.

Apakah repositori manajer paket Anda memeriksa tanda tangan paket? Apakah ada sistem pra-pemeriksaan yang diperlukan untuk mendaftarkan paket ke dalam repositori atau apakah itu repositori pendaftaran terbuka? Apakah Anda menerima perpustakaan dalam bentuk kode sumber atau sebagai biner yang dikompilasi? Ini memengaruhi seberapa banyak Anda bisa mempercayai perpustakaan, faktor-faktor risiko, dan bagaimana Anda bisa lebih jauh meningkatkan kepercayaan.

Anda juga harus mempertimbangkan aplikasi dan lingkungan eksekusi tempat aplikasi akan berjalan. Apakah ini untuk kode keamanan nasional? Apakah kode ini menangani bagian dari eCommerce atau perbankan yang menangani nomor kartu kredit? Apakah kode ini berjalan sebagai pengguna super? Apakah kode ini hidup/aman-kritis? Apakah Anda memiliki kontrol kompensasi untuk mengisolasi dan menjalankan kode dengan hak istimewa yang berbeda (mis. Kontainer, VM, izin pengguna)? Apakah kode ini untuk proyek sampingan akhir pekan? Bagaimana Anda menjawab pertanyaan-pertanyaan itu akan membuat Anda menentukan anggaran tentang seberapa banyak Anda dapat berinvestasi dalam kode pemeriksaan, dan karena itu bagaimana memprioritaskan perpustakaan mana yang perlu diperiksa, pada tingkat apa, dan mana yang baik-baik saja dengan kepercayaan yang lebih rendah.

140
Lie Ryan

Pohon direktori "Komposer" saya saat ini ada di lebih dari 120.000 baris kode. Dan itu untuk jumlah minimal pustaka PHPkrusial yang saya butuhkan.

Kesalahan Anda dalam mencoba kode dokter pihak ketiga seolah-olah itu milik Anda. Anda tidak dapat dan tidak boleh mencoba melakukan itu.

Anda belum menyebutkan salah satu perpustakaan dengan nama, tapi saya akan berasumsi bahwa sebagian besar ada di sana karena Anda menggunakan salah satu kerangka kerja yang lebih besar, seperti Laravel atau - Symfony . Kerangka kerja seperti ini, seperti perpustakaan besar lainnya memiliki tim keamanan sendiri; masalah ditambal dengan cepat dan menginstal pembaruan itu sepele (selama Anda berada pada rilis yang didukung).

Daripada mencoba memeriksa semua kode itu sendiri, Anda harus melepaskan dan percaya bahwa vendor telah melakukan - dan terus melakukan - yang menjamin Anda. Lagi pula, inilah alasan mengapa Anda menggunakan kode pihak ketiga.

Secara realistis, Anda harus memperlakukan pustaka pihak ketiga PHP persis sama seperti Anda akan memperlakukan pustaka pihak ketiga dalam lingkungan yang dikompilasi seperti . NET atau Java. Di platform tersebut, pustaka datang sebagai file DLL atau yang serupa dan Anda mungkin tidak akan pernah melihat kode sumber. Anda tidak dapat memeriksa mereka dan Anda tidak akan mencoba. Jika sikap Anda terhadap perpustakaan PHP berbeda dengan itu, maka Anda perlu bertanya pada diri sendiri mengapa. Hanya karena Anda dapat membaca kode tidak berarti Anda mendapatkan sesuatu dari melakukannya.

Tentu saja semua ini gagal jika perpustakaan pihak ketiga Anda menyertakan perpustakaan yang lebih kecil yang tidak didukung atau tidak memiliki kebijakan keamanan. Jadi ini adalah pertanyaan yang perlu Anda tanyakan dari semua perpustakaan yang Anda gunakan: Apakah mereka didukung penuh, dan apakah mereka memiliki kebijakan keamanan yang Anda sukai? Untuk yang tidak, maka Anda mungkin ingin mempertimbangkan untuk mencari alternatif untuk perpustakaan tersebut. Tapi itu tetap tidak berarti Anda harus mencoba memeriksanya sendiri, kecuali jika Anda benar-benar berniat mengambil alih dukungan untuk mereka.

Namun, satu hal yang akan saya tambahkan: Jika Anda ingin melakukan audit keamanan pada kode PHP Anda, saya sangat menyarankan menggunakan pemindai RIPS . Ini tidak murah, tetapi jika Anda memiliki persyaratan keamanan yang kuat, itu mudah alat analisis keamanan otomatis terbaik yang bisa Anda dapatkan untuk PHP. Jalankan dengan kode Anda sendiri; Anda mungkin akan terkejut betapa banyak masalah yang muncul. Anda bisa, tentu saja, menjalankannya di perpustakaan pihak ketiga Anda juga jika Anda cukup paranoid. Akan lebih mahal, dan poin saya di atas masih berlaku; Anda benar-benar harus mempercayai vendor pihak ketiga Anda untuk melakukan hal semacam ini untuk diri mereka sendiri.

47
Spudley

Selamat datang di paradigma baru pengkodean: Anda menggunakan perpustakaan di atas perpustakaan. Anda tidak sendirian, tetapi Anda juga perlu memahami bahwa kapan pun Anda memasukkan kode yang tidak Anda tulis, Anda membawa risiko.

Pertanyaan Anda yang sebenarnya adalah bagaimana saya bisa mengelola risiko itu?

Pahami apa yang seharusnya dilakukan oleh perangkat lunak Anda

Terlalu sering, manajer perpustakaan menjadi cara yang nyaman untuk menampar kode dalam "hanya berfungsi", tanpa pernah repot-repot memahami pada tingkat tinggi apa yang seharusnya dilakukan. Dengan demikian, ketika kode perpustakaan tepercaya Anda melakukan hal-hal buruk , Anda tertangkap basah, bertanya-tanya apa yang terjadi. Di sinilah pengujian unit dapat membantu, karena menguji apa yang seharusnya dilakukan oleh kode.

Ketahui sumber Anda

Komposer (atau manajer paket mana pun) dapat menginstal dari sumber apa pun yang Anda tentukan, termasuk perpustakaan yang digulung kemarin oleh sumber yang sama sekali tidak dikenal. Saya sudah rela menginstal paket dari vendor yang memiliki SDK, karena vendor adalah sumber yang sangat tepercaya. Saya juga menggunakan paket dari sumber yang melakukan pekerjaan tepercaya lainnya (mis. Seseorang dalam proyek PHP memiliki repo perpustakaan). Memercayai sumber apa pun secara tidak sengaja dapat membuat Anda dalam masalah.

Terimalah bahwa ada beberapa risiko yang tidak dapat Anda mitigasi sepenuhnya

Pada 2016, satu pengembang NodeJS melumpuhkan banyak paket ketika mereka keluar dari proyek dan menuntut perpustakaan mereka tidak diterbitkan. Mereka memiliki satu perpustakaan sederhana yang ratusan paket lainnya terdaftar sebagai dependensi. Atau mungkin infrastruktur tidak dibangun untuk menangani distribusi paket sehingga gagal secara acak. Internet telah menjadi sangat baik dalam "membuat sesuatu bekerja" di dunia pengembangan perangkat lunak terdistribusi, sehingga orang cenderung kesal atau bingung ketika itu hanya berhenti bekerja.

Ketika PHP 7.0 keluar, saya harus melakukan banyak pekerjaan dalam membuat paket perangkat lunak pihak ketiga open-source yang kami gunakan fungsi di lingkungan 7.0. Butuh waktu yang signifikan di pihak saya, tetapi saya dapat membantu pembuat paket untuk mengatasi beberapa masalah dan membuatnya dapat digunakan di lingkungan 7.0. Alternatifnya adalah menggantinya ... yang akan memakan waktu lebih lama lagi.Ini risiko yang kami terima karena paket itu cukup berguna.

27
Machavity

Namun, masalah keamanan yang paling mendasar masih berlanjut: Saya tidak tahu apa yang mengandung kode "diinstal" ini, saya juga tidak tahu apa yang ditambahkan/diubah dengan setiap pembaruan. Salah satu penulis perpustakaan dapat dengan mudah dikompromikan suatu hari ketika Composer saya mengambil pembaruan, menyebabkan skrip PHP CLI saya tiba-tiba mengirim Bitcoin wallet.dat saya) ke beberapa server jarak jauh, instal RAT/trojan di komputer saya, atau bahkan lebih buruk. Bahkan, itu sudah bisa terjadi, dan saya tidak akan menjadi lebih bijak. Saya hanya tidak tahu. Saya secara logis tidak bisa tahu.

Lihat Heartbleed , lubang keamanan besar-besaran di OpenSSL. Heartbleed secara efektif nerfed SSL dengan terlebih dahulu menyimpan beberapa ratus atau ribuan transaksi terakhir (dienkripsi jaringan) sebagai plaintext dan kemudian dengan meninggalkan fasilitas yang mudah dan tidak disimpan untuk siapa pun yang tahu tentang hal itu untuk terhubung jarak jauh dan mengambil semua transaksi cache-memori yang dipikirkan pengguna dienkripsi dengan aman, dalam teks biasa. Pada saat itu OpenSSL melindungi sebagian besar situs web yang dihosting sendiri dan sejumlah besar bank dan bahkan layanan intelijen pemerintah.

Kemudian cari Meltdown dan Specter , bug besar yang dibangun langsung ke CPU Intel modern. Meltdown dan Specter sepenuhnya menangkal menjalankan CPU dalam Mode Terlindungi sama sekali dan, karena tidak tergantung pada OS, dapat dieksploitasi pada setiap sistem operasi.

Bertahun-tahun yang lalu, sepotong malware bernama MSBlaster mengeksploitasi a (Saya bahkan tidak yakin itu bug - hanya sangat bodoh) Windows XP layanan latar belakang yang tidak memiliki bisnis bahkan berjalan secara default - itu hanya akan secara aktif digunakan oleh sebagian besar pengguna Windows dan kemudian hanya diketahui oleh departemen TI.Ini akhirnya mendorong ISP untuk mengeluarkan firewall perangkat keras yang dibangun ke dalam perangkat modem mereka, dan mendorong Microsoft untuk menanamkan firewall perangkat lunak bawaan ke dalam sistem operasi mereka. Sekitar waktu yang sama, sebuah distribusi dari platform Linux yang diduga "anti virus" ditemukan mengandung rootkit bawaan dalam rilis distribusi utama.

Seperti yang dikatakan orang lain: Anda harus memercayai seseorang pada suatu saat. Kecelakaan dan kedengkian menyebabkan masalah. Aku seperti kamu - penggemar The X-Files dan - plink (TRUST NO ONE!) - tetapi kenyataannya adalah mesin kriptografi SSL Anda atau perangkat perangkat keras fisik Anda sama mungkin untuk menghadirkan lubang keamanan dan mereka jauh lebih mungkin untuk mewakili kegagalan misi-kritis ketika mereka hadir.

Jika Anda serius berusaha lebih keras untuk menciptakan kembali roda Composer untuk keamanan Anda dan pengguna Anda, maka seriuslah untuk menempuh jarak ekstra itu: Insinyur CPU, mainboard, RAM, HDD dan drive optik. Tulis OS dan driver perangkat keras Anda sendiri. Buat kompiler Anda sendiri juga. Dan lupakan PHP karena mungkin ada masalah pada penerjemah - bahkan lupakan C dan C++ juga karena mungkin ada masalah di kompiler, dan bahkan tidak berpikir tentang bahasa Assembly dengan assembler yang ditulis orang lain. Tulis semua perangkat lunak Anda sendiri dari bawah ke atas dalam instruksi mesin, dengan hex editor.

Atau Anda bisa bertindak seperti anggota industri. Berlangganan buletin Pembaruan Komposer/PHP/YourLinuxDistro dan mungkin dapatkan juga di beberapa buletin independen berbasis keamanan, dan dapatkan berlangganan Kabel. Tinjau log sistem Anda. Secara berkala uji jaringan Anda dengan PCAP untuk memastikan tidak ada aliran jaringan yang tidak sah baik masuk atau keluar. Jadilah proaktif tentang memonitor kemungkinan ancaman dan tidak paranoid tentang hal-hal yang belum terjadi.

3
user116960

Sebagai pengembang tingkat menengah hingga lanjutan, saya telah mempertimbangkan masalah yang sama. Beberapa hal yang perlu dipertimbangkan:

  • Prioritas meninjau kode yang sangat penting untuk tujuan keamanan. Jelas itu akan mencakup hal-hal seperti otentikasi dan kode masuk, validasi izin, integrasi prosesor pembayaran . Apa pun yang meminta informasi sensitif atau membuat panggilan jaringan.
  • Secara visual skim hal-hal seperti perpustakaan gaya - Anda harus dapat dengan cepat menentukan bahwa mereka hanya melakukan penataan - dan hal-hal seperti fungsi utilitas. String huruf besar, penggantian spasi putih, susunan ulang susunan ... Anda harus dapat dengan cepat membaca kode dan melihat bahwa mereka tidak melakukan sesuatu yang tidak terduga.
  • Bahkan jika Anda tidak sepenuhnya membalikkan kode insinyur seolah-olah itu milik Anda sendiri, Anda harus dapat melirik sumbernya dan menentukan apakah itu dimaksudkan menjadi ramah terhadap rekayasa balik . Kode harus didokumentasikan dengan komentar yang bermanfaat, nama variabel dan metode harus relevan dan bermanfaat, fungsi dan implementasi tidak boleh terlalu panjang atau terlalu rumit atau mengandung fungsi yang tidak perlu. Kode yang sangat menyenangkan mata tentu saja bukan vektor serangan yang disukai oleh peretas jahat.
  • Konfirmasikan bahwa kode memiliki basis pengguna dewasa dan mapan. Anda ingin condong ke proyek-proyek yang diketahui digunakan oleh perusahaan-perusahaan yang menguntungkan dan terkenal.
  • Konfirmasikan identitas dunia nyata dari kontributor utama. Untuk proyek-proyek skala besar, pengembang utama akan senang untuk mengambil kredit untuk pekerjaan mereka. Anda harus dapat menemukan posting blog, akun media sosial, dan mungkin resume atau halaman pemasaran untuk pekerjaan konsultasi. Hubungi saya! dll.
  • Konfirmasikan bahwa kode sumber terbuka dipelihara secara aktif dengan perbaikan bug terbaru. Lihatlah laporan bug yang luar biasa - pasti ada beberapa - dan jangan percaya klaim bahwa alat atau pustaka tertentu bebas bug. Itu klaim delusi.
  • Hindari "freeware" situs dengan iklan berlebihan. Hindari proyek yang tidak memiliki situs demo, atau di mana demo "jelek", tidak terawat, atau sering offline. Hindari proyek yang terlalu bersemangat, atau kata kunci yang berlebihan, membuat klaim kinerja unggul yang belum teruji. Hindari mengunduh dari blog anonim. Dll.
  • Berpikir jahat. Jika Anda ingin menghancurkan situs Anda, apa yang akan Anda coba? Jika Anda ingin menyelinap kode yang tidak aman ke perpustakaan yang banyak digunakan, bagaimana Anda melakukannya? (Jangan coba ini, tentu saja.)
  • Fork proyek sumber terbuka, atau unduh cadangan. Jangan pernah percaya bahwa repo resmi proyek sumber terbuka yang Anda sukai akan tetap online tanpa batas.

Jadi alih-alih mencoba membaca dan memahami setiap baris kode secara terpisah, dapatkan gagasan tentang apa setiap perpustakaan, dan mengapa Anda yakin itu yang melakukannya. Saya benar-benar berpikir bahwa, jika pekerjaan Anda menguntungkan, tidak ada batas atas seberapa besar proyek bisa; Anda dapat "dokter hewan" 1.200.000+ baris kode, atau 120.000.000+ baris kode!

2

Komposer dapat bekerja dengan composer.lock file dan, secara default, mengunduh paket melalui https://packagist.org/ (perhatikan HTTP [~ # ~] s [~ # ~] .) Jadi Anda memiliki repositori paket yang sangat besar dan unduhan yang aman disertai SHA1 checksum untuk memastikan bahwa Anda mengunduh persis apa yang pernah ditentukan. Itu saja cukup banyak membantu Anda.

Jika Anda tetap pada sisi konservatif dari pembaruan ketergantungan, Anda juga dapat berharap bahwa versi paket telah melihat penggunaan produksi.

Pada akhirnya, Anda harus memercayai seseorang. Anda bisa memercayai diri sendiri untuk menulis kode bebas-exploit, atau Anda bisa, seperti orang lain, mempercayai proyek komunitas yang digunakan oleh ribuan orang dan dilihat oleh lebih banyak pengguna.

Pada akhirnya, saya pikir Anda tidak punya pilihan. Jika orang lain "terbang membabi buta", yaitu tanpa audit keamanan yang ingin Anda lakukan, dan membawa pelanggan "Anda" dengan harga lebih rendah dan rilis fitur yang lebih cepat, toh tidak seorang pun akan mendapat manfaat dari aplikasi aman yang Anda tulis sendiri.

0
knallfrosch