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

Ferruh Mavituna ferruh at mavituna.com
Thu May 24 17:49:51 EDT 2007


Class su sekilde calisiyordu,

Once tum degerleri aliyor bir array ye yerlestiriyor. Aynen dediginiz gibi
GET ve POST iceriklerini bosaltiyor.

Ondan sonra class icerisinde bir suru kural var. Ana kurallar numerik, SQL,
Range Kontrolu, Uzunluk kontrolu vs.gibi ust kontroller ise web sitesinin
objeleri mesela kullanici adi. Eger herhangi bir sekiklde herhangi bir zaman
kullanici adi kullanici adinin olmasi gerektigi gibi degilse direk sistem
orada onu dusuruyor ve kullanici adini disari vermiyor.

Buradan da anlasildigi gibi sistem sadece GET POST vs. ile de degil ozel
girdi ile de desteklenebiliyor. Bu sayede second order ataklarda
engelleniyor.

Dolayisiyla gelistirici herseye tamamen burada erisiyor ve herhangi bir
sekilde bir SQL parametresi veya HTML ciktisi olacaksa once burada
kontrollerden geciyor ondan sonra giriyor.

Biz bunu dedigim gib cok buuyuk bir sistemde uyguladik, hic bir sorun
cikmadi. Class i yazmak ve ayni zamanda gelistiricilerin de zevkle
kullanabilecegi hale getirmek biraz zaman aldi. Onun harici tum projeye
entegre ettik 150+ dinamik sayfalik bir isti sanirim. Sonuc olara biz verim
alip memnun kaldik :)

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.

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.

Tabii ki yanlis dusunuyor olabilirim.

On 24/05/07, Bunyamin DEMIR <bunyamindemir at gmail.com> wrote:
>
> Bukadar güvenlik adama zarar verir diye düşünüyorum. Teoride
> uygulanabilinir gözüksede ben bunun pratiğe geçirileceği kanısında değilim.
> En azından piyasa koşullarında yazılımın güvenli olmasından ziyade erken
> hayata geçmesi önemli oluyor çoğu zaman.
>
> Hem şöyle bir senerya düşünelim? Eğer kredi kartı numarası geçerli bir
> kart numarası değil se niye oraya kadar devam ediyor? Bu ekstra yük ve zaman
> masrafına sebep olmaz mı?
>
> Ben güvenlik kontrollerinin mümkün olduğu en erken zamanda yapılmasından
> yanayım. Çok kopleks ve çok basit te olmamalı. Burada aslında "Kararlı"
> kelimesinin kullanmak istiyorum. Çünkü güvenliğin bazı götürüleri
> olacağından bunu mümkün olduğunca dengeli yapmak gerekir.
>
> Ferruh hocam şu class`ı az daha açarmısın? Merak ettim:)
>
>
> Ayrıca güvenlik kontrollerinde sizin izlediğiniz aşamalar nasıl? Varmı bu
> konuda acı ve tatlı tecrübeleri olanlar?
>
>
>
> 24.05.2007 tarihinde Bedirhan Urgun <urgunb at hotmail.com> yazmış:
> >
> >
> >  Tabi detayli olarak gormeden bisey demek cok mantikli degil ama sanki
> > implement ettiginiz ana obje (class), choke point (girdi bogumu) gibi geldi
> > bana. Hicbir girdi burdan gecmeden uygulamaya girmiyor (kullanilmiyor).
> > Bunun icin de _GET ve _POST degiskenlerine ulasimi engellemissiniz sanirim.
> > Gelistirici direk eristigi zaman kod icinde bu durumlar acikca goruluyor ve
> > potansiyel olarak guvensiz durumlar (tainted variables gibi yani) oluyor.
> >
> >  Okudugum bi makalede soyle bi ana fikir vardi: pozitif girdi kontrolunu
> > (sunucu tarafinda) kullaniciya en yakin yerde yapin ama uygulamanin icinde
> > yeri geldiginde mantiksal girdi denetimleri de uygulayin. Mesela kredi karti
> > numarasini uygulama girisinde kontrol edin (sadece rakamlardan olusacak),
> > ama bu kredi karti bilgisini business object'lerde kullanacaginiz zaman,
> > kredi karti numarasi algoritmalarini uzerinde uygulayin (mantiksal olarak bu
> > gercekten kredi karti numarasi mi).
> >
> >  Soylemesi kolay. Her orta capta program yazan, bunlari uygulanmanin ne
> > kadar zor geldigini cok iyi bilir. Burda da guvenlik kutuphaneler yardima
> > yetisebilir.
> >
> >
> > ------------------------------
> > Date: Thu, 24 May 2007 14:29:09 +0100
> > From: ferruh at mavituna.com
> > To: urgunb at hotmail.com
> > Subject: Re: [Owasp-turkey] [Fwd: [netsec] WordPress Kritik Guvenlik
> > Acigi]
> > CC: huzeyfe at lifeoverip.net; owasp-turkey at lists.owasp.org
> >
> > Bence giris noktasi kontrolleri cok verimli degil. 1-2 sene kadar 10
> > kisilik falan bir ekibin calistigi bir web uygulamasinda (PHP) guvenli
> > kutuphaneler gelistirdik. Bu gelistirmede su sekilde bir yontem uyguladik ve
> > bayagi da verim aldik.
> >
> > Herseyden ote direk GET ve POST vs. her turlu erisimleri gelistiriciye
> > kapadik. Dolayisiyla kod yazarlarken isteseler de bu verilere direk
> > ulasamiyorlardi.
> >
> > Ikinci olarakta bu verilere erisimi ana obje altinda tek bir class tan
> > yaptik, eger sayfa HTML e cikti gidecekse HTMLSafe gibi bir isimli property
> > den koyuyorlar, eger SQL e gidecekse bunu da SQLsafe gibi bir property den.
> > Ek olarak girdinin ozune de de bazen erismek gerekiyor onu da ek olarak
> > koyduk erisime ama bu erisim cok basit sekilde yazilimda gozlenebiliyordu,
> > dolayisiyla potansiyel olarak guvensiz olan yerler anlasiliyor.
> >
> > Maalasef PHP de strong type olmamasindan dolayi bazi limitleri
> > implemente etmedik. Mesela aynisi .NET te cok daha verimli sekilde
> > yapilabilir.
> >
> > Aslinda dumur noktasi su, bu adamlar niye parameterized SQL ler
> > kullanmiyorlar ?
> >
> > Ikincisi basit bir sekilde kontrollerin son noktada yapilmasi katman
> > karmasasindan dogan buradaki gibi sorunlari da cozuyor. Katmandan kastim
> > kodun geldigi yeri bilmemek. Genelde web uygulamalarinda olan bir sey. WP
> > deki Bir onceki SQL Injeciton acigi da bu sekilde cache sistemindeydi ( http://www.notsosecure.com/folder2/2007/04/03/wordpress-212-xmlrpc-security-issues/
> > ).
> >
> > Eger acigi kaynak koddan takip ederseniz yaklasik 4 ten fazla
> > fonksiyondan geciyor ve neredeyse pasif olarak cacheleme ile ilgili bir
> > yerde SQL Injection olusuyor. Muhtemel bir skaynak kod analizinde bile
> > gozden kacabilecek bir sey.
> >
> >
> >
> >
> >  On 24/05/07, *Bedirhan Urgun* <urgunb at hotmail.com> wrote:
> >
> >
> >  Girdi denetimini stratejilerinde denetimi sunucuda nerde yapmak gerekir
> > diye bi konu var. trust boundary, choke point meseleleri.
> >
> >  Acigin kaynak koduna baktim tam egitimlik (hatta tartismalik)...
> >
> > ******************
> > function check_ajax_referer() {
> > $cookie = explode('; ', urldecode(empty($_POST['cookie']) ?  <<------
> > $_GET['cookie'] : $_POST['cookie'])); // AJAX scripts must pass
> > cookie=document.cookie
> > foreach ( $cookie as $tasty ) {
> > if ( false !== strpos($tasty, USER_COOKIE) )
> > $user = substr(strstr($tasty, '='), 1);
> > if ( false !== strpos($tasty, PASS_COOKIE) )
> > $pass = substr(strstr($tasty, '='), 1);
> > }
> > if ( !wp_login( $user, $pass, true ) )
> > die('-1');
> > *******************
> >
> > simdi genel bir strateji olarak girdi denetimini soyle
> > yapilabilir; Girdi uygulamaya ulastigi en yakin noktada (choke point), daha
> > ileri gitmeden. Ama yukaridaki durum boyle bir denetimi by-pass edebilir.
> > Mesela double url encoded stringler (sunucu tarafindan uygulamaya gelmeden
> > bir kere decode edilmislerdi) pozitif denetim fonksiyonlarimizi
> > atlatabilirler (tam yukaridaki durum, yani regular expressionimizda %
> > karakterine izin veriliyorsa varsa tamam).
> >
> > Cok gelistiricili bir projede choke point falan yetmeyebiliyor demek ki.
> > Daha kademeli bir anlayis lazim. Gelistiriciye "(giris noktasinda) girdi
> > denetimi yap" dedikten sonra uygulamasinda boyle bi hata bulmak umutsuzluga
> > dusurebilir.
> >
> >  bedirhan
> >
> >
> >
> >
> >
> > ------------------------------
> > Date: Thu, 24 May 2007 09:49:57 +0100
> > From: ferruh at mavituna.com
> > To: huzeyfe at lifeoverip.net
> > CC: owasp-turkey at lists.owasp.org
> > Subject: Re: [Owasp-turkey] [Fwd: [netsec] WordPress Kritik Guvenlik
> > Acigi]
> >
> > Biz de iki gun once test ettik, acik ilk yayinlandiginda. Gayet guzel
> > bir sekilde calistigini onayliyabilirim.
> >
> > Ek olarak her daim WP kulanicilarinin admin kisimlarina en azindan
> > ekstra bir Basic Auth eklemesini oneriyorum. Ek olarak  patch i  uygulayana
> > kadar bu sekilde hizli ilk onlemi de almis olabilirsiniz.
> >
> > On 24/05/07, *Huzeyfe ONAL* <huzeyfe at lifeoverip.net> wrote:
> >
> >
> >
> > ---------------------------- Original Message
> > ----------------------------
> > Subject: [netsec] WordPress Kritik Guvenlik Acigi
> > From: "Huzeyfe ONAL" < huzeyfe at lifeoverip.net>
> > Date: Thu, May 24, 2007 10:29 am
> > To: netsec at huzeyfe.net
> > --------------------------------------------------------------------------
> >
> >
> >
> >
> > WordPress 2.1.3 kullanicilarinin
> > dikkatine...
> >
> > Bir iki gundur bloguma gelen web isteklerindeki
> > anormallikleri incelerken iki gun oncesine ait bir WP aciginin
> > kullanildigini kesfettim.
> >
> > wp-admin/admin-ajax.php ve buna bagli olan
> > scriptlerdeki eksik kontroller yuzunden blogunuzun /wp-admin kismina
> > erisebilen kotu niyetli birisi sistemdeki wp kullanicilarina ait
> > plain md5 ciktilarini alabilir(kendi sistemimde test ettim) ve
> > otesinde bunu kullanarak sisteme admin yetkileri ile
> > baglanilabiliyor(mus)-test etmedim.
> >
> > Cesitli undergorund
> > sitelerde konu ile ilgili exploitler yayinlanmis durumda.
> >
> > Aciktan korunma icin WP tarafindan cikarilan guncellemeler ( 2.2)
> > gecilebilir
> >
> > Detayli Bilgi :
> > http://secunia.com/advisories/25345/
> >
> >
> >
> > --
> > Huzeyfe ONAL
> > huzeyfe at lifeoverIP.net
> > http://www.lifeoverip.net
> >
> > Ag guvenligi listesine uye oldunuz
> > mu?
> > http://netsec.huzeyfe.net
> >
> >
> > _______________________________________________
> > Owasp-turkey mailing list
> > Owasp-turkey at lists.owasp.org
> > https://lists.owasp.org/mailman/listinfo/owasp-turkey
> >
> >
> >
> >
> >
> > --
> > Ferruh Mavituna
> > http://ferruh.mavituna.com
> >
> >
> > ------------------------------
> > Create the ultimate e-mail address book. Import your contacts to Windows
> > Live Hotmail. Try it!<http://www.windowslive-hotmail.com/learnmore/managemail2.html?locale=en-us&ocid=RMT_TAGLM_HMWL_reten_impcont_0507>
> >
> >
> >
> >
> > --
> > Ferruh Mavituna
> > http://ferruh.mavituna.com
> >
> >
> > ------------------------------
> > Change is good. See what's different about Windows Live Hotmail. Check
> > it out!<http://www.windowslive-hotmail.com/learnmore/default.html?locale=en-us&ocid=RMT_TAGLM_HMWL_reten_changegood_0507%0A%0A>
> >
> > _______________________________________________
> > Owasp-turkey mailing list
> > Owasp-turkey at lists.owasp.org
> > https://lists.owasp.org/mailman/listinfo/owasp-turkey
> >
> >
>
>
> --
> Bunyamin Demir
> OWASP-Turkey Chair
> http://www.webguvenligi.org
>



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


More information about the Owasp-turkey mailing list