Örnek sorular
Security Web VulnerabilitiesZorluk 1
Bir kullanıcının gönderdiği yorum diğer ziyaretçilere değiştirilmeden gösteriliyor. Yorum bir <script> etiketi içerirse, tarayıcı sayfayı görüntüleyen herkes için bu script'i çalıştırıyor. Bu ne tür bir zafiyet?
- aStored XSS, sunucuda saklanıp sonraki görüntüleyenlere yansıtılır✓
- bSQL injection, script bir veritabanı komutu olarak ayrıştırılır
- cCSRF, kurban adına sahtelenmiş bir istek
- dSSRF, sunucunun iç bir kaynağa bağlanması
Açıklama:Payload depolamaya (ör. veritabanı) yazıldığı ve sonraki ziyaretçilere kaçışsız gösterildiği için bu stored (kalıcı) XSS'tir — klasik örnek, diğer kullanıcılara sanitize edilmemiş HTML'i yansıtan bir yorum ya da profil alanıdır.
Security Web VulnerabilitiesZorluk 2
Bir arama sayfası, sorgu dizesini kodlamadan doğrudan başlığa gömüyor: <h1>Results for: {query}</h1>. Saldırgan, bu sorgu parametresinde script içeren hazırlanmış bir bağlantıyı kurbana gönderiyor; script yalnızca kurban bağlantıya tıklayınca çalışıyor. Bu hangi XSS türüdür?
- aStored XSS, veritabanında kalıcı olarak saklanır
- bReflected XSS, yalnızca tıklanan hazırlanmış bağlantıyla tetiklenir✓
- cDOM-based XSS, sunucuya hiç değmez
- dBlind XSS, saldırgan yanıtı hiç göremez
Açıklama:Payload yalnızca istekte (URL/sorgu dizesi) yaşar ve yanıtta anında yansıtılır — hiçbir şey saklanmaz. Kurban başına hazırlanmış bir bağlantı gerektirmesi reflected XSS'in ayırt edici özelliğidir.
Security Web VulnerabilitiesZorluk 2
Bir sayfanın istemci tarafı JavaScript'i location.hash'ten bir değer okuyup bunu innerHTML ile DOM'a ekliyor; bu değer hiçbir zaman sunucuya gönderilmiyor veya sunucu tarafından işlenmiyor. Bu, stored ya da reflected XSS'ten farkı nedir?
- aİstismar için doğrudan veritabanı erişimi gerekir
- bYalnızca kimliği doğrulanmış bir yönetici tetikleyebilir
- cZafiyetli akış tamamen istemci tarafında, tarayıcıda kalır✓
- dSite çerez kullanmadığı sürece istismar edilemez
Açıklama:DOM-based XSS, kaynak-hedef akışının tamamen tarayıcı JavaScript'inde gerçekleşmesiyle tanımlanır (ör. location.hash → innerHTML). Stored (sunucuda kalıcı) veya reflected (sunucu tarafından yansıtılan) XSS'in aksine sunucuya hiç gidiş-dönüş yoktur.
Security Web VulnerabilitiesZorluk 1
Bir geliştirici kullanıcı yorumunu element.innerHTML = comment; ile gösteriyor. Bu neden sayfayı XSS'e açık hale getirir?
- a
innerHTML, textContent'ten yavaştır, bir zamanlama yan kanalı - bTarayıcı
innerHTML ile atanan dizeleri render etmeyi reddeder - c
innerHTML tasarım gereği yalnızca aynı-origin veriyi kabul eder - d
innerHTML dizeyi markup olarak ayrıştırır, script'ler çalışır✓
Açıklama:innerHTML kendi argümanını HTML olarak yeniden ayrıştırır. comment içindeki herhangi bir <script> veya <img onerror=...> benzeri markup, atıl metin yerine tarayıcının çalıştırdığı canlı DOM'a dönüşür.
Security Web VulnerabilitiesZorluk 2
Aynı güvenilmeyen comment değeri iki farklı şekilde render ediliyor: Versiyon 1 element.textContent = comment kullanıyor, Versiyon 2 element.innerHTML = comment kullanıyor. Versiyon 1 neden XSS'e karşı güvenliyken Versiyon 2 değil?
- a
textContent dizeyi düz metin gösterir, hiç ayrıştırılmaz✓ - b
textContent dizeden SQL anahtar kelimelerini otomatik çıkarır - c
textContent sayfanın yaptığı tüm ağ isteklerini engeller - d
textContent dizeyi göstermeden önce sessizce şifreler
Açıklama:textContent girdisini asla markup olarak ele almaz — açı parantezleri ve tırnaklar görünür karakterler olarak gösterilir, bu yüzden comment'in çalıştırılabilir bir eleman ortaya çıkarmasının bir yolu yoktur.
Security Web VulnerabilitiesZorluk 1
SQL injection özünde nedir?
- aVeritabanını çok fazla eşzamanlı bağlantıyla boğmak
- bGüvenilmeyen girdinin doğrudan bir sorgu dizesine eklenmesi✓
- cVeritabanı sunucusunun hatalı bir pakette çökmesi
- dYanlış yapılandırmanın anonim yedek erişimine izin vermesi
Açıklama:SQL injection, kullanıcı kontrolündeki verinin veri olarak ayrı tutulmak yerine bir sorgunun metnine karıştırılmasıyla oluşur; böylece özel hazırlanmış girdi sorgunun gerçekte ne yaptığını değiştirebilir.