it-swarm-tr.com

Nasıl = Composer PHP kod benim tarafımdan yazılmamış) 120.000+ satır "veteriner" nasıl mümkün olacak?

Ben PHP CLI her türlü kişisel ve (umarım, yakında) profesyonel/görev açısından kritik "iş mantığı" bağlıdır. (Bu başka bir dil olabilir ve tam olarak aynı sorun hala devam edecekti ; Sadece bağlam uğruna kişisel olarak kullandığımı söylüyorum.)

Mümkün olan en geniş ölçüde, her şeyi kendi başıma kodlarım. Ancak kesinlikle gerekli olduğunda üçüncü taraf bir kütüphane kullanmaya başvuruyorum. Bazı şeyler için bu sadece gerekli. Örneğin, e-posta ayrıştırma ve bunun gibi diğer çok karmaşık şeyler.

Bu tür üçüncü taraf kitaplıklarını yönetmek için PHP Composer kullanıyorum. PHP için bir kütüphane yöneticisidir. Kitaplıkları ve bağımlılıklarını indirebilir ve diğer "paket yöneticilerine" benzer komutlarla güncelleyebilir. Pratik anlamda, bu çok bunu manuel olarak takip etmek ve Zip dosyalarını manuel olarak indirmek ve paketinden çıkarmak ve her türlü problemle uğraşmaktan daha iyidir. En azından birçok pratik baş ağrısından kurtarır.

Ancak, en temel güvenlik sorunu hala devam ediyor: Bu "kurulu" kodun ne içerdiği hakkında hiçbir fikrim yok, ne de her güncelleme ile neyin eklendiğini/değiştirildiğini biliyorum. Composer güncellemeler getirildiğinde kütüphanelerin yazarlarından biri kolayca tehlikeye atılabilir ve bu da PHP CLI komut dosyalarının birden Bitcoin wallet.dat'ımı göndermesine neden olabilir) bazı uzak sunuculara, makineme bir RAT/truva atı yükleyin, hatta daha da kötüsü ... Aslında, zaten olmuş olabilirdi ve daha akıllıca olamayacaktım. Hiçbir fikrim yok. Mantıken hiçbir fikrim yok.

Kendi kod tabanım yaklaşık 15.000 satır. Bu kod tabanından titizlikle geçmek bir yıldan uzun sürüyor. Ve bu [~ # ~] i [~ # ~] yazdıkları ve yakından bildiğim kod ...

"Besteci" dizin ağacım şu anda 120.000 satırın üzerinde kod. Ve bu en az sayı çok önemli PHP kütüphaneler ihtiyacım var. Çok az kullanıyorum, ama çeşitli var bağımlılıkları ve kendi kodumla karşılaştırıldığında genel olarak çok şişkin/şişirilmiş olma eğilimindedir.

Bunları nasıl "veteriner" edeyim ?! Sadece olmayacak. Ben bile denedikten kısa bir süre sonra "bölge". Nasıl kendi kod - başka bir "veteriner turu" üzerinden nasıl yapacağımı bile bilmiyorum - yalnız bu 10x büyük bir tane, başkaları tarafından kodlanmış.

İnsanlar bunun üçüncü taraf kodunu araştırmak için "zorunluluk" olduğunu söylediklerinde, tam olarak ne anlama geliyorlar? Ayrıca bunun bir "zorunluluk" olduğunu kabul ediyorum, ama sonra sinir bozucu gerçeklik var. Bunu yapmak için asla zamanım ve enerjim olmayacak. Ayrıca, bunu yapmak için başkasına ödeme yapacak param yok.

Docker hakkında bilgi edinmek ve bu güvenilmeyen üçüncü taraf kütüphanelerini bir şekilde "kapsülleyebilmemin" bir yolu olup olmadığını görmek için sayısız saat geçirdim, ama bu kaybedilen bir savaş. Bunu devam ettirmek ya da bununla ilgili birçok sorumdan herhangi birinin cevaplanmasını imkansız buldum. Hayal ettiğim gibi mümkün olduğunu bile düşünmüyorum.

86

Tek tek kod satırlarını inceleyemezsiniz. Sadece bunu yapmaya çalışırken öleceksin.

Bir noktada, başka birine güvenmelisiniz. 1984 yılında, Unix'in çoğunun ortak mucitlerinden Ken Thompson, tröst sınırlamaları hakkında kısa bir makale yazdı. Bir noktada, diğer insanlara güvenmek zorundasınız, metin düzenleyicinizi kim yazıyorsa, PHP yorumlayıcının bazı Bitcoin çalma kötü amaçlı yazılımlarına yürüteceği bazı Truva atı kodunu otomatik olarak gizlemediğine güvenmelisiniz. .

Veterinere ne öncelik verdiğini belirlemek için bir maliyet-fayda analizi yapmalısınız.

Çoğunlukla, kodun yazarlarını, projenin iç güvenlik uygulamalarını ve kodun size nasıl ulaştığını incelemek için elinizden geleni yapmalısınız. Aslında kodu gözden geçirmek pahalı ve zordur, bu nedenle projeniz için en önemli olduğunu düşündüğünüz bölümlere ayrılmalıdır.

Kütüphane, saygın bir şirket veya arkasındaki tanınmış bir proje lideri olan birçok kişi tarafından kullanılan popüler bir kütüphane mi? Projede uygun proje yönetimi süreçleri var mı? Kütüphane geçmişinde güvenlik sorunlarıyla ilgili iyi bir geçmişe sahip mi ve bunları nasıl ele aldılar? Ele alması gereken tüm davranışları kapsamak için testleri var mı? Kendi testlerini geçiyor mu? Daha sonra hiç kimsenin farkına varmadan kütüphanenin tehlikeye girme riski azalır.

Daha derin veterinerlik için birkaç örnek dosya alın. Orada bir şey görüyor musun? Aldığınız birkaç dosyanın önemli sorunları varsa, muhtemelen kod tabanının geri kalanının benzer sorunları olduğunu çıkarabilirsiniz; iyi görünüyorlarsa, kod tabanının geri kalanının benzer şekilde iyi yazıldığına dair güveninizi artırır. Çok büyük kod tabanlarında, kodun değişen düzeylerde kod kalitesine sahip farklı alanları olacağını unutmayın.

Paket yöneticisi deponuz paket imzasını kontrol ediyor mu? Bir paketi depoya kaydetmek için ön inceleme sistemi var mı veya açık bir kayıt havuzu mu? Kütüphaneyi kaynak kodu şeklinde mi yoksa önceden derlenmiş bir ikili dosya olarak mı alıyorsunuz? Bunlar kütüphaneye ne kadar güvenebileceğinizi, risk faktörlerini ve güveni nasıl daha da artırabileceğinizi etkiler.

Ayrıca uygulamayı ve uygulamanın çalışacağı yürütme ortamını da dikkate almanız gerekir. Bu bir ulusal güvenlik kodu için mi? Bu kod yönetimi bir e-Ticaret veya bankacılık işlemleri kredi kartı numaralarının bir parçası mı? Bu kod bir süper kullanıcı olarak mı çalışıyor? Bu kodun ömrü/güvenliği kritik mi? Kodu farklı ayrıcalıklarla (örn. Kapsayıcılar, VM'ler, kullanıcı izinleri) izole etmek ve çalıştırmak için telafi edici denetimleriniz var mı? Bu kod bir hafta sonu tarafı projesi için mi? Bu soruları nasıl yanıtladığınız, veterinerlik koduna ne kadar yatırım yapabileceğinize ve bu nedenle hangi kütüphanelerin veterinere ihtiyaç duyduğuna, hangi düzeyde ve hangilerinin daha düşük güvene sahip olduğuna nasıl öncelik verileceğine dair bir bütçe tanımlamanıza izin vermelidir.

140
Lie Ryan

"Besteci" dizin ağacım şu anda 120.000'den fazla kod satırında. Ve bu, ihtiyacım olan çok az önemli PHP kitaplık için.

Sizin hatanız, üçüncü taraf kodunu kendinizmiş gibi incelemeye çalışmaktır. Bunu yapmaya çalışamazsınız ve yapmamalısınız.

Kütüphanelerden hiçbirini adından bahsetmediniz, ancak bunun daha büyük bir çerçeveden birini kullandığınız için orada adil bir yığın olduğunu varsayacağım, örneğin Laravel veya - Symfony'nin . Diğer büyük kütüphanelerde olduğu gibi böyle çerçevelerin kendi güvenlik ekipleri vardır; sorunlar hızlı bir şekilde yamanır ve güncellemeleri yüklemek önemsizdir (desteklenen bir sürümde olduğunuz sürece).

Tüm bu kodu kendiniz araştırmaya çalışmak yerine, satıcının sizin için bu veterinerliği yaptığını ve yapmaya devam ettiğine güvenmeniz gerekir. Sonuçta, üçüncü taraf kodu kullanmanızın nedenlerinden biri budur.

Gerçekçi olarak, üçüncü taraf PHP kitaplıklarına . NET veya Java gibi derlenmiş bir ortamda üçüncü taraf kitaplıklarla aynı şekilde davranmanız gerekir. Bu platformlarda, kütüphaneler DLL dosyası veya benzeri olarak gelir ve hiçbir zaman kaynak kodunu göremeyebilirsiniz. Onları araştıramazsınız ve denemezsiniz. Bir PHP kütüphanesine karşı tutumunuz bundan farklıysa, kendinize nedenini sormanız gerekir. Sadece kodu okuyabilmeniz kodu okuyabileceğiniz anlamına gelmez.

Elbette tüm bunların düştüğü yer, üçüncü taraf kütüphanelerinizde desteklenmeyen veya bir güvenlik politikası olmayan daha küçük kütüphaneler varsa. O halde bu, kullandığınız tüm kütüphaneleri sormanız gereken soru: Tam olarak destekleniyorlar mı ve rahat olduğunuz bir güvenlik politikası var mı? Bunu yapmayanlar için bu kütüphanelere bir alternatif bulmayı düşünebilirsiniz. Ancak bu, aslında onları desteklemeyi düşünmediğiniz sürece, onları kendiniz denemelisiniz anlamına gelmez.

Ancak ekleyeceğim bir şey: PHP kodunuzda güvenlik denetimi yapmak istiyorsanız, RIPS tarayıcı kullanılmasını önemle tavsiye ederim. Ucuz değil, ancak güçlü güvenlik gereksinimleriniz varsa, PHP için alabileceğiniz en iyi otomatik güvenlik analiz aracıdır. Kesinlikle kendi kodunuzda çalıştırın; Muhtemelen kaç tane sorun çıkardığına şaşıracaksınız. Tabii ki, eğer yeterince paranoyaksanız, üçüncü taraf kitaplıklarınızda da çalıştırabilirsiniz. Yine de size çok daha pahalıya mal olacak ve yukarıdaki puanlarım hala duruyor; üçüncü taraf satıcılarınıza bu tür şeyleri kendileri için yapmaları konusunda gerçekten güveniyor olmalısınız.

47
Spudley

Yeni kodlama paradigmasına hoş geldiniz: kütüphanelerin üstünde kütüphaneler kullanıyorsunuz. Çok yalnız değilsin, ama aynı zamanda kod yazdığın zaman yazmadığın bir risk getirdiğini de anlamalısın.

Asıl sorunuz bu riski nasıl yönetebilirim?

Yazılımınızın ne yapması gerektiğini anlama

Çok sık, kütüphane yöneticileri, ne yapması gerektiğini üst düzeyde anlamaya hiç uğraşmadan, bu "sadece çalışır" kod tokat atmak için uygun bir yol haline gelir. Böylece, güvenilir kütüphane kodunuz kötü şeyler yapar olduğunda, ne olduğunu merak edersiniz. birim testi kodun ne yapması gerektiğini test ettiği için burada yardımcı olabilir.

Kaynaklarınızı tanıyın

Composer (veya herhangi bir paket yöneticisi), tamamen bilinmeyen bir kaynak tarafından dün toplanan bir kitaplık da dahil olmak üzere, belirttiğiniz herhangi bir kaynaktan yükleyebilir. SDK'ları olan satıcıların paketlerini isteyerek kurdum, çünkü satıcı oldukça güvenilir bir kaynak. Ayrıca diğer güvenilir işler (yani PHP projesinde bir kütüphane repo var) birisi kaynaklardan paketleri kullandım. Körü körüne herhangi bir kaynağa güvenmek size bela alabilirsiniz.

Asla tamamen azaltamayacağınız bir risk olduğunu kabul edin

2016'da, tek bir NodeJS geliştiricisi bir ton paket sakladı projeden çıkıp kütüphanelerinin yayınlanmasını istemediklerinde. Yüzlerce başka paketin bağımlılık olarak listelendiği basit bir kütüphaneleri vardı. Ya da belki altyapı paket dağıtımını işlemek için inşa edilmemiştir bu yüzden rastgele başarısız olur. İnternet, dağıtılmış yazılım geliştirme dünyasında "işleri işler hale getirmede" o kadar başarılı oldu ki, insanlar sadece çalışmayı bıraktığında üzülüyor ya da kafası karışıyor.

PHP 7.0 çıktığında, 7.0 ortamında işlev kullandığımız açık kaynaklı bir üçüncü taraf yazılım paketi yapmak için tonlarca iş yapmak zorunda kaldım. ancak paketin yazarının bazı sorunlar üzerinde çalışmasına ve 7.0 ortamında kullanılabilir hale getirmesine yardımcı oldum.Alternatif bunun yerini almaktı ... bu daha da zaman alacaktı.Paket oldukça faydalı olduğu için kabul ediyoruz.

27
Machavity

Ancak, en temel güvenlik sorunu hala devam ediyor: Bu "yüklü" kodun ne içerdiği hakkında hiçbir fikrim yok, ne de her güncellemede nelerin eklendiğini/değiştirildiğini bilmiyorum. Composer güncellemeler getirildiğinde kütüphanelerin yazarlarından biri kolayca tehlikeye atılabilir ve bu da PHP CLI komut dosyalarının birden Bitcoin wallet.dat'ımı göndermesine neden olabilir) bazı uzak sunuculara, makineme bir RAT/truva atı yükleyin, hatta daha da kötüsü ... Aslında, zaten olmuş olabilirdi ve daha akıllıca olamayacaktım. Hiçbir fikrim yok. Mantıken hiçbir fikrim yok.

Yukarı bak Heartbleed , OpenSSL'deki büyük güvenlik açığı. SSL'yi, son birkaç yüz veya bin (ağ şifreli) işlemi düz metin olarak kaydederek ve ardından uzaktan bağlanıp kullanıcıların düşündüğü tüm bellek önbelleğe alınan işlemleri almasını bilen herkes için kolay ve kilitsiz bir tesis bırakarak etkili bir şekilde sinirlenmiş SSL'yi yürürlüğe soktu. düz metin olarak güvenli bir şekilde şifrelenmiştir. O zamana kadar OpenSSL, kendi kendine barındırılan web sitelerinin büyük çoğunluğunu ve çok sayıda bankayı ve hatta devlet istihbarat servislerini koruyordu.

O zaman Meltdown ve Spectre , modern Intel CPU'larda yerleşik büyük hatalara bakın. Meltdown ve Spectre, Korumalı Mod'da bir CPU çalıştırmaya tamamen karşı çıkıyor ve işletim sisteminden bağımsız olarak her işletim sisteminde sömürülebilir.

Yıllar ve yıllar önce, MSBlaster adlı bir kötü amaçlı yazılım sömürüldü (bir hata olduğundan emin değilim - sadece son derece aptal) Windows XP arka plan hizmeti varsayılan olarak çalışan bir işi bile olmayan - yalnızca Windows kullanıcılarının büyük bir azınlığı tarafından aktif olarak kullanılacak ve daha sonra sadece BT departmanları tarafından bilinecekti.Bu, nihayetinde ISS'leri modem cihazlarına yerleşik donanım güvenlik duvarları yayınlamaya itti ve Microsoft'u gömmek için sürdü Aynı zamanda, "virüs geçirmez" olduğu iddia edilen Linux platformunun, büyük dağıtım sürümünde yerleşik bir rootkit içerdiği bir dağıtımın keşfedildi.

Diğerlerinin söylediği gibi: Bir noktada birine güvenmelisin. Hem kazalar hem de kötülük sorun yaratır. Ben senin gibiyim - X Dosyaları ve - plink (BİRİNE GÜVENMEYİN!) - Ama gerçek şu ki, SSL şifreleme motorunuz veya fiziksel donanım cihazlarınız güvenlik açıkları sunma olasılıkları yüksektir ve bunların mevcut olduklarında kritik görev hatalarını temsil etme olasılıkları daha yüksektir.

Eğer sizin ve kullanıcılarınızın güvenliği için Composer tekerleğini yeniden icat etmek için bu ekstra milden gitme konusunda ciddiyseniz, o ekstra milden gitme konusunda ciddi olun: Kendi CPU'nuzu, anakartınızı, RAM'inizi, HDD ve optik sürücüler Kendi işletim sisteminizi ve donanım sürücülerinizi yazın Kendi derleyicilerinizi de yapın ve PHP) hakkında yorum yapın, çünkü yorumlayıcıda sorunlar olabilir - aslında C ve C++ 'yı da unutun çünkü derleyicide sorunlar olabilir ve başka birinin yazdığı bir montajcı ile Meclis dilini bile düşünmeyin.Herhangi bir yazılımınızı sıfırdan bir düzenleyici ile makine talimatlarında sıfırdan yazın.

Veya sektörün bir üyesi gibi davranabilirsiniz. Composer's/PHP's/YourLinuxDistro'nun güncelleme bültenlerine abone olun ve belki de bazı bağımsız güvenlik tabanlı bültenlere katılın ve Kablol. Sistem günlüklerinizi inceleyin. İçeri veya dışarı yetkisiz ağ akışı olmadığından emin olmak için ağınızı bir PCAP ile periyodik olarak test edin. Olası tehditleri izleme konusunda proaktif olun ve henüz gerçekleşmemiş şeyler hakkında paranoyak olmayın.

3
user116960

Orta ve ileri seviye bir geliştirici olarak aynı problemi düşündüm. Dikkate alınması gereken bazı noktalar:

  • Öncelik güvenlik açısından kritik olan kodu inceleme. Açıkçası bu kimlik doğrulama ve giriş kodu, izin doğrulama, ödeme işlemci entegrasyonları gibi şeyleri içerecektir. Hassas bilgi isteyen veya şebeke çağrısı yapan her şey.
  • Görsel olarak yağsız stil kitaplıkları gibi şeyler - sadece stil yaptıklarını hızlı bir şekilde belirleyebilmelisiniz - ve yardımcı program işlevleri gibi şeyler. Üst dizeleri, boşlukları değiştiren, dizileri yeniden sıralayan ... kodu hızlı bir şekilde gözden geçirebilmeniz ve beklenmedik bir şey yapmadığını görebilmeniz gerekir.
  • Mühendis kodunu tamamen kendinizinmiş gibi tersine çevirmeseniz bile, kaynağa bakabilirsin ve bunun amaçlanıp amaçlanmadığını belirleyebilmeniz gerekir tersine mühendislikle dostça. Kod belgelenmiş yararlı yorumlarla, değişken ve yöntem adları ile ilgili ve yararlı olmalı, işlevler ve uygulamalar çok uzun veya çok karmaşık olmamalı veya gereksiz işlevsellik içermemelidir. Göze çok hoş gelen kod kesinlikle kötü niyetli bilgisayar korsanları için tercih edilen saldırı vektörü değildir.
  • Kodun yerleşik ve yetişkin kullanıcı tabanına olduğunu doğrulayın. Karlı ve tanınmış şirketlerin kullandığı bilinen projelere yönelmek istiyorsunuz.
  • başrol katılımcılarının gerçek dünya kimlikleri onaylayın. Büyük ölçekli projeler için, baş geliştirici çalışmaları için kredi almaktan memnuniyet duyacaktır. Blog gönderilerini, sosyal medya hesaplarını ve muhtemelen danışmanlık çalışmaları için bir özgeçmiş veya pazarlama sayfası bulabilmeniz gerekir. Bana ulaşın ! vb.
  • Açık kaynak kodunun son hata düzeltmeleriyle etkin bir şekilde korunur olduğunu doğrulayın. Olağanüstü hata raporlarına bakın - birkaç tane olması gerekir - ve belirli bir aracın veya kütüphanenin hatasız olduğu iddialarına güvenmeyin. Bu bir yanılsama iddiası.
  • Kaçının aşırı reklam içeren "ücretsiz" siteler. Bir demo sitesi bulunmayan veya demonun "çirkin", kötü bakımlı veya sık sık çevrimdışı olduğu projelerden kaçının. Aşırı yüklenmiş veya aşırı terim içeren projelerden kaçının, test edilmemiş üstün performans iddiaları yapın. Anonim bloglardan indirmekten kaçının. Vb.
  • Kötü düşünün. Sitenizi kırmak isterseniz ne denerdiniz? Güvenli olmayan kodu yaygın olarak kullanılan bir kitaplığa gizlemek isterseniz, bunu nasıl yapardınız? (Bunu kesinlikle denemeyin.)
  • Çatal açık kaynaklı projeler veya yedeklemeler indirin. Beğendiğiniz açık kaynaklı projenin resmi repo'sunun süresiz olarak çevrimiçi kalacağına asla güvenmeyin.

Bu nedenle, her bir kod satırını ayrı ayrı okumaya ve anlamaya çalışmak yerine, ne her kütüphanenin yaptığı bir fikir edinin ve neden bunu yaptığına inanıyorsunuz. Gerçekten, eğer çalışmanız kârlıysa, bir projenin ne kadar büyük olabileceğinin bir üst sınırı olmadığını düşünüyorum; 1200.000+ kod satırını veya 120.000.000+ kod satırını "veteriner" edebilirsiniz !

2

Besteci bir composer.lock dosyası ve varsayılan olarak paketleri https://packagist.org/ (HTTP [~ # ~] s [~ # ~] üzerinden indirir .) Böylece, büyük bir paket deposuna ve beraberindeki SHA1 sağlama toplamı ile güvenli bir indirmeye sahip olursunuz. Sadece bu size çok yardımcı oluyor.

Bağımlılık güncellemelerinin muhafazakar tarafında kalırsanız, paket sürümlerinin üretim kullanımını gördüklerini de bekleyebilirsiniz.

Sonunda, birisine güvenmek zorunda kalacaksın. İstismardan bağımsız kod yazmak için kendinize güvenebilirsiniz ya da diğerleri gibi binlerce kişi tarafından kullanılan ve daha fazla kullanıcı tarafından görülen topluluk projelerine güvenebilirsiniz.

Sonunda, senin bir seçeneğin olduğunu düşünmüyorum. Diğerleri "körü körüne uçuyor", yani yapmak istediğiniz güvenlik denetimleri olmadan ve daha düşük fiyatlar ve daha hızlı özellik sürümleri ile "müşterileriniz" almazsanız, hiç kimse kendi güvenli yazım uygulamanızdan hiçbir şekilde yararlanamayacaktır.

0
knallfrosch