Barış

Barış

WFN Üye
Konular
552
Mesajlar
552
Çözüm
0
Ticaret Puanı
0
Üyelik
24 Gün
Konum
Kastamonu
Web Sitesi
Var
Alanı
Google ADS
1/1
Konu sahibi
İlk adım, uygulamanın kullandığı JDK sürümünü güncel güvenlik düzeltmeleriyle birlikte sabitlemek; ardından tehdit modelini çıkarıp gizli bilgileri koddan ayırmak, girdileri doğrulamak, veritabanı ve ağ iletişimini güvenli yapılandırmak, kriptografik işlemlerde Java’nın güvenli API’lerini kullanmak ve bütün bunları testlerle doğrulamaktır. Java’nın tür güvenliği ve bellek yönetimi bazı hata sınıflarını azaltır; ancak yetkilendirme, gizli bilgi yönetimi, güvenli ağ iletişimi ve iş kuralları ayrıca tasarlanmalıdır.

Güvenlik çalışmasına başlamadan önce kapsamı belirleyin​


Önce uygulamanın koruduğu varlıkları yazın: kullanıcı hesapları, oturum belirteçleri, ödeme bilgileri, kişisel veriler, yönetici işlemleri ve dış sistem erişim anahtarları. Her varlık için şu soruları cevaplayın: Bu veriye kim erişebilir, hangi işlem yapılabilir, saldırgan bunu ele geçirirse ne olur ve olay nasıl fark edilir?

Bu çalışma yalnızca parola veya şifreleme seçmekten ibaret değildir. Örneğin bir kullanıcının kendi profilini görmesi ile başka kullanıcıların profillerini değiştirebilmesi farklı yetkilerdir. Sunucu tarafında her istekte kimlik doğrulamasını ve işlem yetkisini ayrı ayrı kontrol edin; yalnızca arayüzde düğmeyi gizlemek yetki kontrolü sayılmaz.

JDK, bağımlılık ve çalışma ortamını sabitleyin​


Üretim, test ve geliştirme ortamlarında aynı ana Java sürümünü ve mümkünse aynı güncelleme seviyesini kullanın. Bağımlılık sürümlerini açıkça sabitleyin; sürüm aralıklarını rastgele güncelleyen yapılandırmalardan kaçının. Derleme sırasında bağımlılıkların güvenlik taramasını çalıştırın ve kullanılmayan kütüphaneleri kaldırın.

Gizli anahtarları, veritabanı parolalarını ve erişim belirteçlerini kaynak koduna, Git deposuna, hata mesajına veya normal uygulama günlüğüne koymayın. Bunları çalışma ortamının gizli bilgi deposundan ya da işletim sistemi ortam değişkenlerinden okuyun. Uygulama başlarken zorunlu bir gizli bilgi eksikse güvenli varsayılanla devam etmek yerine açık hata vererek durması, yanlış yapılandırmanın fark edilmesini sağlar.

Girdiyi doğrulayın ve sorguları parametreleyin​


İstemciden gelen veriyi güvenilir kabul etmeyin. Tür, uzunluk, biçim, izin verilen değerler ve iş kuralı sınırlarını sunucu tarafında kontrol edin. Hata mesajlarında veritabanı sorgusunu, dosya yolunu, erişim belirtecini veya yığın izini kullanıcıya göstermeyin; ayrıntıyı yalnızca erişimi kısıtlanmış teknik günlüğe yazın.

SQL sorgularında kullanıcı verisini metin birleştirmeyle eklemeyin. JDBC kullanıyorsanız parametreli sorgu tercih edin:

Java: 
String sql = "SELECT id, email FROM users WHERE email = ?";
try (PreparedStatement statement = connection.prepareStatement(sql)) {
    statement.setString(1, emailFromRequest);
    try (ResultSet result = statement.executeQuery()) {
        // Sonucu uygulamanın yetki kurallarına göre işleyin.
    }
}

Bu örnek SQL enjeksiyon riskini azaltır; ancak kullanıcının bu kaydı görmeye yetkili olduğunu kanıtlamaz. Sorgudan sonra veya sorgu tasarımının parçası olarak kaynak sahipliği ve rol kontrolü de yapılmalıdır.

Kriptografiyi kendiniz uygulamayın​


Rastgele belirteç, parola sıfırlama kodu veya tek kullanımlık değer üretirken java.util.Random yerine kriptografik olarak güçlü SecureRandom kullanın. Java belgeleri, güçlü bir uygulama seçimi için SecureRandom.getInstanceStrong() yöntemini ve sağlayıcıların güçlü algoritma listesini tanımlar.

Java: 
SecureRandom random = SecureRandom.getInstanceStrong();
byte[] tokenBytes = new byte[32];
random.nextBytes(tokenBytes);
String token = Base64.getUrlEncoder()
        .withoutPadding()
        .encodeToString(tokenBytes);

Parolaları düz metin olarak saklamayın ve yalnızca hızlı bir özet algoritmasıyla, örneğin doğrudan SHA-256 ile saklamayın. Parola için uygun maliyet ayarı bulunan, tuz kullanan ve doğrulama işlevi sağlayan bir parola-hash kütüphanesi kullanın. Tuz, her parola için ayrı üretilmeli ve hash ile birlikte saklanmalıdır; gizli anahtar değildir. Parola doğrulamasının başarılı olması, kullanıcının işlem için yetkili olduğunu tek başına göstermez.

Ağ iletişimini ve sertifika doğrulamasını koruyun​


Dış servislerle iletişimde TLS kullanın ve sertifika doğrulamasını kapatmayın. “Her sertifikaya güven” biçimindeki özel TrustManager veya hostname doğrulamasını devre dışı bırakan kod, testte geçici çözüm gibi görünse de üretimde araya girme saldırılarına yol açabilir. Java’nın güvenlik kılavuzu TLS, PKI ve sağlayıcı yapılandırmaları için JSSE ve ilgili güvenlik API’lerini kapsar.

Bağlantı hatası alırsanız önce hedef alan adını, sistem saatini, sunucunun sertifika zincirini ve istemcinin güvenilen sertifika deposunu kontrol edin. Sertifika doğrulamasını kapatmak yerine eksik veya yanlış sertifikayı düzeltilmiş güven zinciriyle giderin.

Dosya, serileştirme ve günlük güvenliğini kontrol edin​


Kullanıcının gönderdiği dosya adını doğrudan dosya sistemi yolu olarak kullanmayın. Dosyayı uygulamanın belirlediği güvenli bir dizine kaydedin, dosya adını sunucu tarafında üretin, izin verilen boyut ve türleri sınırlayın ve sembolik bağlantı ile yol geçişi denemelerini engelleyin.

Güvenilmeyen veriyi Java nesne serileştirmesiyle doğrudan açmak yerine güvenli ve açık bir veri biçimi kullanın; zorunlu serileştirme durumunda sınıf ve veri doğrulamasını sınırlandırın. Java belgeleri serileştirme ve güvenli kodlama kılavuzlarını ayrı güvenlik konuları olarak sunar.

Günlüklerde parola, oturum belirteci, erişim anahtarı ve kişisel verileri maskeleyin. Tanılama amacıyla ayrıntılı günlük açtıysanız işlem bittiğinde kapatın; hata yanıtlarında iç sınıf adlarını, dosya yollarını ve yığın izlerini dışarı vermeyin.

Sonucu testlerle doğrulayın​


Güvenli uygulama adımlarının tamamlandığını yalnızca uygulamanın normal çalışmasıyla kabul etmeyin. En azından şu kontrolleri otomatikleştirin:
  • Yetkisiz kullanıcı isteğinde beklenen reddetme kodu ve güvenli hata gövdesi dönüyor mu?
  • Bir kullanıcı başka bir kullanıcının kimliğini veya kaynak numarasını değiştirerek veriye erişebiliyor mu?
  • Geçersiz, aşırı uzun ve beklenmeyen türdeki girdiler reddediliyor mu?
  • TLS sertifika veya hostname doğrulaması bozulduğunda bağlantı gerçekten kesiliyor mu?
  • Günlüklerde parola, belirteç ve anahtar bulunuyor mu?
  • Bağımlılık taraması, derleme ve dağıtım sırasında hata verdiğinde yayın duruyor mu?
Bir test başarısız olursa yalnızca hata mesajını değil; isteğin kimliğini, kullanılan rolü, kaynak sahibini, uygulama sürümünü ve güvenlik kuralının beklenen sonucunu kaydedin. Sorun düzeltilince aynı testin yeniden geçtiğini ve yeni düzeltmenin başka bir yetki yolunu açmadığını doğrulayın. Güvenli uygulama, tek bir sınıf veya kütüphane seçimi değil; güncelleme, doğrulama, yetkilendirme, gizli bilgi yönetimi, güvenli iletişim ve sürekli testlerin birlikte işletilmesidir.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Üye ol
Foruma git ?

Bu konuyu görüntüleyen kullanıcılar

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Robotlar:
  • Anthropic
Toplam: 1 (Üye: 0, misafir: 0, robot: 1)