[Owasp-turkey] FW: [Fwd: [netsec] WordPress Kritik Guvenlik Acigi]

Bedirhan Urgun urgunb at hotmail.com
Thu May 31 09:26:37 EDT 2007


 


Date: Thu, 31 May 2007 15:54:19 +0300From: keremskusmezer at gmail.comTo: urgunb at hotmail.comSubject: Re: [Owasp-turkey] [Fwd: [netsec] WordPress Kritik Guvenlik Acigi]
Aynen, sadece bu validasyon rulelarini external bir resource'ta tutuyorsunuz diyelim, external resource config file etc. update olunca validasyon engine tekrardan bu kurallari yukleyip buna gore calismaya basliyor, boylece projenin kodunda bir degisiklik yapmadan bir whitelist'e gore direkt olarak validasyonu saglamish oluyorsunuz. 
 
Public Method olayida public olarak class tarafindan expose edilmis olan methodlarda mesela fxcop tarafindan bu propertylerin null vs. validasyonlarinin mutlaka yapilmasinin force edilmesine dayaniyor. 
31.05.2007 tarihinde Bedirhan Urgun <urgunb at hotmail.com> yazmış: 

  yanlis anlamadiysam, runtime'da (yurutme zamaninda) degisiklikleri yapinca bi downtime (kesinti) olmasin diye herhalde.


Date: Thu, 31 May 2007 09:19:28 +0100From: ferruh at mavituna.comTo: keremskusmezer at gmail.comCC: owasp-turkey at lists.owasp.org 
Subject: Re: [Owasp-turkey] [Fwd: [netsec] WordPress Kritik Guvenlik Acigi]Sadece public ve shared (veya degil) bir methodu cagirsak yeterli degil mi? Yoksa bir noktayi mi kaciriyorum ? 
On 31/05/07, Izzet Kerem Kusmezer < keremskusmezer at gmail.com> wrote: 

Cut/Paste kesinlikle kod sagligina zararli :) 
 
Public olarak expose edilen methodlarda library'in durumuna veya input'un nasil olarak geldigine bagli olarak bu kontrol yapilabilir.
Cunku diyelim 3 layer'dada ayni durumu kontrol ettik, bir degisiklik istegi geldigi zaman 3 layer'da ayri ayri olarak degistirilme ihtiyaci doguracak.
 
Bundan dolayi validasyon motorunu enterprise library 3'te oldugu gibi, sadece runtime'da calisan bir motor haline getirip, gerekli validasyon kurallarinin uygulanmasini reflection tabanlı bir sistem ile gerceklestirmek ciddi anlamda bakim maliyetlerini dusurecektir kanaatimce.  
2007/5/30, volkan uzun <vuzun at csusb.edu>: 



 Aralik kontrolleri veya bu tip kontrolleri kategorilendirmek gerekirse :

is katmanina ait kontroller ( business layer) : ornek: satis miktari eliminizdeki maldan cok olamaz : bunu ancak veritabanini check edecek bir katman anlayabilir, 
sunum katmanina ait kontroller ( presentation layer ) : kisinin yasi negatif olamaz, gelis tarihi gidis tarihinden sonra olamaz gibi 
veritabanina kayit ederken kontroller : mesela bir kolon negatif olamaz, null olamaz gibi  
Simdi Izzet beyin sorusuna gelirsek, bence evet her modulde ayri ayri kontrol gerekiyor; neden ? cunku her modulu biz yazmiyoruz, bir onceki ya da bir sonraki programcinin kontrolup yapip yapmadigini bilemezsiniz, veya her modulu biz yazmissakta; kodu ileride bakimini yapacak kisi, kodu degisirirken herhangi bir modulu kirabilir. ben cut/paste yaparken arada o kadar co kkodun kayboldugunu gordum ki J mesela kodu debug ederken, su kontrolu cut ediyim sonra paste ederim derken aa bir bakmissin kod gitmis tarzi soyler cok oldu, bu yuzden kontroller cok cabuk kayboluyor J yani ben oyle yapmam diyorsanizda; iste benim gibileri var; kodunuzun ileride bakimini yapacak kisi benim gibiyse; yandiniz J hazirlikli olun son not : cut/copy + paste = DEVIL yapmayalim J   


From: Izzet Kerem Kusmezer [mailto: keremskusmezer at gmail.com] Sent: Wednesday, May 30, 2007 5:57 AM To: volkan uzun; owasp-turkey at lists.owasp.org 
Subject: Re: [Owasp-turkey] [Fwd: [netsec] WordPress Kritik Guvenlik Acigi]

 
Diye girdi denetim kontrolleri her katmanda ayri ayri olarak gerceklestirildi, bu durumda girdiyle ilgili olarak mesela bir aralik kontrolu yapan validasyon kodunu her modulde ayri ayri olarak gerceklestirmek gerekmeyecek mi? 
2007/5/25, volkan uzun <vuzun at csusb.edu >: 

Konunun basini belki biraz kacirdigim icin alakasiz olabilir JBen girdinin her asamada kontrolunden yanayim, cunku girdinin ilk alindigi ( diyelim ki kullanici webden giris yapti ), ortamdan son asamaya dek her zaman ayni programci yazmiyor. Mesela; ben business katmanindaki kodu yaziyorsam; maalesef ui tarafini yazip; benim siniflarima istekte bulunacak programciya guvenemem herseyi kontrol etmis mi diye; hatta ve hatta test gruplarinin test islemlerinde aciklari bulmasina da guvenemem, benim yapmam gereken yazdigim her module gelecek girdinin sanki sistemi bozmaya calisacak bir kullaniciya ait oldugunu dusunmek; ve ona gore onlem almak olmali. Butun modulleri ayni programci yazsa bile gene her asamada kontrolden yanayim J cunku bu seferde ileride kodun bakimini, optimizasyonunu yapacak kisinin napacagina guvenemem, bir modulu bozup farkinda olmayarak diger module denetimsiz parametre yollayabilir.   



From: owasp-turkey-bounces at lists.owasp.org [mailto: owasp-turkey-bounces at lists.owasp.org] On Behalf Of Bunyamin DEMIRSent: Friday, May 25, 2007 9:26 AMTo: burak.dayioglu at pro-g.com.tr; Ferruh Mavituna; Bedirhan UrgunCc: owasp-turkey at lists.owasp.orgSubject: Re: [Owasp-turkey] [Fwd: [netsec] WordPress Kritik Guvenlik Acigi]  

Şimdi herkes "girdi denetimi" konusunda mutabık. Hatta ilk "iyi programlama" konulu kitaplar bile bundan bahsetti diyoruz. Zaten burasına kimsenin takıldığı yok. Mevzu denetimin hangi aşamada başlaması? Hangi aşamada yoğulaşması? Hangi aşamada bitmesi? Dayatma olmasın tabide.. İzlediğim yolu belirteyim. Genelde temel kontrolleri en başta yaparım. Yani bir kullanıcını kredi kartı numarası girmiş ise onu aldığım yerde denetlerim. Fakat bir fonksiyon çağırılacaksa. Onu çağıran parametreyi fonksiyonun çağrıldığı yerde-dosyasında denetlerim. Örneğin,Sisteme login olduk. Kullanıcı adı şifre denetlenmesinden geçtik. İçeride bir linke bastığımızda (listele).  Giden parametre çağrıldığı yerde zaten biliniyor. Biraz daha açayım. Bu sayfaya gelen talepler ancak ve ancak "listele,goster" olabilir onun dışında gelen her türlü parametreyi salla gitsin. Bu birazda güvenlik kontrolünü parçalara yaymaya yarıyor. Gerçi ilk etapta girdinin kontrolüne daha yakın bir plan. Umarım anlatabilmişimdir:)
25.05.2007 tarihinde Burak DAYIOGLU < burak.dayioglu at pro-g.com.tr > yazmış:On Fri, 2007-05-25 at 12:16 -0400, Bedirhan Urgun wrote:>  neyse sanirim hepimiz ayni seyden yanayiz, tek denetim degil (ama > giriste mutlaka olabildigince kisitlilayici bir sekilde) katmanli > denetim gerekli sonra da cikti denetimi (html encode, url encode,> canonicalize v.b.). Ama sanirim her fonksiyonda girdi denetim> yapilmasi sıkıntıya sokar gelistiriciyi. En azindan ben> dellenirim... :) >  bedirhan"Dellenecek" bir sey yok. Butun "iyi programlama" kitaplari saglamprogramlama (robust programming) icin beklenmedik parametrelere/girdilere hazirliktan soz eder, konu guvenlik olmadan coook once bile yazilmis "nasil iyi yazarsiniz" kitaplarinin hemenhepsinde bu var... :)sevgiler.-burak "muhalif" dayioglu _______________________________________________Owasp-turkey mailing listOwasp-turkey at lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-turkey -- Bunyamin DemirOWASP-Turkey Chairhttp://www.webguvenligi.org 
_______________________________________________Owasp-turkey mailing listOwasp-turkey at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-turkey  _______________________________________________Owasp-turkey mailing listOwasp-turkey at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-turkey _______________________________________________Owasp-turkey mailing listOwasp-turkey at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-turkey -- Ferruh Mavitunahttp://ferruh.mavituna.com 

Change is good. See what's different about Windows Live Hotmail. Check it out!
_________________________________________________________________
Change is good. See what’s different about Windows Live Hotmail.
www.windowslive-hotmail.com/learnmore/default.html?locale=en-us&ocid=TXT_TAGLM_HMWL_reten_changegood_0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-turkey/attachments/20070531/1136cb6d/attachment.html 


More information about the Owasp-turkey mailing list