• isim ve gorevim sebebiyle surekli olarak ugrasmam gereken bir saldiri turu. acikcasi "xss yeni buffer overflowdur" diyenlere bircok yonden katilirim zira son 4-5 sene icinde bulunan saldirilar arasinda en yenilikci, uzerinde en cok konusulan ve de kesinlikle en fazla karsilasilan tur saldiridir xss.
    bunun yaninda bir urunde xss bulmak, buffer overflow bulmaktan nispeten daha kolaydir. exploit yazmak cok daha kolaydir. yamalamak da yine cok daha zahmetsizdir. yine de bunlar guvenlik acigi oldugu ve birilerine zarar verecegi gercegini degistirmez.

    bunlarin yaninda, asla ama asla bir buffer overflowun zerafetine, imkan sagladigi evrimsel seleksiyon gucune, ve etki potansiyeline ulasamayacaktir. yine de ozellikle web application framework gelistiren biriyseniz rahatsiz edici, dikkate alinmasi gereken bir risktir ...
  • geçenlerde siber güvenlik uzmanı başlığına yazınca gördüm ki aslında xss hala daha yeterince ciddiye alınmıyor. ortalık da çoğunlukla bilgisayardan biraz anladığını düşünen siber güvenlik uzmanları (şarlatanları) dolandığı için işin tarihsel bir miktar da yazilimsal tarafından bahsedeceğim. ne de olsa ekşi sözlük 2010ların başına kadar xss açığıyla az uğraşmadı. google 4 yıl öncesine kadar arama kutusundan xss saldırısına maruz kalabiliyordu.

    web güvenliği alanında sıkça karşımıza çıkan terimlerden biri de cross-site scripting, yani xss'dir. bu terim pek çok kişi için kafa karıştırıcı olabiliyor. nitekim ben de bu terimle ilk karşılaştığımda pek anlamamıştım ama sonradan olayı kavradığımda bu terim yerine daha açıklayıcı olabilecek "javascript kod enjeksiyonu" ya da "html enjeksiyonu" ifadelerini tercih edebilirdim.

    1996 yılında, netscape communications corporation tarafından javascript dilinin icadı, web için bir dönüm noktası oldu. javascript, web sayfalarına interaktiflik kazandırarak kullanıcı deneyimini kökten değiştirdi. yeni teknolojinin getirdiği yenilikler beraberinde beklenmedik güvenlik sorunlarını da getirdi. javascript'in yaratılmasından kısa bir süre sonra, netscape javascript ile ilgili ilk güvenlik açıklarını yaşamaya başladı. bu açıklarla kötü niyetli kişilerin kullanıcıların bilgilerini çalmasına veya sisteme zarar vermesine olanak tanıyordu. bu dönemde tarayıcılar arasında güvenlik rekabeti de başlamıştı ama güvenlik henüz öncelikli bir konu değildi. netscape'in ardından microsoft'un ınternet explorer'ı da piyasaya sürüldü ve hızla popülerlik kazandı. ınternet explorer da netscape gibi çeşitli güvenlik açıklarına sahipti. bu dönemde, "browser wars" olarak adlandırılan rekabet, her iki tarayıcının da daha fazla özellik eklemesine neden oldu fakat güvenlik sorunları göz ardı edildi. özellikle, bir web sitesinin başka bir siteye ait verilere erişmesini engellemek için tasarlanmış same-origin policy ihlali önemli bir sorundu. 1990ların sonunda microsoft mühendisleri, bu tür ihlalleri analiz ederken, web sitelerinin kendilerindeki kodlama hatalarının bu güvenlik açıklarını daha da karmaşık hale getirdiğini fark ettiler. 2000 yılına gelindiğinde, microsoft güvenlik mühendisleri, web sitelerindeki kodlama hatalarının ve tarayıcı güvenlik ihlallerinin birleşiminden kaynaklanan yeni bir güvenlik açığı tespit ettiler. hotmail üzerinden alınan bir maillerde kötü niyetli kişiler mailin içeriğine kendi javascript kodlarını ekleyip bunu browser'da çalıştırabiliyorlardı. bu sebepten bu açığa "cross-site scripting" (xss) adını verdiler.

    yazının başında dediğim "javascript kod enjeksiyonu" veya "html enjeksiyonu" gibi açıklayıcı terimler bence daha iyi olabilirdi ama neden xss seçtiklerini de anlayabiliyorum. bahsettiğim terimler saldırının "sitelerarası" yönünü ve web siteleri arası etkileşimlerdeki potansiyel tehlikeleri vurgulamıyor. xss ismi sadece kod enjeksiyonundan daha fazlasını içeriyor. bir web sitesinin başka bir site üzerindeki kullanıcı etkileşimlerini manipüle etme yeteneğini de ifade ediyor.

    microsoft mühendisleri bunları çözebilmek için ilk olarak hotmail'de kullanıcıların zararlı javascript kodu içeren e-postalara maruz kalmasını engellemek amacıyla e-posta içeriklerinin daha sıkı bir şekilde filtrelenmesi sağlandı. ınternet explorer tarafında ise, xss'e karşı daha güçlü korumalar ekledi. tarayıcının same-origin policy uygulamalarını iyileştirdi. burada ufak bir parantez açayım. same-origin policy, bir web sitesinin başka bir kaynaktan (farklı bir domain, protokol veya port) gelen verilere erişimini sınırlar. böylece xss saldırılarına karşı önemli bir savunma hattı oluşturur.

    xss tarihini bilmek günümüz internet teknolojilerinin güvenliğini anlamak için kritik öneme sahiptir. microsoft'un hotmail ve ınternet explorer üzerinde yaptığı çalışmalar, web güvenliği konusundaki genel yaklaşımı büyük ölçüde şekillendirdi ve bugünkü web güvenlik uygulamalarının temellerini attı.

    aslında yazıyı yazılımsal perspektiften de devam ettirip xss türleri (reflected, stored ve dom xss), bunların önleme yöntemleri (validation, sanitizing, csp), tespiti için hangi araçları kullanabileceğiniz (owasp zap, waf'lar, fortify, dast araçları) gibi konulardan da bahsetmek isterdim ama şu anda bile internette okumak için fazlasıyla uzun bir yazı oldu. onları da belki başka bir gün detaylıca anlatırım.
  • kimileri tarafindan hic sallanmayan, kimileri tarafindan da asiri abartilan olay.ornegin herhangi bir web uygulamasinda buldugunuz xss ile ilgili advisorynizi bir infosec sitesine yolladiginizda "baba valla xss yayinlamiyoruz gecti bunun modasi" tarzinda bir cevap alirken, diger taraftan da "xss is the new buffer overflow" diyen insanlarla karsilasabilirsiniz.
  • kaliteli sitelerin hemen hemen hepsinde olan ve çoğu zaman "amaan nolcak bu da açık mı kıytırık bişi" diye site sahipleri tarafından geçiştirilen güvenlik açığı. sallamamalarının en büyük sebebi ise açığı saniyeler içinde kapatmalarıdır. önlemek için 2 kelimelik kod parçası yeter. ayrıca 1 tane varsa bundan en fazla 3 tane daha vardır*.
  • aldığı parametreyi,veriyi kabak gibi html'e yazan sayfalara javascript kullanarak sızma işlemi.
    http://video.google.com/…?docid=6026634286422106971
  • https://netsec.expert/posts/xss-in-2021/

    soyle bir cheat sheet'ini buldum. ise yarar diye kendime not aliyorum. buradan sonrasini okumayin. onemli bir sey de yazmayacagim zaten, gereksiz bos bos yazi.
  • parametre alabilen bir yere, cali$abilen ve cali$tiginda i$inize yarayacak bir $eyler dondurebilen bir kod ekleyerek sizma* i$lemi. benzer bir yontem icin (bkz: sql injection)
  • kanallar arası düşünülerek exploit edilmesi gereken saldırı tekniği. örneğin mobil kanalda girdi olarak kabul edilebilen bir kodun tarayıcı veya test edilen kurumun dahili sistemlerinde çalışma ihtimaline karşı denenmesi günümüzde daha kaliteli sonuçlar verebilir. aksi halde mevcut güvenlik önlemleri karşısında çok şansı kalmayan web tabanlı zaafiyet konusudur.
hesabın var mı? giriş yap