XSS ölüyor mu?

0
Yns_
Yns_
15 Ağustos 2006 , 1 dakika okuma süresi
PHP 5.2 ile beraber PHP'de setcookie() fonksiyonuna 7.parametre olarak httponly desteği gelmiş.

Httponly çerezlere Javascript ile ulaşılamadığı için xss ataklarının en tehlikelisi olan cookie çalma olayı ortadan kalkıyor.

Şu an tek sorun her tarayıcı tarafından desteklenmemesi, ama yakında bir çok tarayıcı yeni sürümünde bu standartlara uyacaktır tahminimce.IE 7 ile en güvenli şekilde bu özelliği destekliyor, fakat mozilla şaşırtıcı bir şekilde desteklemiyor.
Destekleyen tarayıcılar:
* IE 6.0 SP1 and later - prevents reading, but not over-writing (still allows preset CSRF attacks)
* IE 7.0 - prevents reading and writing - safest
* Safari 1.3 and later - prevents reading
* Opera 8 and later - prevents reading
* Mozilla - not supported
* Firefox - not supported
* IE 5.x for Mac - will actually fail to render the page. Use browser detection to encourage them to migrate to Safari or Firefox once it supports HttpOnly

Bu adreste mozilla tabanlı tarayıcılar için potansiyel çözümler var.

Konu ile ilgili kaynaklar: #1 , #2
Güvenlik
13
Linkedin Facebook Twitter Google plus

Görüşler

belfagor
0
belfagor
Mozillanın desteklememesi tuhaf. Mic bile desteklerken Mozillanın böyle yapması....

Ama eminimki yeni sürümlerde bu desteği görücez.
yilmaz
0
yilmaz
XSS açığı benim doğru dürüst kod yazamamamdan kaynaklanan bir durum değil mi? Bunu artık tarayıcı kodlayan kişiler mi düşünmek zorunda artık?
arsenelupin
0
arsenelupin
Herkes birlikte düşünmek zounda.

Sonuçta kodu yazan kim olursa olsun insan ve dolayısıyla "insani hatalar" her zaman söz konusu olabilir. Elbette gerekli önlemleri alarak xss ve diğer sıkça görülen açıkların üstesinden doğrudan php katmanında gelinebilir, öte taraftan, insani hatalara karşı birden fazla güvenlik katmanının bulunması her zaman tercih edilen bir durum olmalı gibime geliyor.

Yine de itiraz edilecekse, kanımca birden fazla güvenlik katmanı bulunmasının, kod yazan kişiyi zihinsel tembelliğe itmesi ve kişinin "nasıl olsa tarayıcıya takılır" düşüncesiyle yazdığı koda gereken özeni göstermemesi noktasında itiraz edilebilir.
Yns_
0
Yns_
Xss her zaman kod yazarı ile alakalı bir durum olmuyor, tarayıcıların yorumlama farkları yüzünden xss zayıflıkları ortaya çıkabiliyor.Örneğin aşağıdaki kodu IE javascipt olarak çalıştırıyor.

<IMG STYLE="xss:expr/*XSS*/ession(alert('XSS'))">

Projeniz öyle bir proje ki, bazı html etiketlerine izin veriyorsunuz.İçinde IMG'de var..Şimdi elinizde böyle bir veri var, ve buna benzer milyonlarca yorumlama farkından doğan zayıflık olabilir.

Javascript ile ulaşamayacak bir cookie göndermek varken, yukardaki yorumlama farkları için standart değerleri aldıktan sonra beyaz liste oluşturup mu kontrol ederdiniz?
(Biz ikincisini yaptık, yüzlerce satır ekstradan kod yazmak durumunda kalıyorsunuz.)

Şahsen ben tarayıcıları yeterince düşündüm, birazda onlar bizi düşünsün.
anonim
0
anonim
Beyaz liste ve karaliste zaten kullanılması gereken önlemler bana kalırsa.
Diğer taraftan bu tip durumlar için daha kesin çözüm mod_security gibi web uygulamaları için geliştirilmiş ids leri kullanmaktır bence. 2 satırlık bir kuralla hemen hemen bütün XSS saldırılarının önünü kesersiniz.
Yns_
0
Yns_
IE'nin yorumlama farkı olmasa yukarıda bahsettiğim problem karaliste yöntemi ile kolayca çözülebiliyor.

Ama bu konuda iş beyaz liste oluşturmaya gelince elinizde milyonlarca html attribute bulunan bir array'la uğraşmak zorunda kalıyorsunuz..
anonim
0
anonim
Evet beyaz liste biraz zahmetli ama IE olmasa bile dahi güvenlik açısından beyaz liste tercih edilmeli bana kalırsa.

Diğer taraftan baştada söylediğim gibi mod_securty benzeri uygulamalarla sorunu çözmek mümkün ama yalnızca mod_security veya yalnızca dispatcher kullanarak güvenliği tek katmana indirgemiş oluyorsunuz. Tabi bu da aslında risk ve kaynak yönetimi ile ilgili bir konu biraz da...
selam
0
selam
Unutulmamalıdır ki her kod yazan kişinin elinde istediği gibi yönlendirebileceği bir sunucu yada sistem yöneticisi yok. Kaldı ki "yaşasın artık Javascript ile Cookie'lerimi çalamayacaklar" diye form yada benzeri yerlerden gelen veri alanlarını kontrol etmeyi bırakmamalıyız. Hala dünyada eski sürüm tarayıcı kullanan insanlar olacaktır. Bu liste kullanımı uzun bir süre daha devam edecektir hatta etmelidir.
gCg
0
gCg
tarayıcı destekleri bir yana sunucu desteği biraz daha kaygılandırıyor beni. linux sunucuların büyük bir yüzdesinde kullanılan cpanel henüz php4 olduğu için hala sunucuların bir çoğu php4 destekliyor.

php5'e geçiş için daha zaman var gibi gelmekte.
PHP-HuNTeR
0
PHP-HuNTeR
ewet php5 için zaman var gibi gözküyor çünkü Host firmalarının işine gelmiyor o kdr forumu host ederken, php sürümünü değiştirince ortaya çıkan sorunlarla uğraşmak
wookiert-
0
wookiert-
Bu baslik XSS'i cookie calmaktan ibaret sananlarin dustugu bir yanilgidan ortaya cikmis olsa gerek. Bunun disinda, insanlarin javascript konusunda obsesif olmasini ilginc buldugumu ekleyeyim. Tarayicilarda calistirilabilen kod javascriptle kisitli degil. XSS icin Flash objeleri, Java vs. bir cok seyi kullanmak mumkun.

XSS in bence asil tehlikeli oldugu yer stored xss dedigimiz kisim. Kullaniciya sunulan cikti htmlencode edilmedigi surece de bu sorun kolay kolay cozumlenebilecek gibi gozukmuyor.
Yns_
0
Yns_
Insanlar neden okumaktan acizler...
anonim
0
anonim
Pardon, bir sey mi kacirdim? Daha net olabilir misiniz?
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Internet´in En Kara Günü!
sundance
8 Temmuz 2003, 1 dakika okuma süresi

6 Temmuz 2003 muhtemelen Internet'in en kara günlerinden biri olarak tarihe geçecek! Zira bugün, www.defacers-challenge.com, dünya çapında sistem kırıcıları 6,000'e yakın siteyi en kısa sürede kırmaya davet etti.

Eğer medya her zamanki gibi bu habere atlamasaydı, sonuç bu kadar feci olmayabilirdi. Bir delinin kuyuya attığı taş pekala da orada kalabilirdi.

Yarışmayı boykot edip, hakem site zone-h.org'a saldıranlar mı dersiniz, yoksa ünlü olma adına kırdıkları sitelerden haber veren yarışmacılar mı (ikisi de zone-h'a denial-of-service yapmış tamamen zıt sebeplerle :)) Kırılan sitlerin listesi haberde, özellikle Sapık Ferit tarafından re-hack edilmiş pcoyun.net'e dikkat :)))

ATM şifreleme anahtarı kırmak!
conan
9 Kasım 2001, 1 dakika okuma süresi

Bu sayfada yazanlara göre IBM 4758 cryptographic co-processor'unden 3DES anahtarını "çalmayı" başarmışlar.

IBM 4758, bankalar tarafından sıklıkla kullanılan bir şifreleme chipiymiş ve IBM'in ATM'lerinde de sıkça kullanılmaktaymış. Bu crack'i gerçekleştirenler, 20 dakika makinaya kesintisiz ulaşımı ve Combine_Key_Parts kullanım yetkisi olan birinin, 995$'lik bir aletle (FPGA evaluation board from Altera) 2 gün içerisinde bu şifreyi ele geçirebilecegini iddia ediyorlar. (nasıl yapılacağını da bilmesi gerektiğini söylemeyi unuttum sanırım) ;)

Kontörleriniz Nereye Gitti ? (Turkcell Açığı Kabul Etti ! )
anonim
20 Mart 2003, 1 dakika okuma süresi

Geçtiğimiz günlerde Turkcell'in Mobilaktif.com adresli sitesi üzerindeki bir açıkla istenilen Turkcell abonesinden kontör silinmesine dair haberlere, siteden açığı kabul eden bir açıklama geldi: http://www.mobilaktif.com/popup.php?sp=haberler

Router Tasarlarken Dikkatli Olmak Lazım! ;-)
FZ
18 Eylül 2003, 1 dakika okuma süresi

2003 yılının Mayıs ayında `University of Wisconsin - Madison´ ağ yöneticileri kampüsteki kamuya açık NTP (Network Time Protocol) zaman sunucusu bilgisayarın kaldıramayacağı kadar yoğun bir trafiğe maruz kaldığını saptadılar. Başlangıçta saniyede yüzbinlerce paketten oluşan bu trafiği DDoS (Distributed Denial of Service) saldırısı olarak algılayan ağ yöneticileri durumu inceleyince bunun böyle olmadığını gördüler.

Problemin pek çok organizasyonda bolca bulunan ucuz ve küçük bir router cihazdaki gömülü koddan kaynaklandığı tespit edildi ve üretici firma ile temas kurma çabaları başladı... Bu süreci çok güzel ve detaylı bir şekilde yansıtan teknik raporu tüm ilgililerin okumasında fayda var. Söz konusu süreç aynı zamanda üniversite sanayi işbirliğine dair güzel bir örnek.

Büyük SSL Göçü Başlıyor mu?
tongucyumruk
22 Kasım 2017, 1 dakika okuma süresi

Google CA/Browser Forum gereksinimlerini yerine getirmemesi sebebiyle Symantec PKI altyapısını güvenilen sertifikalar listesinden çıkarmaya karar verdi. Bu durum SSL dünyasında bolca kullanılan Thawte, VeriSign, Equifax, GeoTrust, ve RapidSSL gibi Symantec'e bağlı SSL sağlayıcıları tarafından üretilen sertifikaların geçerliliğini yitirmesi anlamına geliyor.

Google Güvenlik blogunda yapilan...