[darius]

buyuk umutlarla gectigim sadecehosting'den de husranla ayriliyorum.

sitelerinin her yerinde "cgi klasoru" "perl-cgi destegi" yazmasina ragmen meger bunu kaldirmislar, sayfalarini da -henuz- guncellememisler. bu cok saygi duydugum bir sirketti ama cok uzuldum acikcasi. 3 tane dosyayi degistirmek bu kadar mi zor, hesabi alip, siteleri tasiyip zilyon tane is yaptiktan sonra "cgi'i kapattik biz" deyip gerisingeri gondertiyorlar. parayi iade etmeyi onerdiler ama soyledigim gibi ikide bir tasinmak cok ugrasli oluyor.

neyse, bahsetmek istedigim asil bu degildi. sadecehosting, perl/cgi destegini, %90 guvenlik acigina neden oldugu (bunu da hic anlamadim, ne zamandan beri guvenligin yuzdesi oluyor) icin, musterilerden de pek isteyen olmadigi icin kapatmis. sorunun cozumu varmis da asiri cpu kullanimi vs. oldugu icin tercih etmemisler.

sorum, eger boyle bir guvenlik acigi varsa, neden yer gok inlemedi, nasil hala diger sirketler perl/cgi hizmeti vermeye devam edebiliyor?

perl deyince de "aman dinazora bak" demeyin, movable type kullanacakim sunun surasinda

izhost'taydim bundan once, ne yazik ki destek icin kullandiklari inanilmaz hantal arabirimden, guvenlik konusunda fazla paranoyak olmalarindan (2 senedir kullanmama ragmen verdikleri kullanici adi ve sifreyi ezberleyemedim, degistirmek de "guvenlik nedeni" ile mumkun degil), ve teknik elemanlarinin turkce cumle kurmayi basaramamalarindan (inanilmaz ornekler var elimde, anlamak icin buyuk caba gostermek gerekiyor) artik gina geldi ve degistirmek icin boyle bir girisimde bulunuyorum.

beni karegen mi paklar sizce? onlara da bir senenin parasini pesin vermeye korkuyorum, aksaklik cikarsa ve iade etmekte istekli bulunmazlarsa bitti-gitti olacak.

[soul]

perl aciktir vs. diye bir sey yoktur bu arkadaslar adam gibi konfigüre edememsilerdir, o zaman da zart acik olusturur der cikarlar, ayni bazilarinin tüm windows sistemlerinin yada ASP nin acik oldugunu düsündüğü gibi. Kaale alınmaması gerekir diye düşünüyorum.

Karegen konusunda forumda çok mevzu geçti benim anladığım bir kaç güvenlik sorunu harici iyilermiş. forumda ek olarak geniş bir hosting konusu geçmişti incelenebilir.

[roots]

re: darius,

perl'ü geçtim cgi-bin işlemi apache üzerinde default ayar ve kurulumları ile %90 değil %100 güvenlik açığıdır. nasıl mı? açıp biraz gözatarsanız crossover scripting diye zibilyon tane açıklama ve mesaj bulacaksınızdır. çözümü yok mu? kesinlikle var, suexec algoritmasından tutunda ekstra cgid çalıştırmaya kadar 10 küsür tekniği var fakat sol kulağı sağ el ile göstermek yerine sol kulağı kullanmama durumu şuandaki olay, çünki size gelen seslerin 1500 tanesi sağ kulaktan geliyorsa ve sol kulağın olduğu yerden 2 ses geliyosa inanın sol kulağınızı kullanmamayı bırakırsınız... oradaki hata şu, sipariş sayfalarının 1 kısmında cgi-perl ibaresi kalmış durumda bu sadecehosting'in hatasıdır, sanırım onuda telafi ederler işlemi iptal ederek yada alternatif sunarak vs...

re: soul

cgi-bin bal gibi açıktır oturup 1 script çalıştırmak için sistemin yarısını sömüren ve üstüne üstlük 1500 müşteride sadece 2 müşteri tarafından istenen bir hizmeti satmamak ticari açıdan daha mantıklı ve doğru bir karardır...

olayı görmek istediğimiz kısımları ile görerek fikir yürütürsek bu hem yapıcı olmaz hemde bencilce bir tavır olur.

ve not, perl yada cgi-bin içerikli özellikle interpretter uygulamalar varolan PHP yada ASP gibi modül yapılı uygulamalardan daha fazla performans harcamaktadır. kaldı ki PHP sonrasında perl'in uygulama ve kullanım özellikleri ne konumda olduğu ap ayrı bir tartışma konusudur...

[biturbo]

cgi kesinlikle çok sakat
+1

[soul]

cgi-bin hizmeti vermemek ayrı bir şey zgi-bin açıktır demek ayrı birşeydir. Cgi-bin diye bir şey varsa ve dev gibi firmalar bunu kullanıyortsa bu açık bir şey değildir, o zaman hadi
şu Results 1 - 10 of about 36,400,000 for inurl:cgi-bin. (0.37 seconds)

36 milyonu bir zahmet hackleyelim, çünkü bunlar açık.

bkz : Paypal
Zaten Paypal de güvenli bir site değil, bal gibi açık hadi hemen onu da hackleyelim.

@roots
Sanırım foruma buradaki bahsi geçen hosting sahibi olarak yazıyorsun, 6. mesaj

@biturbo sende çok açıklayıcı bir mesaj göndermişsin.

[soul]

Ya bu muhabbetlere girmek istemiyorum ama hakikaten tarzın hoş değil, ona "crossover scripting" denmez "cross site scripting" denir. XSS veya CSS olarak geçer.

[roots]

firma yetkilisi olarak değil, cgi-bin ile virtual hosting yapıldığında sorun yaşanabileceğini savunan biri olarak yazıyorum.

en kestirme anlatımınıda istersen;
1- cgi destekli bir hosting satın al
2- bir alt dizini okuyabileceğin çok basit 2-3 satırlık bir cgi script upload et
3- webden erişerek çalıştır.

ne görüyorsun? muhtemelen web sunucunun read hakkı bulunan herşeyi... eğer read hakkın yoksa kör denemelerlede bulunan diğer dizinlerdeki dosyaları read edebilirsin... örnek /www/xxx.com/cgi-bin/a.cgi senin dosyan ise sen bununla /www/yyy.com/config.PHP yi read edebilirsin... iis üzerindeki meşhur fso açığı gibi... eğer bu yeterince açık anlatım değil ise daha detayınıda anlatabilirim.

koruma yolları elbette var en kestirmesi suexec mekanizması ki ondada perl ile ilgili bazı modül ve lib desteklerinde sorun yaşıyorsunuz... vs vs...

bu yüzden eğer bir firma "güvenlik VE performans nedenleri ile sunmuyoruz" dediğinde "ayarlamayı becerememişlerdir" demek uygunsuz oluyor.

muhabbtelere girmiyoruz, biri bir tecrübesini belirtmiş bizde fikirlerimizi...

ve cross site değil crossover olarak arat...

[BRONZE]

ne görüyorsun? muhtemelen web sunucunun read hakkı bulunan herşeyi... eğer read hakkın yoksa kör denemelerlede bulunan diğer dizinlerdeki dosyaları read edebilirsin...

bahsettiğiniz bu mevzu sadece cgi-bin dizinine ait bir açık mı? PHP kullanarak da erişim hakkı bulunan dosyaları görüntüleyebilirsiniz, bir shared hosting'ten bahsediyorsak aynı sunucudaki başka dosyaları da okuyabilir hatta ufak bir backup tool ile dosyaları çekebilirsiniz. O zaman server side tüm diller açık oluşturuyor diyelim, sadece HTML kullanalım.(?)

[roots]

kesinlikle haklısın...

sırf bu yüzden PHP için özel kontrol fonsiyonları bulunmaktadır. SAFE_MODE denilen bir mod ile ilgili virtual host'u bir dizine hapsederek değil diğer dizinlere read hakkı dilerseniz kendi dosyaları üzerinde de işlemler konusunda kısıtlamalar koyabiliyorsunuz... execution işlemlerinden tutunda istemediğiniz fonksiyonların çalıştırılmasına ait izinlere kadar pek çok kontrolde PHP mantıklı çözümler sunmaktadır...

cgi üzerinde malesef bu derece detaylı kontrol bulunamamaktadır. Özel bir sürü daemon filan var fakat onlarda sol kulağı sağ ayakla göstermekten farksız oluyor... özelliklede 5-10$ a shared-hosting sağlayan şirketler için...

bu arada windows üzerinde bu işlem için fanatik derecede unix taraftarı olsamda daha mantıklı bir güvenlik yapısı bulunduğunu kabul etmem gerekiyor. apache 2 ile benzer bir güvenlik seviyesi gelmekte fakat henüz %100 oturmadığı için temiz bir çözüm sunmak zor... eğer cidden mantıklı bir gelişme olursa ilk ben uygulamaya koyarım

[fatihunal]

soul tarafından gönderilen mesaj:

perl aciktir vs. diye bir sey yoktur bu arkadaslar adam gibi konfigüre edememsilerdir, o zaman da zart acik olusturur der cikarlar, ayni bazilarinin tüm windows sistemlerinin yada ASP nin acik oldugunu düsündüğü gibi. Kaale alınmaması gerekir diye düşünüyorum.

@soul haklı ...

Her programlama dilinin, her sunucunun kendine göre açığı vardır.
ASP 'de açık çok derler, evet çok. Ama kapatmanız mümkün, anında hem de. PHP'de, CGI 'da açık yok mu, elbetteki var ....
Böyle işin içinden çıkılmaz ki...

Açık olması ya da olmaması sunucuyu kuran ya da scripti, programı vs. yazan kişinin becerisine, tecrübesine, bilgisine kalmıştır. En güzeli açıkları zaman içinde bulup birer birer kapatmak, ya da kapattırmak.
Hatasız kul olmaz. %100'lük sunucu da olmaz.
En iyisi "on error resume next" .
Oh be içimi döktüm.