Web Projesi Oluşturmadan Önce Kendinize Sormanız Gereken Beş Soru

Teknoloji projelerinin başarısız olmasının milyonlarca nedeni var. Yanlış hesaplanmış iş modelleri, fazla tahmin edilen talep veya köpüren maliyetler, adını siz koyun. Ancak profesyonel hayatım boyunca, parlak fikirlere ve iyi potansiyele sahip pek çok projenin görünüşte küçük hatalar ve gözden kaçırmalar yüzünden çöktüğünü gördüm. Ve sanırım bu neden en acı olanı, en azından benim için bir geliştirici olarak. Bu makalede deneyimlerimi paylaşmak ve arka uç geliştiricilerin web uygulamalarında çalışırken karşılaştıkları sorunları ve zorlukları analiz etmek istiyorum. Çoğunlukla gözden kaçırılan önemli noktaları vurgulayacağım ve bu engellerin maksimum verimlilikle nasıl aşılacağını açıklayacağım. Bunun riskleri en aza indirmenize ve projenizin başarı şansını önemli ölçüde artırmanıza yardımcı olacağından eminim.

1. Kodunuzda saklanan herhangi bir sır var mı?

Kulağa ne kadar açık gelse de şu nokta çok önemlidir: asla gizli veya hassas bilgileri kaynak kodunuzda saklamayın. İhlaller mali kayıplara ve diğer ciddi sorunlara yol açabilir. Hiçbir zaman kodda saklanmaması gereken hassas bilgiler şunları içerir:

• API anahtarları ve dahili veya harici hizmetlere erişim belirteçleri
• Veritabanı ve yönetici sistemi şifreleri de dahil olmak üzere şifreler ve hesap verileri
• Şifreleme anahtarları
• Hassas veriler içeren yapılandırma dosyaları
• Annenin kızlık soyadı veya evcil hayvanının adı gibi güvenlik sorularının yanıtları

Bu tür bilgileri proje kodunuzda saklamak yerine ortam değişkenlerini kullanın. Daha güvenli sistemler için aşağıdakiler gibi sağlam gizli depolama çözümleri kullanmayı düşünün: HashiCorp Kasası . AWS Gizli Yöneticisi veya GitHub sırları aynı zamanda yararlı da olabilir. Gizli depolama araçlarının seçimi, proje türü ve boyutu, ekibin deneyimi ve teknoloji yığını gibi faktörlere bağlıdır.

Hassas bilgilerin uygulama kodunda saklanmasının ciddi bir sorun olmadığını düşünüyorsanız şunu göz önünde bulundurun: Yalnızca 2022'de GitHub şunu tespit etti: 1,7 milyondan fazla potansiyel sır kamu depolarında açığa çıkar. Geliştiricilerin potansiyel sızıntılar meydana gelene kadar farkında olmadığı özel projelerde bu türden kaç tane veri parçasının bulunabileceğini bir düşünün.

Çözüm: Projenizi hemen kontrol edin

Zaten bir projeniz varsa ve artık kodunuzdaki sırlardan endişeleniyorsanız, içinizi rahatlatabilecek kullanışlı çözümler var. Manuel kontroller zaman alıcı olabilir, bu nedenle otomasyon çok önemlidir. Yararlı araçlar şunları içerir:

• YermantarDomuzu : API anahtarları ve diğer hassas veriler için taahhüt geçmişini tarayarak Git depolarındaki gizli dizileri arar.
• GitLeaks : Git depolarındaki parolalar, API anahtarları ve belirteçler gibi sabit kodlanmış sırları algılar.
• GitGuardian : 350'den fazla gizli türü ve diğer güvenlik açıklarını bulmak için yerel veya CI ortamınızda çalışır.
• GitHub Gelişmiş Güvenlik : Bilinen sır türleri için depoları otomatik olarak tarar ve bulunması durumunda sizi uyarır.

Bu araçlar sadece birkaç örnektir; diğer popüler seçenekler arasında SonarQube Ve Checkmarx . Her ikisi de çeşitli ihtiyaçları ve bütçeleri karşılamak için ücretli ve ücretsiz çözümler sunar. Buradaki amaç mevcut tüm araçları listelemek değil, bu sorunların varlığını ve potansiyel çözümlerini vurgulamaktır. Sorunun farkına varmak başarmanın yarısıdır. Artık bu sorunu çözmek için zaman ayırmanız ve ihtiyaçlarınıza uygun araçları seçmeniz önemlidir.

2. Kütüphane lisanslarınız hakkında neler biliyorsunuz?

Şaşırtıcı bir şekilde, bu konu nadiren tartışılıyor ve bazı geliştiriciler, üçüncü taraf çözümlerini kullanmanın yasal sorunlara ve şirketleri için önemli sorunlara yol açabileceğinin farkında bile değil. Bana inanmıyor musun? Şu senaryoyu hayal edin: Küçük bir şirketteki bir geliştirici, GNU Affero Genel Kamu Lisansı (AGPL) ticari bir web ürününde. Bir copyleft lisansı olarak AGPL, kendisi kapsamında yayımlanan kodu kullanan tüm yazılımların aynı koşullar altında dağıtılmasını gerektirir. Bu, benzersiz geliştirmeler de dahil olmak üzere tüm web uygulamanızın kodunun açık ve ücretsiz kullanıma ve değişikliğe açık olması gerektiği anlamına gelir. Örnek ürünümüz ticari olduğundan kaynak kodunun kullanıma sunulması şirketin rekabet avantajına ve iş modeline ciddi şekilde zarar verebilir.

Ticari kullanımı açıkça yasaklayan lisanslara sahip kütüphaneleri kullanan projelerde de ciddi sorunlar ortaya çıkabilir. Ve hiç lisans yoksa da durum daha iyi olamaz: Aslında, herhangi bir kod varsayılan olarak telif hakkıyla korunduğundan, bir lisansın olmaması önemli bir sorun teşkil eder. Lisanslar, kullanıcılara belirli koşullar altında kodu kullanma hakkı verir, ancak lisans olmadan, kamuya açık olsa bile kodu kullanmanın hiçbir yasal dayanağı yoktur.

Lisans sorunlarının yargı alanınıza bağlı olarak sizi farklı şekillerde etkileyebileceğini belirtmekte fayda var: bu konu özellikle uluslararası telif hakkı anlaşmaları imzalayan ülkeler için geçerlidir. Örneğin, bu alandaki başlıca uluslararası anlaşmalardan biri olan Edebiyat ve Sanat Eserlerinin Korunmasına İlişkin Bern Sözleşmesi'nin şu anda 180 civarında üye ülkesi bulunmaktadır. Bu nedenle, açık izin olmadan kod kullanmak, telif hakkı yasalarını ihlal etmek anlamına gelir ve dünya çapında birçok yerde yasal savaşlara yol açabilir. Ancak bu, yazılı ve yazılı olmayan tüm kuralları ihlal ederek 'rahat' bir ülkeye gitmeniz gerektiği anlamına gelmez. Birbirimize saygı duyalım ve eğer birisi gelişiminin belirli amaçlar için kullanılmasını istemiyorsa, insani açıdan bakıldığında bile bunu yapmamak en iyisidir.

Çözüm: Otomatik kontrolleri ve güncellemeleri kullanın

Gördüğünüz gibi lisanslama ve telif hakkı sorunları karmaşıktır. Kendinizi ve şirketinizi önceden korumak için kullandığınız kütüphanelerin ve yazılımların lisanslarını kontrol etmeniz en doğrusudur. Kütüphaneler için bu çok zor değil; modern paket yöneticilerinin zaten bunun için araçları var. Örneğin, PHP bestecisinde bunu ` komutuyla yapabilirsiniz. besteci lisansları `, Python'da pip through ` pip lisansları ` ve Golang'da bu bilgiyi ` aracılığıyla alabilirsiniz. go-lisansları '.

Bağımlılıkları güncellerken bu komutları çağırmayı unutmayın (bu kontrolleri otomatikleştirmek daha da iyidir), çünkü bağlı bir kitaplığın lisansı yeni sürümlerde değişebilir.

3. Geliştirme sürümünüze erişim kısıtlı mı?

Web geliştirmede, bir projenin geliştirme (dev), kalite güvencesi (QA), aşamalandırma ve üretim gibi birden fazla sürümüne sahip olmak yaygındır. Sık sık, bir sitenin veya web projesinin geliştirme/QA ve hazırlama sürümlerinin İnternet'teki herkesin erişimine açık olduğu senaryolarla karşılaştım. Endişe verici bir şekilde, test sürümleri bazen arama motorları tarafından birincil sürüme göre daha etkili bir şekilde dizine eklenebilir ve bu genellikle ürüne zarar verir.

Buradaki asıl sorun, test sürümlerinin hatalar veya hassas, hatta belki de ödün verici bilgiler içerebilmesidir. Ek olarak, beta sürümleri genellikle son sürüme göre bilgisayar korsanlığına karşı daha savunmasızdır. Bu, bunların kullanılabilirliğinin bir saldırganın hassas verilere, dahili koda ve hatta sunucunun kendisine erişme riskini artırdığı anlamına gelir. API'nin test sürümlerine yetkisiz erişim son derece tehlikeli olabileceğinden, mobil uygulama gibi bir şey için arka uç geliştiriyorsanız bu özellikle doğrudur.

Güvenlik risklerinin ötesinde, yinelenen web sayfaları arama motoru sıralamalarını olumsuz yönde etkileyebilir. Google gibi arama motorları bu kopyaları istenmeyen içerik olarak görebilir ve projenizin orijinal sayfalarının sıralamasını düşürebilir, hatta bunları dizinden tamamen kaldırabilir.

Çözüm: Güvenlik stratejinizi en baştan tasarlayın

Domainlerden tasarruf etmeyin. Çevrimiçi olarak erişilebilen bir test sürümüne ihtiyacınız varsa, buna özel olarak ayrı bir alan adı satın alın. Bu basit ama etkili önlem, saldırganların genellikle önce alt alanları kontrol etmesi nedeniyle güvenlik risklerini azaltır. Test sürümünüzü ana kaynağın herhangi bir alt alanında barındırmak, onu kolay bir hedef haline getirir.

Tüm test sürümlerine erişimi kısıtlayın. Geliştirme, QA, hazırlama ve diğer sürümlerin genel erişime açık olmadığından emin olun. Örneğin, bunları yalnızca bir VPN aracılığıyla erişilebilecek şekilde yapılandırın. Bu, test alanı kötü niyetli aktörler tarafından bilinse bile yetkisiz erişim olasılığını azaltır.

Test sürümlerini dizine eklenmekten koruyun. Test sürümlerinize yalnızca VPN aracılığıyla erişilebiliyor ve ayrı gizli alanlarda barındırılıyor olsa bile, bunları bir "robots.txt" dosyası veya "noindex" meta etiketleri kullanarak arama motoru indekslemesinden koruyun. Arama motorları bazen bu sayfaları beklenmedik şekillerde bulup dizine ekleyebildiğinden bu adım çok önemlidir.

4. Gerçek IP adresiniz gizli mi? Kullanılmayan portlarınız kapalı mı?

Kritik öneme sahip olmalarına ve zorlu öğrenilen derslerle oluşturulmuş olmalarına rağmen birçok geliştiricinin gözden kaçırma eğiliminde olduğu güvenlik kuralları vardır. Böyle bir kural, projenizin gerçek IP adresini her zaman gizlemektir. Sunucularınızın IP adresi alan adı üzerinden belirlenebiliyorsa, bu durum aşağıdaki gibi birçok soruna yol açabilir:

• DDoS Saldırıları: Projenizin gerçek IP adresini bilen saldırganlar, sunucunuza Dağıtılmış Hizmet Reddi (DDoS) saldırısı başlatabilir. Örneğin, bir DNS Yansıma Yükseltmesi saldırı, sunucunuzu genel DNS sunucularından gelen çok büyük miktarda yanıtla bunaltabilir, hizmetinizin kullanıcılar tarafından kullanılamaz hale gelmesine ve önemli mali kayba neden olabilir.

  
  

• Potansiyel Güvenlik Açıklarının Belirlenmesi: Yalnızca amatörler değil, ciddi bilgisayar korsanları da açık bağlantı noktalarını ve ağa açık yazılımları tarayarak zayıf noktaları bulabilir ve bunlardan yararlanabilir. MongoDB gibi iyi bilinen hizmetlerde bile yanlış yapılandırma nedeniyle önemli veri ihlalleri yaşandı. Bu sorunların çoğu, gerçek IP adresinin gizlenmesiyle önlenebilir.

Çözüm: Potansiyel saldırganın hayatını daha karmaşık hale getirin

Sunucunuzun gerçek IP adresini gizleyerek saldırganların sisteminizi hedeflemesini çok daha zorlaştırırsınız. İçerik Dağıtım Ağı (CDN) veya DDoS koruma hizmetlerinin kullanılması burada çok etkili olabilir. Popüler seçenekler şunları içerir: BulutFlare Hem CDN yeteneklerini hem de DDoS korumasını ücretsiz olarak sunan ve ayrıca aşağıdaki hizmetleri sunan İmperva (eski adıyla Incapsula) benzer işlevler sağlar ve Qrator Web uygulamalarını bir Web Uygulaması Güvenlik Duvarı ile koruma konusunda uzmanlaşmıştır, ancak bunun maliyeti olabilir.

Bu araçlar güvenliği önemli ölçüde artırabilse de akılda tutulması gereken ek hususlar vardır:

• E-posta Başlığı IP Sızıntısı: E-posta göndermek için ana sunucunuzu kullanırsanız, gerçek IP adresi e-posta başlıklarında açığa çıkabilir ve bu da güvenlik çabalarınızın boşa gitmesine neden olabilir.

  
  

• IP Geçmişi ve Whois İstekleri: Gibi hizmetler DNS Geçmişi veya Whois Talebi bir etki alanıyla ilişkili geçmiş IP adreslerini ortaya çıkarabilir. Gerçek IP'niz çalışma alan adınıza bağlanmışsa onu değiştirmelisiniz.

  
  

• DDoS Koruması ve API Uç Noktaları: API uç noktaları olarak hizmet veren alanlar için DDoS korumasını kullanırken dikkatli olun. Koruma sistemleri, JSON/XML yanıtlarını HTML koduyla değiştirerek istemci tarafı uygulamalarınızın işleyişini bozabilecek kullanıcı doğrulama adımları sunabilir.

  
  

• Giden API İstekleri: Sunucunuz üçüncü taraf API'lere istek gönderdiğinde, yanlışlıkla IP adresini açığa çıkarabilir. Proxy'yi değiştirmek, saldırının sonuçlarıyla uğraşmaktan daha kolay olduğundan, bu tür istekler için proxy sunucuların kullanılması yardımcı olabilir.

Projenizin gerçek IP adresini saklamanın her derde deva bir önlem olmadığını unutmamak önemlidir. Yazılımınız tarafından kullanılan bağlantı noktalarını harici ağdan kapatmak, mümkün olan her yerde çok önemlidir. Standart bağlantı noktalarını değiştirmek tartışmalı bir uygulamadır; bazı uzmanlar bunun kurulumunuzu önemli bir fayda sağlamadan karmaşıklaştırdığını savunuyor. Çoğu zaman, yazılımın ağ TCP bağlantıları yerine Unix yuvaları aracılığıyla etkileşim kuracak şekilde yapılandırılması tercih edilir (eğer hem projeniz hem de yazılımınız aynı sunucuda çalışıyorsa). Bu yaklaşım etkileşim hızını artırmanın yanı sıra açık bağlantı noktalarına olan ihtiyacı ortadan kaldırarak güvenliği de artırıyor.

Veritabanı yönetim sistemleri (DBMS) veya ayrı sunuculardaki diğer dahili hizmetler için erişimin, kesinlikle kontrol ettiğiniz belirli IP adresleriyle sınırlı olduğundan emin olun. Bu kurulum, kritik sistemlere yetkisiz erişimi önler, ekstra bir güvenlik katmanı ekler ve harici saldırı ve veri sızıntısı risklerini en aza indirir.

5. Proje bağımlılıklarını ve yazılımı güncelliyor musunuz?

Bu tavsiye oldukça basittir ancak yine de sıklıkla gözden kaçırılır: projenizin bağımlılıklarını ve sunucu yazılımını düzenli olarak güncelleyin. Güncelliğini yitirmiş ve savunmasız kod, onu kolayca istismar edebilecek saldırganların hayalidir.

Çözüm: Güncellemelerinizi otomatikleştirin

Her şeyi manuel olarak güncellemenize gerek yok; birçok otomasyon aracı yardımcı olabilir. Örneğin, Bağımlı robot GitHub'da güncel olmayan veya savunmasız bağımlılıkları otomatik olarak algılar ve güncellemeler önerir.

Güvenlik sertifikalarının yenilenmesinin otomatikleştirilmesi de çok önemlidir. Eğer kullanırsan Haydi Şifreleyelim sertifikaların yenilenmesini otomatik hale getirebilirsiniz. Sertifikabot . Süresi dolmuş sertifikalar ciddi sıkıntılara neden olabilir, ancak bunların yenilenmesini otomatikleştirmek basit bir iştir.

\Aynı prensip sunucu yazılımı için de geçerlidir. Eğer Linux ile, özellikle de Debian/Ubuntu tabanlı dağıtımlarla çalışıyorsanız, Katılımsız yükseltmeler görevi kolaylıkla halledebilir. Birçok sunucunun bulunduğu daha büyük projeler için aşağıdaki gibi araçlar Yanıtlayıcı , Şef , Kukla , veya Tuz mevcut.

Son düşünceler

Burada verilen ipuçları, arka uç geliştiricilerinin hatırlaması gerekenlerin yalnızca bir kısmıdır. gibi yaygın konularla karşılaştırıldığında önemli ancak daha az tartışılan konuları vurgulamayı seçtim. SQL enjeksiyonu veya CSRF saldırılar.

Web uygulaması güvenliğine ilişkin daha derin bir anlayış için aşağıdakileri keşfetmeyi düşünün: OWASP Vakfı değerli kaynaklar sunan kar amacı gütmeyen bir kuruluş. OWASP İlk On Web sitelerinde bulunan belge, en yaygın ve kritik web uygulaması güvenlik risklerini listeler. Ayrıca daha az bilinen ancak aynı derecede tehlikeli saldırılar hakkında da bilgi bulacaksınız.

Geliştirici topluluğunun içgörü ve deneyimleri paylaşma konusunda hem bilgili hem de destekleyici olması gerektiğine inanıyorum. Bu nedenle herkesi, backend geliştirme alanında çalışan herkes için değerli olan gözlemlerini ve yorumlarını paylaşmaya davet ediyorum!