Belki WordPress güvenlik ekibine güvenmeliyiz

Bu yıl, WordCamp Miami’de Airbnb’yi diğer birkaç WordPress geliştiricisine dağıttım.Biz kaldı kapı bir tuş takımı kapı kilidi vardı.Kodu hemen unuttuğum için şifre yöneticime çok bağımlı olduğumu düşündüm.Sonuç olarak, daha sonra partide, neredeyse ayrılmaya hazır olduğumda, yaşadığım insanlardan birini buldum – olağanüstü güdüler ve kolay dijital indirmeler için bir geliştirici olan Chris Christoff ve WordPress Core Güvenlik Ekibinin üyeleri – Ona kodunu sor.Görünüşe göre, güvenlik sorunları hakkında diğer geliştiricilerle yaptığı tartışmayı kesintiye uğrattım.Bu nedenle, Chris sadece kodu anlatmak yerine, şifreyi kapıdaki şifreyi zorlamak için kullanabileceğim stratejilerin bir listesini yapmaya başladığında şaşırmadım.
WordPress’in ana geliştiricilerinden Mark Jaquith, başarılı olana kadar rastgele sayıların bir kombinasyonuna girdiğini göstermek için onu kesintiye uğrattı. Bunun yerine, kombinasyon rulmanı üzerindeki aşınma modelini analiz etmemi önerdi, bu da bana hangi sayının kodda bulunması muhtemel olduğunu söyleyecek. Tuş takımı sisteminin nasıl çalışması gerektiğini düşünmüyorlar. Nasıl kötüye kullanılabileceğini ve kötüye kullanılabileceğini düşünüyorlar. O zaman, çok yorgundum ve sadece Airbnb’ye dönüp uyuyabilmem için bir kod almak istedim. Geriye dönüp bakıldığında, bu konuşmanın kısa bir parçası olduğum için mutluyum. WordPress’in güvenliği hakkında böyle düşünen insanlar olduğunu fark etmekten mutluluk duyuyorum – yaşamak için kullandığım araçlar. Ama aynı zamanda yaptıkları gerçek konuşmanın bir parçası olmamaktan mutluluk duyuyorum. Ne olursa olsun tartıştıkları ve ne olduğunu bilmiyorum, gerçek bir sorun olduğuna ve bu çözüleceğine inanıyorum.
Bu, çoğu WordPress kullanıcısının WordPress’i kutuyu yazarak ve düğmeyi tıklatarak kullandığınız bir şey olarak nasıl çalıştırılamayacağınızla ilgilidir. Tersine, geliştiriciler, hepsi tarayıcılardan sunuculara bir dizi istek olan PHP ve JavaScript çerçevesinde düşünme eğilimindedir. (Ve tarayıcı aslında denklemde isteğe bağlıdır.) İstek, terminalden veya çoğu hackleme durumunda, kenar durumlarından yararlanmak için tasarlanmış bir tür sofistike komut dosyasından oluşturulabilir. WordPress’in nasıl çalıştığı konusundaki perspektif farkı, sıradan kullanıcıların son güvenlik sömürüsünü anlamasını zorlaştırıyor. Bunun nedeni, kullanıcıların WordPress’i tarayıcılarıyla kontrol ettikleri bir şey olarak görürken, Siyah veya Beyaz Şapkalar Hacker’lar terminallerden çalışır veya Python veya diğer kodlama dilinde yazılmış otomatik istismar komut dosyaları yazar. Güvenlik açığı araştırmacıları Netanel Rubin tarafından bu yazı. Bu güvenlik açığı, bu “pres” özelliğindeki çok özel zayıflıklardan yararlanır. Bu, sıradan kullanıcılar tarafından asla yapılmayacak, ancak herhangi bir kullanıcının yayın yapmasına izin veren karmaşık bir dizi gerektirir. Bu önemli olmasa da, şunu düşünün: Bu, siteye tehlikeli javascript enjekte etmek için kullanılma potansiyeline sahiptir, bu da site ziyaretçilerini gölgeli veya daha kötü olan çevrimiçi eczane gibi spam sitesine yönlendirmek için kullanılabilir.
Ancak “Basın” ın zayıflığı, WordPress 4.2.3’te nadiren tartışılan bir gelişmedir. Daha fazla yayınlanan sorun, kısa kod yangında değişikliklerdir. Bu değişiklik, kısa kod bir HTML özniteliği olarak kullanıldığında sorunlara neden olur – örneğin, görüntü etiketinde “SRC” ayarlamak veya bağlantı etiketinde bir URL olarak. Bu, kısa bir kod yangını tarafından yapılması gereken bir şey değil, ama işe yarıyor, birçok insan bunu yapıyor. Son zamanlarda Christoff’a kısa kodlarla ilgili konu hakkında röportaj yapmaya çalıştım. Bana daha fazla hikaye olduğunu söyledi, ama şu anda bana sürüm gönderisinden daha fazlasını söyleyemedi. Ancak bana şunu söyledi:
Dürüst olmak gerekirse, güvenlik işlerini yaparak en büyük sorun, insanların anladığım tüm cevapları hemen bilmek istedikleri, ancak tüm güvenlik noktaları için önce söyleyebileceğimiz ve ne zaman söyleyebileceğimiz konusunda bir sınırımız var. Bu cevap hayal kırıklığı yaratıyor. Değişim için bir dizi sınırlı açıklama vardır ve gelecekleri konusunda ilk uyarı yoktur. Kendi içerik yönetim sistemimi yazabilirim. Aslında kendime PHP geliştirme becerilerimi geliştirmek ve bilgimi genişletmek için Symfony bileşenini nasıl kullanacağım. Kim, belirli kullanımlarda WordPress yerine bir ön uç Symfony yönlendirici kullanmayı tercih ederken, test sunucusundan başka bir şey için kendi içerik yönetim sistemimi gerçekten kullanmayacağım.

WordPress’ten yararlanmak için kullanılabilecek garip bir kenar vakası bulmak ve geliştirmek için çalışan bir ekip olduğunu bilmek, geceleri uyumama yardımcı olur.Bu yüzden WordPress kullanıyorum.Sadece böyle sorumluluklar istemiyorum.WordPress’i içerik yönetim sistemimiz olarak seçtiğimizde, güvenlik sorunlarımızın çoğuna ücretsiz geçebiliriz.Onlara inanıyor musun?Tabii ki, güvenlik güncellemeleri sitenizde hasara neden olduğunda bu hayal kırıklığı yaratır, ancak bu alternatiften daha iyidir.Güvenlik iyileştirme ile ilgili iletişim eksikliği, WordPress geliştirme sürecinin geri kalanında bulunan açıklığın aksine, ama bunun nedeni olması gerektiğidir.
Bu kararı gizli yapan insanlara güvenmiyorsanız, WordPress kullanmamalısınız.Güvenle ilgili sorunlar çeşitli gizlilik seviyeleriyle ele alınmalıdır;Ve bunu göz önünde bulundurarak, WordPress’in güvenli ve korunmak için gerekenleri yapması için WordPress güvenlik ekibine güvenmeliyiz.Kısa kod yangınlarındaki değişiklikleri sevmiyorsanız, sitenizde iptal edebilirsiniz.Bunu yapmanızı şiddetle tavsiye ediyorum, ama yapabilirsiniz.Onları kişisel olarak tanımadığınızda ve eylemlerinden etkilendiğinizde WordPress güvenlik ekibine kızmak kolaydır.WordPress 4.2.3 Kısa koddaki değişiklikler nedeniyle değil, “bu basının” iyileştirilmesi ile ilgili nedenlerden dolayı, üzerinde çalıştığım eklentide çalıştığım birkaç şeyi çözün.Bu hayal kırıklığı yaratıyor, ancak bunun doğru bir şey olduğuna inanıyorum, hepimizin güvende kalması.