- Konu sahibi
- #1
Saklanan XSS, saldırganın gönderdiği betik içeriğinin sunucuda veritabanı, yorum, profil alanı veya başka bir kalıcı depoda tutulup daha sonra sayfayı ziyaret eden kullanıcılara sunulmasıdır. Yansıyan XSS ise zararlı girdinin kalıcı olarak kaydedilmeden, genellikle bir URL parametresi veya form verisi üzerinden alınarak aynı HTTP yanıtında kullanıcıya geri gönderilmesidir. Kısaca saklanan XSS sunucuda kalır ve sonraki ziyaretçileri etkileyebilir; yansıyan XSS çoğunlukla özel olarak hazırlanmış isteğin açılmasıyla tetiklenir.
Saklanan XSS akışında saldırgan bir kullanıcı adı, yorum veya destek talebi gibi bir alana HTML/JavaScript içeren veri gönderir. Uygulama girdiyi kaydeder; temel açık verinin daha sonra güvenli çıktı işleme olmadan çalıştırılabilir bağlama yerleştirilmesidir. Veritabanına ham metin kaydetmek tek başına XSS değildir; saklama anında HTML kodlamak da her bağlamı korumaz. Başka bir kullanıcı ilgili sayfayı açtığında kayıt HTML içine güvenli olmayan biçimde yerleştirilir ve tarayıcı bunu metin yerine kod olarak yorumlayabilir.
Örneğin bir ürün yorumunda şu tür bir içerik saklanıyorsa:
Bu yalnız temsili bir kod işaretidir; içindeki yorum bir işlem yapmaz. Gerçek açığın etkisi, aynı bağlama yerleşen çalıştırılabilir içeriğin sayfada yürütülebilmesidir. Buradaki önemli nokta, yöneticinin saldırganın ilk isteğini görmemiş olsa bile daha sonra yalnızca sayfayı açarak etkilenebilmesidir.
Yansıyan XSS'te veri kalıcı depoya yazılmaz. Arama sayfasının
Aşağıdaki karşılaştırma, olayın kaynağını ve ilk müdahale önceliğini ayırmaya yardımcı olur.
Saklanan türde etki alanı daha geniş olabilir; çünkü tek bir kayıt çok sayıda ziyaretçiye ulaşabilir. Yansıyan türde ise saldırganın kurbanı belirli bir bağlantıyı açmaya yönlendirmesi gerekebilir. Ancak önem derecesi yalnızca tür adına göre belirlenmez. Kullanıcının yetkileri, verinin hangi HTML veya JavaScript bağlamına girdiği ve sayfanın kimler tarafından açıldığı ayrıca incelenmelidir.
XSS-TEST-123 gibi düz metin işaret yalnız veri akışını izler; görünmesi XSS kanıtı değildir ve bu işaretin yapıyı değiştirmesi beklenmez. Yetkili testte bağlama uygun encoding/sanitizasyon ayrıca doğrulanır; bu rehber çalıştırılabilir saldırı yükü kullanmaz. Yalnızca istemci tarafında yapılan filtrelemeye güvenmek de yeterli değildir; istek farklı bir istemciyle gönderilebilir. Content Security Policy ve uygun çerez öznitelikleri ek savunma sağlar, fakat hatalı çıktı üretimini düzeltmenin yerine geçmez.
En yaygın hata, veritabanına yazılmayan her XSS'i “önemsiz” kabul etmektir. Yansıyan XSS, yetkili bir kullanıcının oturum bağlamında çalışabildiği için ciddi sonuç doğurabilir. Diğer hata yalnızca girişte filtre uygulamaktır. Aynı veri farklı bir ekranda veya farklı bir bağlamda tekrar kullanıldığında filtre atlatılabilir ya da yetersiz kalabilir. Ayrıca saklanan XSS düzeltildiğinde eski kayıtların, önbelleklerin ve farklı yönetim ekranlarının kontrol edilmemesi açık kapı bırakabilir.
Stored/reflected ayrımı verinin kalıcılığına, server/client (DOM) ayrımı ise güvensiz işlem yoluna ilişkindir; birbirini dışlayan üç ayrı kutu değildir. Her iki kalıcılık türü de istemci tarafındaki tehlikeli DOM sink’leriyle birleşebilir.
Aynı kullanıcı girdisi uygulamanın farklı yollarında iki davranış gösterebilir. Örneğin veri bir ekranda anında yanıta eklenirken başka bir ekranda veritabanından okunabilir. Bu nedenle sınıflandırma, açığın adına değil verinin belirli akışına göre yapılmalıdır.
Önce girdinin kaydedildiği alanlar, bu alanları gösteren yönetici ve kullanıcı sayfaları, ardından aynı parametreyi yanıtlayan hata ve arama ekranları incelenmelidir. Böylece yalnızca görünen sayfa değil, aynı veriyi kullanan diğer yollar da kapsanır.
Nasıl çalışırlar?
Saklanan XSS akışında saldırgan bir kullanıcı adı, yorum veya destek talebi gibi bir alana HTML/JavaScript içeren veri gönderir. Uygulama girdiyi kaydeder; temel açık verinin daha sonra güvenli çıktı işleme olmadan çalıştırılabilir bağlama yerleştirilmesidir. Veritabanına ham metin kaydetmek tek başına XSS değildir; saklama anında HTML kodlamak da her bağlamı korumaz. Başka bir kullanıcı ilgili sayfayı açtığında kayıt HTML içine güvenli olmayan biçimde yerleştirilir ve tarayıcı bunu metin yerine kod olarak yorumlayabilir.
Örneğin bir ürün yorumunda şu tür bir içerik saklanıyorsa:
HTML:
<script>/* temsili içerik */</script>Bu yalnız temsili bir kod işaretidir; içindeki yorum bir işlem yapmaz. Gerçek açığın etkisi, aynı bağlama yerleşen çalıştırılabilir içeriğin sayfada yürütülebilmesidir. Buradaki önemli nokta, yöneticinin saldırganın ilk isteğini görmemiş olsa bile daha sonra yalnızca sayfayı açarak etkilenebilmesidir.
Yansıyan XSS'te veri kalıcı depoya yazılmaz. Arama sayfasının
q parametresini alıp doğrudan HTML yanıtına eklediğini varsayalım. Kullanıcı q=ornek gönderdiğinde sayfa “Şunun için sonuçlar: ornek” metnini üretir. Uygulama bu değeri kodlamadan HTML'e yerleştirirse saldırgan, özel hazırlanmış bir bağlantıyı kurbanın açmasını sağlamaya çalışabilir. İstek işlenir, içerik yanıt içinde yansır ve sayfa tarayıcıda çalışır; daha sonra aynı içerik yeni ziyaretçilere otomatik olarak gösterilmez.Temel farkları
Aşağıdaki karşılaştırma, olayın kaynağını ve ilk müdahale önceliğini ayırmaya yardımcı olur.
| Özellik | Saklanan XSS | Yansıyan XSS |
|---|---|---|
| Verinin durumu | Sonraki kullanım için saklanır; istemci depolamasında da kalıcı XSS akışı olabilir | Genellikle yalnızca mevcut istekte taşınır |
| Tetiklenme | Etkilenen sayfanın açılması yeterli olabilir | Özel isteğin veya bağlantının işlenmesi gerekir |
| Tipik alan | Yorum, profil, mesaj, yönetim kaydı | Arama, hata, filtre veya yönlendirme parametresi |
| Öncelikli inceleme | Kayıtlı verinin temizlenmesi ve çıktı kodlaması | İstek parametresinin çıktıda güvenli işlenmesi |
Saklanan türde etki alanı daha geniş olabilir; çünkü tek bir kayıt çok sayıda ziyaretçiye ulaşabilir. Yansıyan türde ise saldırganın kurbanı belirli bir bağlantıyı açmaya yönlendirmesi gerekebilir. Ancak önem derecesi yalnızca tür adına göre belirlenmez. Kullanıcının yetkileri, verinin hangi HTML veya JavaScript bağlamına girdiği ve sayfanın kimler tarafından açıldığı ayrıca incelenmelidir.
Uygulanabilir inceleme ve düzeltme adımları
- Önce etkilenen alanı izole edin. Testi yalnızca yetkili olduğunuz sistemde ve gerçek kullanıcıları etkilemeyecek bir test kaydıyla yapın. Zararlı betik yerine
XSS-TEST-123gibi zararsız, kolay izlenebilir bir işaret kullanın. - İşaretin kaynağını takip edin. Değer veritabanında veya uygulama kayıtlarında sonraki isteklerde tekrar görünüyorsa saklanan XSS şüphesi vardır. Yalnızca gönderilen isteğin yanıtında görünüyorsa yansıyan XSS olasılığı yüksektir.
- Değerin girdiği bağlamı belirleyin: HTML metni, HTML özniteliği, JavaScript kodu, CSS veya URL. Her bağlam için uygun çıktı kodlaması gerekir; tek bir genel değiştirme işlemi tüm bağlamları güvenli hâle getirmez.
- Sunucu tarafında veriyi güvenli çıktı kodlamasıyla üretin. Kullanıcı tarafından sağlanan HTML gerçekten gerekli değilse HTML olarak yorumlanmasına izin vermeyin; metin olarak gösterin. Zengin metin gerekiyorsa izin verilen öğeleri sınırlayan güvenilir bir sanitizasyon yaklaşımı kullanın.
- Saklanan türde mevcut kayıtları da düzeltin veya karantinaya alın. Doğru çıktı işleme mevcut kaydın çalışmasını da önleyebilir; ancak eski önbellek, alternatif render yolu ve kayıtlı içerik ayrıca değerlendirilmelidir. Gerekli olay kanıtı ve yedeği koruyarak kapsamlı düzeltme yapın. Yansıyan türde ise parametrenin üretildiği tüm yanıt yollarını, hata sayfalarını ve yönlendirmeleri inceleyin.
- Düzeltmeden sonra aynı işareti farklı kullanıcı rolleriyle ve ilgili tüm ekranlarda yeniden deneyin. İşaret düz metin olarak görünmeli, HTML yapısını değiştirmemeli ve beklenmeyen bir tarayıcı davranışı oluşturmamalıdır.
XSS-TEST-123 gibi düz metin işaret yalnız veri akışını izler; görünmesi XSS kanıtı değildir ve bu işaretin yapıyı değiştirmesi beklenmez. Yetkili testte bağlama uygun encoding/sanitizasyon ayrıca doğrulanır; bu rehber çalıştırılabilir saldırı yükü kullanmaz. Yalnızca istemci tarafında yapılan filtrelemeye güvenmek de yeterli değildir; istek farklı bir istemciyle gönderilebilir. Content Security Policy ve uygun çerez öznitelikleri ek savunma sağlar, fakat hatalı çıktı üretimini düzeltmenin yerine geçmez.
Sık yapılan hatalar
En yaygın hata, veritabanına yazılmayan her XSS'i “önemsiz” kabul etmektir. Yansıyan XSS, yetkili bir kullanıcının oturum bağlamında çalışabildiği için ciddi sonuç doğurabilir. Diğer hata yalnızca girişte filtre uygulamaktır. Aynı veri farklı bir ekranda veya farklı bir bağlamda tekrar kullanıldığında filtre atlatılabilir ya da yetersiz kalabilir. Ayrıca saklanan XSS düzeltildiğinde eski kayıtların, önbelleklerin ve farklı yönetim ekranlarının kontrol edilmemesi açık kapı bırakabilir.
Stored/reflected ayrımı verinin kalıcılığına, server/client (DOM) ayrımı ise güvensiz işlem yoluna ilişkindir; birbirini dışlayan üç ayrı kutu değildir. Her iki kalıcılık türü de istemci tarafındaki tehlikeli DOM sink’leriyle birleşebilir.
Kaynaklar
Sık sorulan sorular
Bir açık hem saklanan hem yansıyan XSS olabilir mi?
Aynı kullanıcı girdisi uygulamanın farklı yollarında iki davranış gösterebilir. Örneğin veri bir ekranda anında yanıta eklenirken başka bir ekranda veritabanından okunabilir. Bu nedenle sınıflandırma, açığın adına değil verinin belirli akışına göre yapılmalıdır.
XSS bulgusunda ilk olarak hangi kayıtlar incelenmeli?
Önce girdinin kaydedildiği alanlar, bu alanları gösteren yönetici ve kullanıcı sayfaları, ardından aynı parametreyi yanıtlayan hata ve arama ekranları incelenmelidir. Böylece yalnızca görünen sayfa değil, aynı veriyi kullanan diğer yollar da kapsanır.
