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

Ferruh Mavituna ferruh at mavituna.com
Fri May 25 11:12:16 EDT 2007


Merhaba,

Sorun su ki genelde yazilimlarda bir bilgi birden cok yerde kullanilmak icin
uygulamaya geliyor. Dolayisiyla ilk adimda hangi filtrelerden gecmesi
gerektigini bilemiyorsunuz. Buna ragmen tabii ki cok kaba filtreleme
yapilabilir. Bu yuzden kullanim noktasindan filtreden gecirmenin daha iyi
oldugunu dusunuyorum.

Ek olarak dedigim gibi gelistiricileri guvenli kodlamaya zorlamak icin
onlara koda giren ilk haline erisimi de kisitlamak gerekiyor bence. Bir de
eger filtreyi basa alirsaniz bu sefer gelistiriciler buradaki ornekte oldugu
gibi gelen parametreleri ya da kod icerisindeki datayi guvenli kabul edip
cesitli yerlerde tekrar kullaniyorlar, bu da malum input injectionlara neden
oluyor ya da second order injectionlara.

Tabii ki bu basta yapilmamali anlamina gelmiyor ama genelde bu pratik kotu
sonlaniyor, bu da tabii ki gene gelistiricinin hatasi.

On 25/05/07, Burak DAYIOGLU <burak.dayioglu at pro-g.com.tr> wrote:
>
> On Thu, 2007-05-24 at 22:49 +0100, Ferruh Mavituna wrote:
> > Eger girdiyi ilk noktada kurala uygularsaniz bu sorun cikartacaktir,
> > deneyimle ve piyasadaki yazilimlarin aciklari ile sabit bir gercek
> > oldugunu dusunuyorum. Cunku en ciddi sorun dedigim gibi "gizli
> > katmanlar" maalesef kod duz ilerlemiyor dolayisiyla eger bir login
> > fonksiyon gelen parametre filter etmeden direk SQL e veriyorsa bence o
> > hatali bir yapidir.
>
> Merhaba,
> Ben girdi denetiminin ilk noktada UYGULANMAMASINA iliskin onerinizi
> paylasmiyorum. Girdinin uygulamanin sinirinda iceri alinir alinmaz
> kontrol edilmesi gerektigini, pozitif kontrol listeleri ile elden
> gecirilmesini savunuyorum. Eger girdinin "beklenen" tarifini yapar ve
> buna uygunlugu sinarsaniz icerilerde kodun duz ilerlememesi diye tarif
> ettiginiz durum da bir problem olusturmaz.
>
> > Mesela programlamada bilinen bir pratik vardir. "Self Defense" her
> > fonksiyon kendi icinde kendini sakat datadan korur (Code Complete
> > kitabinda detaylari var bu konunun). Tabii ki guvenlikte durum biraz
> > farkli cunku ayni filtre iki defa uygulandiginda program acisindan ya
> > da guvenlik acisindan sorun cikabilir, o yuzden sadece son noktada
> > gerekli yerde kontrolun yapilmasini ben her zaman daha faydali
> > buldum.
>
> Az onceki paragrafta yazdiklarimla birlikte, "Self Defense" ile ilgili
> yorumunuza da katiliyorum. Bir kodun tum bilesenleri (metodlar,
> fonksiyonlar vb.) kendi girdilerini sinamak ve uygunluklarindan emin
> olmak durumundadir; bunun iki ya da daha cok uygulanmasindan
> kaynaklanabilecek problem olsa olsa performans problemi olurdu ki modern
> bir BT ortaminda sorun olacagini hic sanmam. Metod/fonksiyon
> girislerindeki girdi denetimlerinin de yine pozitif kontrol listeleri
> ile olmasini saglamaliyiz.
>
> Onerim (ve Pro-G'nin PGE-411 kursunda anlattigimiz yontem) savunma
> derinligi olusturmak uzere
>
> (i) uygulamaya dis kaynaklardan girdilerin ilk alindiklari noktada
> pozitif kontrol listeleri ile sinanmalari
>
> (ii) kod icerisindeki tum metod ya da fonksiyonlarin kendi girdilerini
> de "dis kaynaklardan geliyormuscasina" pozitif kontrol listeleri ile
> sinamalari
>
> (iii) Verinin islendigi yerde de (veritabani vb.) olabilecek kisitlama
> (containment) ozelliklerinden faydalanarak mumkunse olasi uygunsuz
> girdilerin etkilerini azaltiyor olmak (stored-procedure, prepared query
> gibi)
>
> yontemlerini bir arada kullaniyor olmaktir.
>
> selamlar, iyi calismalar.
> --
> Burak DAYIOGLU, Genel Koordinator
> Pro-G Bilisim Guvenligi ve Arastirma Ltd.
> T:+90 312 4733512   W:http://www.pro-g.com.tr
> *****    Guvenliginiz Geleceginizdir    *****
>
> Blog: http://www.burakdayioglu.net
>
>


-- 
Ferruh Mavituna
http://ferruh.mavituna.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owasp.org/pipermail/owasp-turkey/attachments/20070525/8c5e9ea5/attachment.html 


More information about the Owasp-turkey mailing list