Veri girişi doğrulama - Nerede? Ne kadar? [kapalı]


28

Veri girişi doğrulama her zaman benim için oldukça iç bir mücadele oldu.

Eski uygulamamıza yeniden yazma projemize gerçek bir güvenlik çerçevesi ve kodu eklemenin eşiğinde (şu ana kadar kart kalesi güçlü eski güvenlik kodunu ve veri doğrulamasını tutar), ne kadar doğrulamam gerektiğini merak ediyorum. nerede vb

Profesyonel Java geliştiricisi olarak 5 yılı aşkın süredir veri girişi doğrulama ve güvenlik önlemleri için kişisel kurallarımı oluşturup geliştirdim. Yöntemlerimi geliştirmeyi sevdiğim için, bazılarının sizden bazı fikirler duymasını istiyorum. Genel kurallar ve prosedürler gayet iyi ve Java'ya özgü kurallar da var.

Özetle, bunlar benim kısa açıklamalarım olan kılavuzlarımdır (3 katmanlı bir web uygulaması tarzında açıklanmıştır):

  • 1. kademe müşteri tarafı (tarayıcı): minimum doğrulama, yalnızca değişmeyen kurallar (zorunlu e-posta alanı, bir öğe seçmeli ve benzeri); "6 ile 20 karakter arasında" gibi ek doğrulama işlemlerinin kullanımı daha az sıklıkta görülür; çünkü bu, değişikliklerle ilgili bakım çalışmalarını artırır (işletme kodu sabit olduğunda eklenebilir);

  • 1. kademe sunucu tarafı (web iletişimi işleme, "denetleyiciler"): Bunun için bir kuralım yok, ancak yalnızca veri işleme ve montaj / ayrıştırma hatalarının burada ele alınması gerektiğine inanıyorum (doğum günü alanı geçerli bir tarih değil); buraya daha fazla doğrulama eklemek, onu gerçekten sıkıcı bir işlem haline getirir;

  • 2. kademe (iş katmanı): sağlam sağlam doğrulama, daha az değil; giriş veri formatı, aralıklar, değerler, metodun herhangi bir zamanda çağrılıp aranamayacağı iç durum kontrolü, kullanıcı rolleri / izinleri, vb .; mümkün olduğunca az kullanıcı giriş verisi kullanın, gerekirse veritabanından tekrar alın; Eğer alınan veritabanı verilerini de girdi olarak kabul edersek, sadece bazı spesifik verilerin DB'ye yeterince güvenilmez veya bozuk olduğu biliniyorsa doğrularım - güçlü yazma işlemi burada işin çoğunu yapar, IMHO;

  • 3. katman (veri katmanı / DAL / DAO): burada sadece çok fazla doğrulama gerekmediğine inanılmadı, çünkü sadece iş katmanının verilere erişmesi gerekiyordu ("param2 doğruysa boş olmamalıdır" gibi bazı durumlarda doğrulayın); Ancak, "burada" derken, "veritabanına erişen kod" veya "SQL yürütme yöntemleri" derken, veritabanının kendisinin tamamen zıttır;

  • veritabanı (veri modeli): iyi birincil anahtarlar, yabancı anahtarlar, kısıtlamalar, veri türü / uzunluğu / büyüklüğü ile DB üzerinde mümkün olduğunca yanlış ve bozuk veri oluşmasını önlemek için iyi düşünülmüş, güçlü ve kendi kendini zorlayıcı olmalı / precision ve diğerleri - Kendi özel tartışmaları olduğu için tetikleyicileri bunun dışında bırakıyorum.

Erken veri doğrulama işlemlerinin iyi ve performans açısından iyi olduğunu biliyorum, ancak tekrarlanan veri doğrulama işlemleri sıkıcı bir işlemdir ve veri doğrulama işlemlerinin kendisinin oldukça can sıkıcı olduğunu kabul ediyorum. Bu yüzden birçok kodlayıcı bunu atlıyor ya da yarısını yapıyor. Ayrıca, yinelenen her doğrulama, her zaman senkronize edilmemeleri durumunda olası bir hatadır. Bugünlerde tercih ettiğim başlıca nedenler, iş katmanına yapılan onayların çoğunun zamana, bant genişliğine ve CPU'ya göre durum bazında ele alınan istisnalar olmasına izin veriyor.

Peki bunun hakkında ne düşünüyorsun? Görüşlerin karşısında mı? Başka prosedürleriniz var mı? Böyle bir konuya bir referans? Her türlü katkı geçerlidir.

Not: Java'nın bir şey yapmanın yollarını düşünüyorsanız, uygulamamız Spring Spring'e dayanmaktadır. Spring Security ürününü güvenlik sağlayıcımız ve JSR 303 (Hibernate Validator?) Olarak eklemeyi planlıyorum

Teşekkürler!


Düzenleme: 3. kattaki bazı ekstra açıklamalar.


Tavsiyem Hazırda Bekletme Validatorunun nasıl çalıştığını incelemektir. Temel olarak doğrulamaya dayanan iş kurallarına sahip olduğum için JSR 303'ün onaylama süresinin devam etmesi için yararlı olacağını bulamamışken, bazı kurallarım süreklilikten önce uygulanmalıdır. Benim düşünceme göre, çok yakın bir model için çalışıyor; belki de yanlış kullanıyordum, ama benimkinden farklı deneyimleri olan birini bulamadım.
Vineet Reynolds

@Vineet Reynolds Zaten Spring MVC ile form doğrulama için kullandım, gerçekten harika bir kombinasyon. İnce taneli mesajlarla, çok az çabayla veya hiç çaba sarf etmeden, kullanıcıya uygun bir hatayla sunucu tarafında doğrulama alıyorum. Hala avantajlarından emin değil, tamamen sunucu tarafı nesneler üzerinde test ediyorum. Bu örnek gönderiye
mdrg

2
çok fazla doğrulama koymak . Her yer bu kullanıcı girişlerini kahretsin @ #! ! @@!
Chani

Yanıtlar:


17

Doğrulamanız tutarlı olmalı. Bu nedenle, bir kullanıcı web formuna geçerli olduğu belirlenen bir veri girerse, müşteri tarafında uygulamadığınız bazı kriterler nedeniyle veritabanı katmanı tarafından reddedilmemelidir.

Bir kullanıcı olarak, veriye bir sayfalık veri girmenin, sadece veri tabanına yapılan önemli bir gidişattan sonra bir şeyin yanlış olduğu söylendiğinde, doğru bir şekilde doğru bir şekilde girilmesi daha sinir bozucu olmazdı. Bu süreçte bazı müşteri doğrulama işlemlerini başlattıysam, bu özellikle doğrudur.

Doğrulamayı, bunları ortaya çıkarırken çeşitli seviyelerde tutmanız ve potansiyel olarak onları kimin aradığı üzerinde kontrol etmemelisiniz. Bu nedenle, doğrulamanızın tek bir yerde tanımlanması ve ihtiyaç duyulduğu her yerden çağrılması için (mümkün olduğunca) düzenleme yapmanız gerekir. Bunun nasıl düzenlendiği, dilinize ve çerçevenize bağlı olacaktır. Silverlight'ta (örneğin) sunucu tarafında tanımlayabilirsiniz ve uygun niteliklerle burada kullanılmak üzere istemci tarafına kopyalanacaktır.


2
+1 Kesinlikle. ASP.NET MVC için de aynı şeyi söyleyecektim ama sen beni yendin. :) Gerçekten, bir sistemin geçerli bir durumda kaldığından emin olmak için sadece yerinde doğrulama İHTİYACIM VAR. Müşteri tarafı gibi yapılan onaylamanın geri kalanı, kullanıcı için boşa harcanabilirliği ve zamanı arttırmaktır, bu nedenle ana odak noktası bu olmalıdır. Tutarlılık anahtarıdır.
Ryan Hayes

2
"Gidiş-dönüş" hakkında, sayfa uygun hata mesajları ile yeniden yüklendiği ve daha önce yazdıklarınızla dolu olan tüm alanlar doldurulduğu sürece hiçbir sorun görmüyorum (çoğu arayüz bu son ayrıntıda yetersiz kalmaktadır). Hatalarla başa çıkmak çok uzun sürerse, bu ek müşteri tarafı doğrulaması için bir adaydır.
mdrg

Ve doğrulama, uygulama genelinde kolayca çoğaltılabiliyorsa, bunu boşa harcamak için hiçbir neden yoktur. Sunucu tarafında kolaydır, ancak müşteri tarafında, bahsettiğiniz gibi bir doğrulama aracı olmadan, çok sinir bozucu olur (yani: sunucuda yazdığınız gibi, bir sürü JS doğrulama kodu yazmak) .
mdrg

10

İlişkisel bir sistemde, bunu üç katmanlı bir yaklaşım olarak görüyorum. Her katman aşağıdakiler tarafından sınırlandırılmıştır:

  • Sunum / UI
    • basit giriş doğrulama
    • giriş yanlış formattaysa devam etmeyin
    • "gate" istemcisi, daha iyi kullanılabilirlik ve daha düşük bant genişliği / zaman kaybı için sunucuya gidiş dönüşleri azaltma talebinde bulunur
  • Mantık
    • iş mantığı ve yetkilendirme
    • Kullanıcıların yapmasına izin verilmeyen şeyleri yapmalarına izin verme
    • "türetilmiş" özellikleri ve burada durumu belirtin (veritabanında denormalize edilecek şeyler)
  • Veri
    • temel veri bütünlüğü katmanı
    • kesinlikle herhangi bir çöp depolamak reddetme
    • DB'nin kendisi veri formatlarını zorlar (int, tarih vb.)
    • uygun ilişkileri sağlamak için veritabanı kısıtlamaları kullanın

Bunun için ideal cevap, üç katmandaki kısıtlamaları tek bir yerde tanımlamanıza izin veren bir sistem olacaktır. Bu, SQL için bir miktar kod üretmeyi ve en azından müşteri ve sunucu için veri güdümlü onaylamayı içerecektir.

Burada gümüş mermi olup olmadığını bilmiyorum ... ama JVM'ye girdiğinden beri, en azından müşteri ile sunucu arasında JavaScript doğrulama kodunu paylaşmak için Rhino'ya bakmanı öneririm. Giriş onayınızı iki kez yazmayın.


Rhino'ya bir göz atacağım. Spring MVC form doğrulama ile bir şekilde bütünleşebiliyorsa, çok daha iyi.
mdrg

8

• 3. seviye (veri katmanı / DAL / DAO): burada sadece çok fazla doğrulama gerekmediğine inanılmadı, çünkü sadece iş katmanının verilere erişmesi gerekiyordu ("param2 doğruysa boş olmamalıdır" gibi bazı durumlarda doğrulayın) .

Bu çok yanlış. Doğrulamanın yapılacağı en önemli yer veritabanının kendisindedir. Veriler neredeyse her zaman uygulamadan daha fazla etkilenir (olmayacağını düşündüğünüz zaman bile) ve en iyi ihtimalle veritabanına uygun kontroller koymamaktan sorumlu değildir. Bunu yapmama kararından, diğer faktörlerden daha fazla veri bütünlüğü kaybı var. Veri bütünlüğü, veritabanının uzun süreli kullanımı için çok önemlidir. İyi düzeyde veri içeren veritabanı seviyesinde bütünlük kurallarını uygulayamayan herhangi bir veritabanı görmedim (ve verileri tam anlamıyla binlerce veritabanında gördüm).

Benden daha iyi olduğunu söylüyor: http://softarch.97things.oreilly.com/wiki/index.php/Database_as_a_Fortress


Bu yazı ile son bölümü kabul ediyorum, sanırım bu konuda kendimi netleştirmedim. Soruyu daha fazla ayrıntıyla güncelledim. Teşekkürler!
mdrg

2

Yukarıdakilerin tümü, geliştiricilerin ve bakıcıların mükemmel olduğu varsayımını yapar ve her zaman kusursuz çalışan mükemmel bir kod yazar. Gelecekteki yazılım sürümleri, yaptığınız ve hiç belgelenmediğiniz tüm varsayımlar ve sisteme asla hayal etmediğiniz şekillerde veri koyan kullanıcılar ve bilgisayar korsanları hakkında bilgi sahibidir.

Tabii ki, çok fazla doğrulama kötü bir şeydir, ancak programlar, ağlar ve işletim sistemleri mükemmel olduklarını varsayarsak, bilgisayar korsanları güvenlik duvarınızdan geçemez, bir DBA'lar veritabanını elle "tweak" yapmaz.

Nesnelerin etrafına sınır çemberleri çizin, koruduğu arıza modlarını belirleyin ve bu sınır için uygun bir kontrol seviyesi uygulayın. Örneğin, veritabanınız hiçbir zaman geçersiz veriler görmemelidir, ancak bu nasıl olabilir ve ne olursa? Kullanıcınız kim, başarısızlığın maliyeti nedir?

Fiziksel dünya güvenlik modellerini inceleyin, güvenlik bir soğan gibi katmanlar halinde olmalıdır. Bir kalın duvarın zayıf güvenlik olduğu kabul edilir. Veri doğrulama aynı şekilde düşünülmelidir.


1

Doğrulama için iki kısa, genel kural:

Garantisi olmayan herhangi bir şeyi arayacaksanız, arayan kişiye geri alabileceğiniz şekilde geçersiz giriş hakkında size bilgi verecek bir şey (hata, istisna) getirecektir, doğrulayın.

Verilerle başka bir şey yapacaksanız (karar verin, matematik yapın, saklayın, vb.), Doğrulayın.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.