TurkTeam | Türk Siber Güvenlik Topluluğu - Web Uygulama Güvenliği

postMessage Güvenliği: Storybook CVE-2026-114125 Üzerinden Origin Doğrulama

Fri, 23 Oct 2026 11:30:39 +0300

Selamlar,

Storybook ekibi CVE-2026-114125 (GHSA-f2ph-cmg5-wxc8, CVSS 4.0 9.4) ile ilgili danışmayı yayımladı: çalışan bir storybook dev sunucusunun preview iframe'i herhangi bir web sitesine gömülebiliyor ve her origin'den postMessage olayı kabul ediyordu. Kötü niyetli bir site, kullanıcı etkileşimiyle dev sunucusunun story dosyalarını değiştirmesini sağlayabiliyor; değişen dosya yerel bir runtime tarafından çalıştırılırsa geliştiricinin yetkisiyle kod çalışabiliyordu. Bu konu, olayı özetleyip kendi kodunuzda postMessage'ı nasıl güvenli kullanacağınızı anlatıyor.

Konuda anlatılacaklar

Storybook açığının özeti ve yamalı sürümler
postMessage nasıl çalışır?
Hatalı ve doğru alıcı kodu
Gönderen tarafta hedef origin
Kontrol listesi

Storybook özeti

Etkilenen: Storybook 8, 9, 10 ve 11 alpha dev sunucuları (@storybook/addon-mcp ve @storybook/addon-vitest dahil).
Yamalı: 8.6.19, 9.1.21, 10.6.2, 11.0.0-alpha.6. Yükseltmeden storybook dev çalıştırmayın.
Etkilenmeyen: Build edilmiş statik Storybook'lar ve tarayıcıda hiç açılmayan dev sunucuları.
Yeni varsayılanlar: farklı host adına iframe gömme kapalı; preview ve manager yalnızca kendi origin'i ve localhost servisleriyle mesajlaşıyor. Eski davranış için security.insecureRemoteIframeEmbed ve security.insecureIframeMessaging bayrakları var ama ekip bunları önermiyor.
Danışmaya göre Chrome ve Firefox'un yeni sürümleri bir sitenin localhost'a bağlanmadan önce izin isteyebiliyor; güvenmediğiniz sitelere bu izni vermeyin.

CWE listesi de öğretici: CWE-346 (Origin Validation Error), CWE-1021 (iframe kısıtlaması), CWE-22 (path traversal), CWE-862 (eksik yetkilendirme). Yani tek bir hata değil, birkaç zayıf katmanın zinciri.

postMessage nasıl çalışır?
window.postMessage farklı origin'deki pencereler (ana sayfa ile iframe, açılan popup) arasında güvenli mesajlaşma için tasarlandı. Ama "güvenli" olması iki tarafın da kontrol yapmasına bağlı. MDN açıkça uyarıyor: mesaj alan taraf event.origin'i doğrulamazsa, herhangi bir site mesaj gönderebilir.

Hatalı alıcı

Kod:
// YANLIS: her origin'den gelen mesaja guveniyor
window.addEventListener("message", (e) => {
  if (e.data.type === "updateFile") {
    saveFile(e.data.path, e.data.content);   // tehlikeli islem
  }
});

Doğru alıcı

Kod:
const ALLOWED = new Set(["https://app.ornek.com", "http://localhost:6006"]);
window.addEventListener("message", (e) => {
  // 1) Origin'i tam eslesme ile dogrula (includes/startsWith kullanma)
  if (!ALLOWED.has(e.origin)) return;
  // 2) Kaynagin beklenen pencere oldugunu kontrol et
  if (e.source !== expectedFrame.contentWindow) return;
  // 3) Veriyi sema ile dogrula
  const d = e.data;
  if (typeof d !== "object" || d.type !== "setArgs") return;
  // 4) Tehlikeli islemleri mesajla tetikleme; yalnizca dar kapsamli UI durumu
  applyArgs(sanitize(d.args));
});

Sık hata: e.origin.includes("ornek.com") gibi kontroller; "ornek.com.saldirgan.net" bunu geçer. Her zaman tam eşleşme kullanın.

Gönderen taraf

Kod:
// YANLIS: "*" hedefi, mesaji kim yuklenmisse ona verir
frame.contentWindow.postMessage(secretToken, "*");
// DOGRU: hedef origin'i acikca yaz
frame.contentWindow.postMessage({type:"init"}, "https://widget.ornek.com");

Kontrol listesi

Her message dinleyicisinde izin listesiyle tam origin eşleşmesi.
Mesajla dosya yazma, komut çalıştırma, kimlik bilgisi aktarma gibi yan etkili işlem yapmayın.
Gömülmesini istemediğiniz sayfalarda Content-Security-Policy: frame-ancestors 'self' kullanın.
Geliştirme sunucularını (Storybook, Vite, Jupyter) yalnızca localhost'a bağlayın ve güncel tutun.
Kod incelemesinde "addEventListener('message'" araması yapın.

Kod:
grep -rn "addEventListener(\s*['\"]message" src/ | head
grep -rn "postMessage(.*['\"]\*['\"]" src/ | head

Kendi projelerinizde postMessage dinleyicilerini en son ne zaman denetlediniz? Bulduğunuz hatalı kalıpları paylaşın.

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

11-b01-postmessage-origin.png (Dosya Boyutu: 124.37 KB / İndirme Sayısı: 3)

Güvenli Olmayan Deserialization: pickle, YAML ve Java için OWASP Özeti

Thu, 22 Oct 2026 11:35:44 +0300

Selamlar,

CISA'nın SafePay uyarısında Veeam Backup & Replication için adı geçen CVE-2024-40711, CWE-502: Deserialization of Untrusted Data sınıfında. Yani sorun yeni değil; fidye grupları hâlâ bu sınıftan besleniyor. Bu yazıda OWASP Deserialization Cheat Sheet'in pratik kısımlarını Python, Java ve genel prensipler üzerinden özetliyorum.

Konuda anlatılacaklar

Serialization / deserialization nedir?
Python: pickle ve YAML
Java: ObjectInputStream ve filtreler
Genel kural: güvenilmeyen veriyi native formatta açmayın

Kısa tanım
Serialization bir nesneyi saklanabilir / gönderilebilir bir formata çevirmektir; deserialization tersidir. JSON ve XML gibi saf veri formatları görece güvenlidir. Birçok dilin yerel (native) formatı ise özelleştirme özellikleri sunar; bu özellikler güvenilmeyen veride RCE, DoS veya erişim kontrolü atlatmaya dönüşebilir.

Python
OWASP'ın net uyarısı:

pickle.load / pickle.loads: Güvenilmeyen veriyi asla unpickle etmeyin; keyfi kod çalıştırabilir.
PyYAML: Güvenilmeyen YAML için yaml.safe_load() kullanın; yaml.unsafe_load veya Loader=yaml.Loader / UnsafeLoader kullanmayın.
jsonpickle.decode: Güvenilmeyen girdiyle kullanmayın.

Kod:
# Kendi labiniz - guvenli YAML
import yaml
metin = "liste: [1, 2, 3]"
veri = yaml.safe_load(metin)
print(veri)
# pickle: yalnizca tamamen guvendiginiz, sizin urettiginiz baytlar

Java

ObjectInputStream.readObject / readUnshared, XStream.fromXML, XMLDecoder gibi API'leri güvenilmeyen girdiyle kullanmayın.
Serialization filter'ları uygulama özel sınıf allow-list'i ve kaynak limitleriyle yapılandırın.
resolveClass() override'ı tek başına yeterli değildir; grafik derinliği, referans sayısı, dizi uzunluğu ve akış boyutu da sınırlanmalıdır.
Hex'te AC ED 00 05 veya Base64'te rO0 ile başlayan trafik Java serialization işareti olabilir.

Genel prensipler

Mümkünse native format yerine JSON/XML gibi saf veri formatı kullanın.
Akışın nesne tipini belirlemesine izin vermeyin.
İmzalı (imzası doğrulanmış) veriyi deserialize edin.
Hassas alanları transient yapın; asla deserialize edilmemesi gereken sınıflarda readObject her zaman istisna fırlatsın.

SafePay bağlamında ders basit: yedekleme ürünlerindeki yıllardır bilinen deserialization RCE'leri hâlâ aktif sömürü vektörü. Envanterinizde Veeam, eski Java serileştirme uçları ve pickle kullanan dahili API'ler varsa bunları "teknik borç" değil "açık kapı" olarak işaretleyin.

Kod tabanınızda pickle veya yaml.load (safe olmayan) kalan yer var mı? Grep sonucunuzu (dosya yolu yeter) paylaşın.

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

18-k03-deserialization.png (Dosya Boyutu: 121.98 KB / İndirme Sayısı: 11)

ReDoS Nedir? Evil Regex, Backtracking ve GitLab Regex Açıkları Bağlamı

Thu, 22 Oct 2026 11:34:41 +0300

Selamlar,

GitLab'ın bu ay üst üste iki CVSS 10 regex derleyici açığı yayınlaması (CVE-2026-97229 ve CVE-2026-110264) birçok ekibi aynı soruya getirdi: düzenli ifadeler neden bu kadar tehlikeli olabiliyor? GitLab açıkları bellek taşması sınıfındaydı; ama aynı ailede daha yaygın görülen bir kardeş var: ReDoS (Regular Expression Denial of Service). Bu yazıda OWASP'ın ReDoS sayfasına dayanarak evil regex kavramını ve kendi kodunuzda nasıl tarayacağınızı anlatıyorum.

Konuda anlatılacaklar

Naif regex motoru ve backtracking
Evil regex nedir?
Saldırı senaryoları
Lab ve savunma

Naif algoritma
OWASP'a göre birçok regex motoru NFA (Nondeterministic Finite Automaton) kurar ve eşleşme bulunana kadar olası yolları tek tek dener. Girdi eşleşmezse motor önceki konumlara dönüp (backtracking) başka yolları dener. Kötü yazılmış bir desende yol sayısı girdi uzunluğuyla üstel büyür; örneğin ^(a+)+$ deseni için aaaaX 16 yol, on altı a içeren girdi 65536 yol üretebilir.

Evil regex
OWASP, şu özelliklere sahip desenleri "evil" sayar:

Tekrar içeren gruplama
Tekrarlanan grubun içinde: tekrar veya örtüşen alternasyon

Örnekler: (a+)+$ , ([a-zA-Z]+)*$ , (a|aa)+$ , (a|a?)+$
Bu desenler aaaaaaaaaaaaaaaaaaaaaaaa! gibi bir girdide motoru uzun süre meşgul edebilir.

Saldırı senaryoları

Web uygulamasında kullanıcı girdisinin evil bir regex ile doğrulanması (e-posta, sınıf adı vb.)
Regex'in kendisinin kullanıcı girdisinden etkilenmesi (regex injection) - OWASP örneğinde kullanıcı adı regex olarak derleniyor
WAF / tarayıcı / veritabanı katmanındaki regex'lerin hedef alınması

GitLab açıkları ReDoS değil, derleyici tamsayı taşması yoluyla RCE idi; ama ortak ders aynı: kullanıcı kontrolündeki veya karmaşık regex'leri güven sınırı olarak görmeyin.

Lab

Kod:
# Python - kendi labiniz (kisa timeout ile)
import re, time
pat = re.compile(r"(a+)+$")
s = "a" * 28 + "!"
t0 = time.time()
try:
    pat.search(s)
finally:
    print("sure_s:", round(time.time() - t0, 3))

Girdi uzunluğunu artırdıkça sürenin hızla büyüdüğünü görürsünüz. Üretimde böyle bir deseni kullanıcı girdisine uygulamayın.

Savunma

Kullanıcı girdisini regex'e gömmeyin; sabit bir desen kullanın.
Mümkünse doğrulamayı regex yerine parser / allow-list ile yapın.
Backtracking'siz motorlar veya atomic grouping / possessive quantifier kullanın (dile göre).
Regex çalıştırırken zaman ve bellek limiti koyun.
Bağımlılıklarınızda ve WAF kurallarınızda evil regex tarayıcıları (ör. rxxr2, regexploit) çalıştırın.

Kod tabanınızda kullanıcı girdisinden derlenen regex var mı? Son denetimde ne buldunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

17-k02-redos.png (Dosya Boyutu: 118.88 KB / İndirme Sayısı: 10)

Path Traversal Nedir? Dot-Dot-Slash, Encoding ve Güvenli Dosya Erişimi

Wed, 21 Oct 2026 11:22:47 +0300

Selam,

Dosya indirme, şablon yükleme, log görüntüleme... Kullanıcı girdisi dosya yoluna karıştığı anda Path Traversal (directory traversal, CWE-22) kapıda. Bu yazıda saldırı mantığını, encoding oyunlarını ve güvenli deseni kendi labınızda (DVWA / Juice Shop) denenecek şekilde anlatıyorum.

Konuda anlatılacaklar

Saldırının özü: ../ ve mutlak yol ile web kökü dışına çıkmak
Encoding / çift encoding / null byte notları
Kırılgan PHP örneği ve düzeltilmiş desen
Test checklist (yalnızca izinli lab)

Klasik kırılgan desen

Kod:

İstek: Kod:
?file=../../../../etc/passwd
 — include kökün dışına yürür (izinler elverdiği ölçüde).



Encoding varyasyonları (OWASP)%2e%2e%2f ve ..%2f → ../


Windows için ..%5c / %2e%2e%5c


Çift encoding: %252e%252e%255c


Eski ortamlar: ..%c0%af gibi overlong UTF-8


Null byte (eski Java/PHP): secret.doc%00.pdf



Konteyner çoğu zaman bir kez decode eder; uygulamanın ikinci kez decode etmesi filtreyi bypass ettirir.



Nasıl kapatılır?Kullanıcıdan ham yol almayın; kimlik (ID) -> sunucu tarafı eşleme kullanın.


Girdi allowlist: sadece [a-z0-9._-] ve uzantı beyaz listesi.


realpath() / Path.GetFullPath sonrası kök dizinin altında mı diye öneki doğrulayın.


Chroot / ayrı kullanıcı / salt-okunur volume ile blast radius küçültün.


Hassas dosyaları web köküne koymayın.





Kod:
# Python güvenli iskelet (fikir)
from pathlib import Path
ROOT = Path("/var/www/templates").resolve()
def open_user_file(name: str) -> Path:
    if "/" in name or "\\" in name or name.startswith("."):
        raise ValueError("invalid")
    p = (ROOT / name).resolve()
    if not str(p).startswith(str(ROOT) + os.sep) and p != ROOT:
        raise ValueError("escape")
    return p


Labda test fikri

DVWA File Inclusion / Juice Shop'ta path ile oynayın. Amacınız /etc/passwd okumak değil; filtrenin nasıl kırıldığını ve doğru düzeltmeyi görmek. Burp Repeater'da encoding matrisini tek tek deneyin, her denemeyi not edin.



Yasal uyarı

Yalnızca sahip olduğunuz veya yazılı izinli sistemlerde test edin. TCK 243-245.



Kaynaklarhttps://owasp.org/www-community/attacks/Path_Traversal


https://cwe.mitre.org/data/definitions/22.html





WAF ve ikincil kontroller

WAF ../ imzaları yardımcı olur ama encoding ile aşılabilir; asıl düzeltme uygulama katmanındadır. Loglarda %2e%2e ve ..\ yoğunluğu erken uyarıdır. SecComp / read-only rootfs konteynerde blast radius'u küçültür.







Uygulamada sık gördüğüm hatalar

Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.



Ekip içi iletişim şablonu

Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.



Lab not defteri

Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.



İzleme ve doğrulama

Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.



Sonuç

Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.





Adım adım kontrol listesi (kopyala-yapıştır)

Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).


Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.


İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.


Yama veya yapılandırma azaltmasını stagingde deneyin.


Üretim penceresinde uygulayın; değişiklik kaydı açın.


Servis sağlık kontrolü + log doğrulaması yapın.


Gerekliyse IOC avı veya compromise assessment planlayın.


Kapanış notunu yazın: sürüm, tarih, kim onayladı.





Sık sorulanlar

Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.

PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.

WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.

Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.



Örnek komut defteri

Kod:
# Tarih damgası ve ortam notu
date -Is
hostnamectl 2>/dev/null | head -5 || true
# Ağ dinleme özeti (lab)
ss -lntp | head -30
# Son reboot / güncelleme ipucu (systemd)
who -b 2>/dev/null || true
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.



İlgili TurkTeam bölümleri

Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.



Kapanış ve yasal çerçeve

TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.



Kişisel deneyim notu

Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.



Okuma listesiÜretici / araştırmacı birincil yazısı (kaynakçada)


CISA KEV veya CERT duyurusu varsa o


Kendi iç runbook'unuzun ilgili maddesi



Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.




  09-t09-path-traversal.png (Dosya Boyutu: 115.06 KB / İndirme Sayısı: 8)



İzinli Labda İlk XSS Bulgum: Rapor Şablonu ve Yeniden Üretme Adımları
Mon, 19 Oct 2026 02:19:15 +0300



Selam,



İlk XSS bulgunuzu labda yeniden üretebilmek ve düzgün raporlamak, bug bounty / pentest hayatında altın değerinde. Bu yazıda izinli labda (DVWA) bulduğum reflected XSS örneğini nasıl yazdığımı ve şablonumu paylaşıyorum. Gerçek müşteri verisi yok.



Yeniden üretme adımları (net olsun)

Ortam: DVWA, security low, Firefox, Burp


Giriş: /dvwa/vulnerabilities/xss_r/


Payload (eğitim): Kod:

Gözlenen: sayfada alert kutusu, yanıtta encode edilmeden dönen girdi



Ekran görüntüsü + HTTP request/response ekleyin. "alert çıktı" tek başına zayıf rapordur.






Rapor şablonu

Başlık: Reflected XSS in /vulnerabilities/xss_r/ (name parameter)

Özet: name parametresi HTML bağlamında encode edilmeden yansıtılıyor; saldırganın JavaScript çalıştırmasına izin veriyor.

Etki: Oturum çerezi hırsızlığı (HttpOnly yoksa), phishing, CSRF ile zincir.

Adımlar: numaralı, kopyala-yapıştır URL/payload.

Kanıt: request, response snippet, screenshot.

Düzeltme: bağlamına uygun encode (OWASP Cheat Sheet), CSP, cookie bayrakları.

CVSS: ortamınıza göre; labda eğitim amaçlı "Medium" örneği verebilirsiniz ama metodolojiyi yazın.



Kaliteli rapor alışkanlıklarıEn kısa çalışan payload + alternatif vektör


Self-XSS ile reflected/stored ayrımını netleştirin


WAF bypass hikâyesi uydurmayın; kanıtlayın


PII / gerçek kullanıcı verisi eklemeyin





Düzeltme tarafı (geliştiriciye not)

Kod:
# Örnek düşünce (dil bağımsız):
# HTML context -> entity encode
# JS context -> JSON encode / güvenli API
# URL context -> URL encode
CSP ek katmandır; tek başına input encode yerine geçmez.



KaynaklarOWASP XSS Prevention Cheat Sheet


PortSwigger XSS lab'ları


CWE-79





İlk raporunuz reddedildiyse gerekçe neydi? "Etki yok" cevabına karşı nasıl revize ettiniz?



Etkiyi abartmadan yazmak

alert(1) kanıtı teknik doğrulamadır; iş etkisi için cookie HttpOnly mı, CSP var mı, oturum cookie'si hangi path'te yazın. "Hesap ele geçirme" iddiası için gerçekçi zincir gerekir. Triager abartıyı görünce güven kaybeder.



Stored XSS farkı

Kayıtlı (stored) XSS'te payload'ın nerede saklandığını ve kimlerin gördüğünü yazın. Admin panelinde stored XSS genelde reflected'dan yüksek etki taşır; yine kanıtla.





Doğrulama senaryosu

Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.



Lab disiplini

Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.



Runbook'a taşımak

İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.



Ölçüm ve alarm sağlığı

Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.



Kapsam ve izin hatırlatması

Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.



Yedekleme ve geri dönüş

Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.



Log saklama süresi

Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.



Yanlış pozitif yönetimi

Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.



Değişiklik yönetimi ile ilişki

Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.



Eğitim tatbikatı

Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.



Doğrulama senaryosu

Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.



Lab disiplini

Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.



Runbook'a taşımak

İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.



Ölçüm ve alarm sağlığı

Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.



Kapsam ve izin hatırlatması

Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.



Yedekleme ve geri dönüş

Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.



Log saklama süresi

Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.



Yanlış pozitif yönetimi

Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.



Değişiklik yönetimi ile ilişki

Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.



Eğitim tatbikatı

Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.



Uygulama notu

Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.




  100-n21-fec995.png (Dosya Boyutu: 65.51 KB / İndirme Sayısı: 13)





  n21-inner.png (Dosya Boyutu: 19.74 KB / İndirme Sayısı: 12)



Burp Intruder ile Labda Parametre Fuzzing: Payload Tipleri ve Örnekler
Mon, 19 Oct 2026 01:55:19 +0300



Merhaba,



Burp Suite Intruder, labda parametre fuzzing için hâlâ en hızlı yollardan biri. Bu yazıda DVWA / Juice Shop labımda Intruder'ı nasıl kullandığımı, payload tiplerini ve rate limit nezaketini anlatıyorum. Yalnızca izinli hedefler.



Hazırlık

Proxy açık, lab trafiği Burp'tan geçiyor


Hedef HTTP history'den Intruder'a Send


Attack type seçimi: Sniper, Battering ram, Pitchfork, Cluster bomb



Tek parametre için Sniper yeter. İki parametreyi birlikte denemek için Pitchfork (eşleşmeli) veya Cluster bomb (kartezyen; patlar, dikkat).



İşaretleme

Payload Positions'ta fuzz edilecek değeri § ile işaretleyin. Örnek: id=§1§. JSON body'de de aynı mantık.






Payload tipleriSimple list: kendi wordlist'iniz


Numbers: 1..1000 (IDOR avı)


Runtime file: büyük listeler


Grep / regex extract ile zincirleme (ileri)



IDOR lab örneği:

Kod:
# Payload: Numbers 1-200
# Grep match: "email" veya "Welcome"
# Length / status code farkına bak


Sonuçları okumak

Status, Length, Words, Grep Match sütunları. Anormal uzunluk = farklı yetki seviyesi veya hata mesajı sızıntısı olabilir. Response'u elle doğrulamadan "bug" demeyin.



Nezaket ve güvenlikResource Pool / Delay ile saniyede istek sayısını düşürün


Production bug bounty'de program kurallarındaki rate limit'e uyun


Login formunda brute force Intruder = çoğu programda yasak


Oturum çerezini öldürmemek için attack sırasında cookie jar'ı bilinçli yönetin





Intruder vs ffuf

Intruder GUI ve tarayıcı akışıyla entegre; ffuf hız ve CLI otomasyonunda önde. Ben keşifte ffuf, oturumlu iş mantığında Intruder kullanıyorum.



KaynaklarPortSwigger Web Security Academy - Burp Intruder


OWASP Testing Guide


DVWA / OWASP Juice Shop (yasal lab)





Siz Cluster bomb'u gerçekten ne zaman kullanıyorsunuz? Ben çoğu senaryoda Pitchfork + manuel ile yetiniyorum.



Grep extract ile zincir

Önceki yanıttan CSRF token çekip sonraki isteğe yerleştirmek Intruder/macros ile yapılır. Labda login + fuzz akışını kaydedin. Session handling rule ile cookie yenilemek, uzun fuzz sırasında 401 yağmurunu keser.



Payload set hijyeni

Başkasının "100MB xss.txt" listesini körlemesine kullanmayın; labda önce 50 satırlık hedefli liste. Production bounty'de aynı kural: kalite > megabayt.





Doğrulama senaryosu

Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.



Lab disiplini

Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.



Runbook'a taşımak

İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.



Ölçüm ve alarm sağlığı

Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.



Kapsam ve izin hatırlatması

Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.



Yedekleme ve geri dönüş

Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.



Log saklama süresi

Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.



Yanlış pozitif yönetimi

Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.



Değişiklik yönetimi ile ilişki

Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.



Eğitim tatbikatı

Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.



Doğrulama senaryosu

Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.



Lab disiplini

Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.



Runbook'a taşımak

İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.



Ölçüm ve alarm sağlığı

Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.



Kapsam ve izin hatırlatması

Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.



Yedekleme ve geri dönüş

Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.



Log saklama süresi

Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.



Yanlış pozitif yönetimi

Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.



Değişiklik yönetimi ile ilişki

Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.



Uygulama notu

Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.




  100-n20-0dfa17.png (Dosya Boyutu: 63.1 KB / İndirme Sayısı: 14)





  n20-inner.png (Dosya Boyutu: 20.26 KB / İndirme Sayısı: 17)



Command Injection: OS Komut Enjeksiyonu ve Güvenli Kodlama Rehberi
Sun, 18 Oct 2026 21:31:33 +0300
[center]
[/center]



Selam millet, BlueTornado burada.



Command Injection (OS komut enjeksiyonu), uygulamanın kullanıcı girdisini işletim sistemi kabuğuna güvensiz biçimde iletmesiyle oluşur. SQL Injection veritabanını hedeflerken, command injection doğrudan sunucu sürecini hedefler; etki çoğu zaman kritiktir. Bu yazıda CWE-78 bağlamında teori, DVWA/lab gözlemi ve güvenli kodlama odaklı korunma anlatılır.



Konuda Anlatılacaklar

Command injection nedir?


Kodlama hataları: shell=True, string birleştirme


Lab ortamı ve güvenli gözlem


Metacharacter'lar ve çıktı yorumlama


Korunma: API'ler, allowlist, least privilege


İleri seviye: argument injection, kör enjeksiyon


Kaynakça ve yasal uyarı





1) Teori

Birçok uygulama ping, traceroute, görüntü işleme, yedekleme gibi işler için dış komut çağırır. Girdi kabuğa birleşirse saldırgan ek komut zincirleyebilir.



Kod:
# Tehlikeli Python kalıbı
import os
ip = request.args["ip"]
os.system("ping -c 1 " + ip)
# ip = 127.0.0.1; id   -> kabuk ; ile ikinci komutu çalıştırabilir


Kod:
# Tehlikeli PHP kalıbı
system("ping -c 1 " . $_GET["ip"]);


OWASP Top 10 2021'de Injection (A03) ailesindedir. CWE: CWE-78 (OS Command Injection). Argument injection (CWE-88) yakından ilişkilidir: kabuk olmasa bile program argümanları kötüye kullanılabilir.



2) Lab Kurulumu

DVWA Command Injection sayfası klasik bir örnektir.



Kod:
cd DVWA && docker compose up -d
# Security: Low


Alternatif: kendi izole VM'inizde bilerek zayıf küçük bir Flask uygulaması (internete açmayın).



[center][/center]



3) Kavram Referansı



Kabuk metacharacter örnekleri (bilgi amaçlı):

Kod:
# Komut ayırıcı / zincir (Unix)
; && || |
# Yerine koyma
`...`  $(...)
# Yönlendirme
> >>


Güvenli çağrı: Kabuğu devre dışı bırakıp argüman listesi geçmek.



Kod:
import subprocess
subprocess.run(["ping", "-c", "1", ip], check=False)
# shell=False (varsayılan) — ip artık yeni komut başlatamaz
# AMA ip'nin ping'e özel zararlı argüman olup olmadığı ayrı konudur


Allowlist:

Kod:
import ipaddress
def validate_ip(s: str) -> str:
    return str(ipaddress.ip_address(s))  # geçersizse exception


4) DVWA Low: Adım Adım Gözlem

Yalnızca kendi DVWA'nızda:



Adım 1 - Normal:

Kod:
127.0.0.1
# Beklenen: ping çıktısı


Adım 2 - Zincir gözlemi (lab):

Kod:
127.0.0.1; uname -a
Low seviyede çoğu kurulumda hem ping hem uname çıktısı görünür. Bu, girdinin kabuğa gittiğinin kanıtıdır.



[center][/center]



Adım 3 - Filtreli seviyeler: Medium'da Kod:
&&
 / Kod:
;
 gibi karakterler engellenmiş olabilir. Kara liste kırılgandır (Kod:
%0a
 satır sonu vb. labda araştırılır). Impossible seviyede allowlist / güvenli API beklenir.



Kod:
# Not şablonu
Seviye: Medium
Payload: 127.0.0.1; id
Sonuç: ; silindi / komut çalışmadı / hata
Çıkarım: blacklist


Adım 4 - Çıktıyı yorumlama:Ek komut çıktısı görünüyorsa RCE etkisi vardır


Çıktı görünmese bile time-based kör enjeksiyon mümkün olabilir


Uygulama hangi OS kullanıcısı ile çalışıyor? (www-data vb.) — least privilege kritik





5) Güvenli KodlamaMümkünse hiç dış komut çağırmayın; dilin kendi kütüphanesini kullanın


Çağrı zorunluysa Kod:
subprocess
 / Kod:
execve
 argüman dizisi; Kod:
shell=True
 yasak


Girdiyi allowlist ile doğrulayın (IP, enum, sabit seçenekler)


Kullanıcı girdisini asla komut şablonuna birleştirmeyin


Uygulamayı düşük yetkili kullanıcı ile çalıştırın; container'da root'tan kaçının


Gerekli binary'lere filesystem izni sınırlayın





Kod:
# İyi: IP doğrulama + argüman listesi
import ipaddress, subprocess
ip = str(ipaddress.ip_address(user_input))
subprocess.run(["ping", "-c", "1", ip], capture_output=True, text=True, timeout=5)


Kod:
# Kötü
subprocess.run(f"ping -c 1 {user_input}", shell=True)


Kod:
# Node.js kötü
const { exec } = require("child_process");
exec("ping -c 1 " + ip);

# Daha iyi yönde: execFile / spawn ile argüman dizisi + doğrulama
const { execFile } = require("child_process");
execFile("ping", ["-c", "1", ip]);


[center][/center]



6) İleri Seviye

Argument injection: Kod:
tar
, Kod:
ffmpeg
, Kod:
sendmail
 gibi programlar Kod:
-o
 / Kod:
--
 ile başlayan girdilerde beklenmedik davranış sergileyebilir. Allowlist ve Kod:
--
 ayırıcısı düşünün.



Kod:
# Kavramsal
subprocess.run(["some-tool", "--", user_path])


Blind command injection: Çıktı sayfaya basılmaz; Kod:
sleep
 veya dışarıya DNS/HTTP callback (yalnızca kendi labınız) ile tespit edilir. Üretimde izinsiz outbound callback kullanmayın.



Şablon motorları / CI: Build script'lerine kullanıcı kontrollü alan enjekte etmek de aynı sınıftır.



Kod:
# Rapor
Bulgu: OS Command Injection (CWE-78)
Konum: /vulnerabilities/exec/ ip parametresi
Kanıt: Labda ; uname -a çıktısı
Öneri: subprocess argüman listesi + IP allowlist + düşük yetki


7) Sonuç

Command injection, kabuğa güvenilmeyen veri vermektir. Kara liste değil, güvenli API + allowlist + least privilege ile kapatılır. DVWA'da Low'da görün, Impossible'da doğru kodu okuyun.







Ek: Tespit, Loglama ve Kod İnceleme İpuçları

Mavi takım / kod inceleme perspektifinden şunlara bakın:



Kod:
# Grep ile tehlike işaretleri (kendi repo'nuz)
rg -n "os\\.system|shell=True|exec\\(|popen\\(|child_process\\.exec" .


Kod:
# Uygulama logunda (kavramsal)
{"event":"extcmd","bin":"ping","args":["-c","1","127.0.0.1"],"user":"www-data"}
# Argümanlar ayrık loglanmalı; kabuk satırı tek string olarak loglanıyorsa tasarım zayıf olabilir


WAF ve filtre yanılgısı: Kod:
;
 karakterini engellemek çözüm değildir. Base64 ile kodlanmış ikinci aşama, boşluk yerine Kod:
$IFS
 gibi varyasyonlar lab ortamlarında anlatılır; üretimde kök nedeni (güvenli API) düzeltin.



Konteyner sertleştirme:Distroless veya minimal imaj; Kod:
bash
/Kod:
curl
 yoksa etki azalır (yine de binary çalıştırma mümkün olabilir)


Read-only kök dosya sistemi + tmpfs


Capability drop, seccomp, non-root user





Kod:
# Dockerfile parçası
USER nobody
# HEALTHCHECK ve minimal paket seti


[center][/center]



Kod incelemesinde "bu girdi allowlist'ten mi geçiyor?" sorusu, "filtre yeterli mi?" sorusundan daha değerlidir.



KaynakçaOWASP Command Injection


OWASP OS Command Injection Defense


CWE-78


Python subprocess dokümantasyonu


DVWA





Yasal Uyarı

Komut enjeksiyonu testleri yalnızca kendi sistemleriniz veya yazılı izinli lab/pentest içindir. İzinsiz RCE denemesi TCK 243-245 kapsamında ağır suç olabilir. Sorumluluk uygulayana aittir.



Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).




  000-team-new-bf04ec.png (Dosya Boyutu: 67.75 KB / İndirme Sayısı: 9)



HTTP Güvenlik Başlıkları: CSP, HSTS, X-Frame-Options ve Doğru Yapılandırma Rehberi
Sun, 18 Oct 2026 19:13:18 +0300
[center]
[/center]



Selam TurkTeam, BlueTornado yazıyor.



HTTP güvenlik başlıkları, sunucunun yanıtla birlikte tarayıcıya gönderdiği "bu sayfayı nasıl korumalısın" talimatlarıdır. Başlığı koymak işin yarısıdır; asıl mesele tarayıcının o başlığı nasıl yorumladığını bilmek ve politikayı uygulamanızı bozmadan, uygulama katmanında (kod, framework, middleware) doğru kurmaktır. Bu rehberde ağırlık Content Security Policy (CSP) üzerinde: direktifler, nonce/hash, report-only modu ve ihlal raporlama. Web sunucusu tarafındaki TLS ve rate limit ayarları için forumdaki Nginx sıkılaştırma konusuna bakabilirsiniz; burada o kısmı tekrar etmiyoruz.



Konuda Anlatılacaklar

Güvenlik başlıkları nedir, tarayıcı bunları nasıl uygular?


Lab: kendi uygulamanızın başlıklarını okumak


CSP derinlemesine: direktifler ve kaynak ifadeleri


Nonce ve hash ile inline script'e güvenli izin


Report-Only modu ve ihlal raporlarının toplanması


HSTS, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy


Uygulama katmanında kurulum: Express (helmet), Django, PHP


Sık yapılan hatalar, sonuç, kaynakça ve yasal uyarı





1) Güvenlik Başlıkları Nedir?

Tarayıcı, bir yanıtı işlerken başlıkları okur ve kendi davranışını kısıtlar. Örneğin CSP, "bu sayfada yalnızca kendi alan adımdan script çalıştır" der; XSS açığı olsa bile enjekte edilen script'in çalışması engellenebilir. Başlıklar açığın kendisini kapatmaz, sömürünün etkisini azaltan ikinci savunma hattıdır (defense in depth). Girdi doğrulama ve çıktı kodlama (output encoding) yine zorunludur.



Alıntı:Kural: Başlıklar tarayıcıda uygulanır. curl veya bir bot bu kurallara uymaz; yani CSP sunucunuzu değil, kullanıcınızın tarayıcısını korur.


2) Lab: Başlıkları Okumak

Önce mevcut durumu görelim. Kendi geliştirme ortamınızda (ör. localhost:3000) çalışan uygulamanız üzerinde:



Kod:
# Yalnızca yanıt başlıklarını göster
curl -sI http://localhost:3000/

# Belirli başlıkları süz
curl -sI http://localhost:3000/ | grep -iE 'content-security|strict-transport|x-frame|x-content-type|referrer|permissions'


Çıktı yorumu: Hiçbir satır dönmüyorsa uygulamanız hiçbir güvenlik başlığı göndermiyor demektir. Tarayıcıda DevTools > Network > ilgili istek > Headers sekmesinden de aynı bilgiyi görebilirsiniz. CSP ihlalleri ise Console sekmesinde ayrıca uyarı olarak çıkar.



[center][/center]



3) Content Security Policy Derinlemesine

CSP, direktif ve kaynak listelerinden oluşan bir politikadır. Direktifler noktalı virgülle ayrılır:



Kod:
Content-Security-Policy: default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'


Temel direktifler:default-src: Ayrıca tanımlanmayan fetch direktifleri için varsayılan (script-src, style-src, img-src, connect-src, font-src vb.)


script-src: JavaScript kaynakları; XSS'e karşı en kritik direktif


style-src: CSS kaynakları


connect-src: fetch, XHR, WebSocket hedefleri


object-src 'none': Eski eklenti (object/embed) içeriğini kapatır; neredeyse her sitede önerilir


base-uri: base etiketiyle göreli URL'lerin kaçırılmasını önler


form-action: Formların hangi adreslere gönderilebileceği


frame-ancestors: Sayfanızı kimin iframe içine alabileceği (clickjacking koruması)


upgrade-insecure-requests: Sayfa içindeki http alt kaynak isteklerini https'e yükseltir





Kaynak ifadeleri: Kod:
'self'
 (aynı origin: şema + host + port), Kod:
'none'
, belirli host'lar (Kod:
https://cdn.ornek.com
), şemalar (Kod:
data:
, Kod:
https:
) ve anahtar kelimeler (Kod:
'unsafe-inline'
, Kod:
'unsafe-eval'
, Kod:
'strict-dynamic'
). 'unsafe-inline' ve 'unsafe-eval' script-src içinde CSP'nin XSS korumasını büyük ölçüde boşa çıkarır; kaçının.



Meta etiketiyle CSP: Başlık ekleyemediğiniz statik barındırmada politika HTML içine konabilir:



Kod:


Dikkat: meta etiketi ile frame-ancestors, report-uri ve sandbox desteklenmez ve politika yalnızca etiketten sonra yüklenen içeriğe uygulanır. Mümkünse HTTP başlığını tercih edin.



4) Nonce ve Hash ile Inline Script

Inline script'leri tamamen kaldırmak en temizidir. Kaldıramıyorsanız 'unsafe-inline' yerine nonce veya hash kullanın.



Nonce: Her yanıtta yeniden üretilen, tahmin edilemez rastgele bir değer. Başlıkta ve script etiketinde aynısı olmalıdır:



Kod:
Content-Security-Policy: script-src 'nonce-R4nd0mDegerHerIstekteYeni' 'strict-dynamic'; object-src 'none'; base-uri 'self'



Nonce sabit kodlanırsa veya önbelleğe alınmış sayfada tekrar kullanılırsa koruma anlamını yitirir. Kod:
'strict-dynamic'
, nonce'lu güvenilir script'in yüklediği script'lere de güvenilmesini sağlar; destekleyen tarayıcılarda host listelerini göz ardı eder. Bu yaklaşım OWASP ve web.dev tarafından önerilen "strict CSP" modelidir.



Hash: Değişmeyen inline script için içeriğin SHA-256 özeti:



Kod:
# Script içeriğinin (etiketler hariç, birebir aynı boşluklarla) hash'i
printf '%s' "initApp();" | openssl dgst -sha256 -binary | openssl base64

# Politikaya ekleme
Content-Security-Policy: script-src 'sha256-'


Script içeriğinde tek bir boşluk değişirse hash tutmaz ve tarayıcı script'i engeller; Console'daki hata mesajı genellikle beklenen hash'i de gösterir.



[center][/center]



5) Report-Only ve İhlal Raporları

Mevcut bir uygulamaya doğrudan sıkı CSP koymak genellikle bir şeyleri bozar. Doğru yol önce Content-Security-Policy-Report-Only ile gözlemlemektir: tarayıcı hiçbir şeyi engellemez, yalnızca ihlali raporlar.



Kod:
Reporting-Endpoints: csp-endpoint="https://uygulamaniz.ornek/csp-report"
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-to csp-endpoint; report-uri /csp-report
report-uri: Eski yöntem, spesifikasyonda kullanımdan kaldırılıyor ama hâlâ geniş destekli. Tarayıcı JSON gövdesini application/csp-report türüyle POST eder.


report-to: Reporting API ile yeni yöntem; uç nokta adı Reporting-Endpoints başlığında tanımlanır. Geçiş döneminde ikisini birlikte kullanmak yaygındır.





Basit bir Express toplayıcı (yalnızca kendi uygulamanız için):



Kod:
app.post('/csp-report',
  express.json({ type: ['application/csp-report', 'application/reports+json'] }),
  (req, res) => {
    console.log(JSON.stringify(req.body));   // üretimde log sistemine yazın
    res.sendStatus(204);
  });


Raporlarda violated-directive / effective-directive ve blocked-uri alanlarına bakarak hangi kaynağı politikaya eklemeniz veya koddan kaldırmanız gerektiğine karar verin. Birkaç gün temiz rapor aldıktan sonra aynı politikayı zorlayıcı başlığa taşıyın. Rapor uç noktası herkese açık olduğundan gövde boyutunu sınırlayın ve içeriğe güvenmeyin.



6) Diğer Başlıklar ve Tarayıcı Yorumu



Strict-Transport-Security (HSTS): Tarayıcı bu başlığı yalnızca HTTPS yanıtında dikkate alır; max-age süresince o alan adına http ile gitmeyi reddeder, sertifika hatasında kullanıcıya "yine de devam et" seçeneği sunmaz.

Kod:
Strict-Transport-Security: max-age=31536000; includeSubDomains
preload eklemeden önce hstspreload.org gereksinimlerini okuyun; preload listesinden çıkmak uzun sürer. Kısa max-age ile başlayıp artırmak güvenli yaklaşımdır.



X-Frame-Options: DENY veya SAMEORIGIN. ALLOW-FROM eskidir, modern tarayıcılar desteklemez. Modern karşılığı CSP frame-ancestors'tır; ikisi birlikte varsa destekleyen tarayıcılar frame-ancestors'ı esas alır. Eski tarayıcılar için ikisini birlikte göndermek zararsızdır.

Kod:
X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none'


X-Content-Type-Options: nosniff: Tarayıcının MIME türü tahmin etmesini (sniffing) kapatır; yanlış Content-Type ile gelen script/stil engellenir.



Referrer-Policy: Başka siteye geçerken URL'nin ne kadarının Referer'da gideceğini belirler. Kod:
strict-origin-when-cross-origin
 dengeli bir seçimdir; URL'de token taşıyorsanız Kod:
no-referrer
 düşünün.



Permissions-Policy: Kamera, mikrofon, konum gibi tarayıcı özelliklerini kısıtlar:

Kod:
Permissions-Policy: camera=(), microphone=(), geolocation=()


X-XSS-Protection: Eski tarayıcı filtresi içindir, modern tarayıcılarda kaldırılmıştır. OWASP, göndermemeyi veya "0" değerini önerir; XSS koruması için CSP kullanın.



[center][/center]



7) Uygulama Katmanında Kurulum



Express (helmet):

Kod:
npm install helmet


Kod:
const crypto = require('crypto');
const helmet = require('helmet');

app.use((req, res, next) => {
  res.locals.cspNonce = crypto.randomBytes(16).toString('base64');
  next();
});

app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'", (req, res) => `'nonce-${res.locals.cspNonce}'`],
      objectSrc: ["'none'"],
      baseUri: ["'self'"],
      frameAncestors: ["'none'"],
    },
  },
}));
// Şablonda: 


helmet varsayılan olarak bir dizi başlık ekler; hangi değerleri gönderdiğini kendi sürümünüzde curl -I ile mutlaka doğrulayın.



Django: SecurityMiddleware ve XFrameOptionsMiddleware ayarları settings.py'dedir. Django 6.0 ile yerleşik CSP desteği geldi (eski sürümlerde django-csp paketi kullanılır):



Kod:
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
    "django.middleware.csp.ContentSecurityPolicyMiddleware",  # Django 6.0+
    # ...
]

SECURE_HSTS_SECONDS = 31536000          # yalnızca HTTPS tamamen hazırsa
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_CONTENT_TYPE_NOSNIFF = True
SECURE_REFERRER_POLICY = "strict-origin-when-cross-origin"
X_FRAME_OPTIONS = "DENY"

from django.utils.csp import CSP
SECURE_CSP_REPORT_ONLY = {
    "default-src": [CSP.SELF],
    "script-src": [CSP.SELF, CSP.NONCE],
    "object-src": [CSP.NONE],
    "report-uri": "/csp-report/",
}


Şablonda nonce için csp context processor'ı (django.template.context_processors.csp) etkinleştirip Kod:


[center][/center]



8) Sık Yapılan Hatalarscript-src içinde 'unsafe-inline' bırakmak (nonce/hash varken destekleyen tarayıcılar onu yok sayar, ama tek başına korumayı boşa çıkarır)


Aynı başlığı hem uygulamada hem ters vekilde farklı değerlerle eklemek; birden fazla CSP başlığında tarayıcı hepsini birden uygular, sonuç beklenenden sıkı olur


Nonce'u sabit yazmak veya tam sayfa önbelleğinde kullanıcılar arasında paylaştırmak


Report-Only'de kalıp politikayı hiç zorlayıcı moda almamak


HTTPS hazır değilken uzun max-age ile HSTS ya da preload göndermek


CDN alan adının tamamına izin vermek (ör. tüm bir paylaşımlı CDN); saldırgan aynı CDN'e dosya koyabiliyorsa politika aşılabilir





9) Sonuç

Güvenlik başlıkları ucuz ama güçlü bir katmandır. Sıralama önerim: önce nosniff, Referrer-Policy ve frame koruması; ardından CSP'yi Report-Only ile başlatıp raporlarla olgunlaştırmak; en son nonce tabanlı strict CSP'yi zorlamak. Politikanızı Google'ın CSP Evaluator aracıyla gözden geçirip her sürümde curl -I ile doğrulayın.



KaynakçaMDN - Content Security Policy (CSP)


MDN - Content-Security-Policy başlık referansı


W3C - Content Security Policy Level 3


OWASP CSP Cheat Sheet


OWASP HTTP Security Response Headers Cheat Sheet


OWASP Secure Headers Project


RFC 6797 - HTTP Strict Transport Security


RFC 7034 - X-Frame-Options


Helmet.js dokümantasyonu


Django - Content Security Policy


web.dev - Strict CSP


Google CSP Evaluator





Yasal Uyarı

Bu rehber kendi uygulamalarınızı korumak içindir. Başlık ve politika testlerini yalnızca kendi sistemlerinizde veya yazılı yetkili pentest kapsamında yapın. Başkasına ait sistemlere izinsiz erişim veya müdahale TCK 243-245 ve ilgili maddeler kapsamında suç olabilir. Eğitim amaçlıdır.



Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).




  000-team-new-3ddc97.png (Dosya Boyutu: 71.82 KB / İndirme Sayısı: 7)



Dosya Yükleme File Upload Açıkları ve Güvenli Doğrulama Rehberi
Sun, 18 Oct 2026 11:45:10 +0300
[center]
[/center]



Selam TurkTeam, BlueTornado ile devam.



Dosya yükleme özelliği; profil fotoğrafı, ek, CV, fatura gibi meşru ihtiyaçlar için vardır. Yanlış uygulanırsa webshell yükleme, XSS (SVG/HTML), path traversal, depolama tüketimi (DoS) ve sunucu tarafı parse açıklarına yol açar. Bu rehber güvenli doğrulama odaklıdır; örnekler DVWA ve kendi labınız içindir.



Konuda Anlatılacaklar

File upload riskleri nelerdir?


DVWA File Upload labı


Tehlikeli doğrulama hataları


Savunma katmanları: tip, içerik, depolama, sunum


Uygulamalı güvenli tasarım


İleri seviye: SVG, zip slip, malware tarama


Kaynakça ve yasal uyarı





1) RisklerUzaktan kod çalıştırma: Kod:
.php
, Kod:
.jsp
, Kod:
.aspx
 webshell'in web köküne yazılması


XSS: Kod:
.html
 / Kod:
.svg
 dosyasının aynı origin'den sunulması


Path traversal: Kod:
../../var/www/shell.php
 dosya adı


Overwrite: mevcut kritik dosyanın üzerine yazma


Zip Slip: arşiv açarken dizin kaçışı


DoS: çok büyük dosya, zip bomb





OWASP WSTG içinde "Testing for Uploaded File Attacks" bölümü bu aileyi kapsar. CWE örnekleri: CWE-434 (Unrestricted Upload of File with Dangerous Type).



2) Lab: DVWA File Upload

Kod:
docker compose -f DVWA/docker-compose.yml up -d
# Security Low -> File Upload


Low seviyede çoğu kurulum yalnızca istemci tarafı veya basit uzantı kontrolü yapar. Impossible seviyede içerik tipi ve depolama sertleştirmesi vardır.



[center][/center]



Gözlem adımları (lab):

Kod:
# 1) Küçük bir PNG yükleyin, yükleme yolunu not alın
# 2) Uzantı / Content-Type oyunlarını lab politikasına göre gözlemleyin
# 3) Impossible ile farkı karşılaştırın


Webshell yüklemeyi üretimde veya izinsiz sistemlerde denemeyin. Labda bile yüklediğiniz dosyaları işiniz bitince silin.



3) Yaygın Hatalı Kontroller



Sadece istemci tarafı:

Kod:



Sadece uzantı kara listesi:

Kod:
# .php engelli ama .php5 .phtml .phar .jpg.php ?
# Sunucu yapılandırmasına bağlı


Sadece Content-Type başlığı:

Kod:
Content-Type: image/png
# İstemci istediğini yazar; güvenilmez


MIME sniffing/Kod:
file
 komutu tek başına: Polyglot dosyalar (hem geçerli görüntü hem script) tarih boyunca görülmüştür; yine de sunucu tarafı MIME tahmini + uzantı allowlist birlikte kullanılmalıdır.



4) Güvenli Doğrulama Katmanları



1 - Allowlist: Yalnızca iş ihtiyacı olan uzantılar (Kod:
jpg jpeg png webp pdf
).



2 - Rastgele dosya adı: Kullanıcı adını kullanmayın.



Kod:
import uuid
from pathlib import PurePosixPath
ext = PurePosixPath(filename).suffix.lower()
if ext not in {".jpg", ".jpeg", ".png", ".webp"}:
    raise ValueError("uzantı yok")
stored = f"{uuid.uuid4().hex}{ext}"


3 - İçerik doğrulama:

Kod:
from PIL import Image
img = Image.open(upload_stream)
img.verify()  # bozuk/şüpheli dosyayı ele
# Yeniden encode ederek metadata/polyglot riskini azaltın
Image.open(upload_stream).save(out_path, format="JPEG")


4 - Depolama konumu: Dosyaları web kökü dışına veya yalnızca statik object storage'a koyun. Uygulama sunucusunun yorumladığı dizine yazmayın.



5 - Sunum:

Kod:
# İndirme için
Content-Disposition: attachment; filename="rapor.pdf"
X-Content-Type-Options: nosniff
Content-Type: application/pdf
SVG/HTML'i aynı origin'de inline açmayın; mümkünse ayrı domain (static.example) kullanın.



6 - Boyut ve hız sınırı:

Kod:
# Nginx örneği
client_max_body_size 5m;


[center][/center]



5) Uygulamalı Güvenli İskelet

Kod:
# Flask kavramsal özet
ALLOWED = {"jpg", "jpeg", "png"}
MAX = 5 * 1024 * 1024

def save_avatar(file_storage):
    if file_storage.content_length and file_storage.content_length > MAX:
        abort(400)
    name = file_storage.filename or ""
    ext = name.rsplit(".", 1)[-1].lower()
    if ext not in ALLOWED:
        abort(400)
    # PIL verify + re-encode
    # kaydet: /var/app/uploads/{uuid}.jpg  (web root dışı)
    # sun: imza/lı URL veya ayrı static host


Kod:
# PHP move_uploaded_file + finfo allowlist (kavramsal)
$finfo = new finfo(FILEINFO_MIME_TYPE);
$mime = $finfo->file($_FILES['u']['tmp_name']);
$allowed = ['image/jpeg' => 'jpg', 'image/png' => 'png'];
if (!isset($allowed[$mime])) { http_response_code(400); exit; }


6) İleri Seviye

SVG: İçinde JavaScript / external entity olabilir. Avatar için SVG kabul etmeyin veya sıkı sanitizer + ayrı domain kullanın.



Zip Slip:

Kod:
# Tehlikeli arşiv girdileri
../../../../tmp/evil
# Açarken final path'in hedef dizin altında kaldığını doğrulayın


Malware tarama: ClamAV vb. ile async tarama; temizlenmeden public yapmayın.



ImageMagick / parse CVE'leri: Görüntü işleme kütüphanelerini güncel tutun; policy.xml ile coder'ları kısıtlayın. İcat CVE numarası yazmayın; NVD'den doğrulayın.



Kod:
# Rapor dili
Bulgu: Unrestricted File Upload (CWE-434)
Kanıt: Labda tehlikeli tipin web köküne yazılması
Öneri: allowlist + re-encode + web root dışı + nosniff


[center][/center]



7) Sonuç

Dosya yükleme, "uzantıya bakmak"tan ibaret değildir. Allowlist, içerik doğrulama, güvenli depolama ve güvenli sunum birlikte gerekir. DVWA Low/Impossible farkını inceleyerek kendi uygulamanızın kontrol listesini çıkarın.







Ek: Operasyonel Kontrol Listesi ve Yaygın Senaryolar

Profil fotoğrafı: Yalnızca raster; yeniden encode; sabit max boyut (ör. 1024px); EXIF temizliği (konum sızıntısı).



Kod:
# ImageMagick (güncel sürüm + policy) ile yeniden örnekleme kavramı
# convert input.jpg -resize 1024x1024> -strip out.jpg


PDF yükleme: PDF içinde JavaScript / form aksiyonları olabilir. Inline göstermek yerine Kod:
Content-Disposition: attachment
 veya güvenilir bir önizleme servisi kullanın.



Çok parçalı / chunked upload: Her parçayı ayrı doğrulayın; birleştirme sonrası tekrar MIME/uzantı kontrolü yapın; geçici dosyaları güvenli dizinde tutun.



Kod:
# S3 / MinIO politikası kavramı
# public-read vermeyin; pre-signed URL ile süreli erişim
# bucket'ta website hosting açıkken html/svg yüklemeyin


CI kontrolü: Yükleme ile ilgili birim testleri: path traversal dosya adı reddi, aşırı boyut reddi, yanlış MIME reddi, başarılı PNG yolu.



[center][/center]



Yükleme özelliği ürün için vazgeçilmezse, güvenlik bütçesini "sonra bakarız"a bırakmayın; tasarım aşamasında depolama ve sunum kararlarını kilitleyin.



KaynakçaOWASP Unrestricted File Upload


OWASP File Upload Cheat Sheet


WSTG - Malicious File Upload


CWE-434


DVWA





Yasal Uyarı

Zararlı dosya yükleme ve webshell denemeleri yalnızca kendi labınızda veya yazılı yetki ile yapılmalıdır. İzinsiz yükleme TCK 243-245 kapsamında suçtur. Eğitim amaçlıdır; sorumluluk uygulayana aittir.



Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).




  000-team-new-1bf799.png (Dosya Boyutu: 67.49 KB / İndirme Sayısı: 8)



API Güvenliği ve OWASP API Top 10: BOLA BFLA ve Temel Kontroller
Sun, 18 Oct 2026 11:12:18 +0300
[center]
[/center]



Selam millet, BlueTornado yazıyor.



Modern uygulamaların yüzeyi çoğu zaman HTML formlarından çok JSON API'lerdir. OWASP API Security Top 10, bu yüzeyi hedefleyen riskleri listeler. Bu rehberde 2023 sürümüne odaklanarak özellikle BOLA ve BFLA'yı, labda test yaklaşımını ve savunma kontrollerini anlatıyoruz. İcat istatistik veya uydurma CVE yok; resmi OWASP dokümanına bağlı kalıyoruz.



Konuda Anlatılacaklar

API güvenliği neden ayrı ele alınır?


OWASP API Top 10 2023 özeti


BOLA (object) ve BFLA (function) derinlemesine


Lab: basit API ile A/B hesap testi


Korunma: authn/authz, rate limit, şema


İleri seviye: GraphQL, mass assignment, envanter


Kaynakça ve yasal uyarı





1) API Güvenliği Nedir?

API'ler makine-okur, otomasyona açıktır, mobil/SPA/partner entegrasyonlarını besler. UI'da gizlenen bir düğme API'de hâlâ duruyor olabilir. Kimlik doğrulama (authentication) ile yetkilendirme (authorization) karıştırılmamalıdır: "Token var" yetki demek değildir.



2) OWASP API Top 10 2023 Özeti

Resmi liste (kısa Türkçe karşılıklarıyla):API1:2023 Broken Object Level Authorization (BOLA)


API2:2023 Broken Authentication


API3:2023 Broken Object Property Level Authorization


API4:2023 Unrestricted Resource Consumption


API5:2023 Broken Function Level Authorization (BFLA)


API6:2023 Unrestricted Access to Sensitive Business Flows


API7:2023 Server Side Request Forgery


API8:2023 Security Misconfiguration


API9:2023 Improper Inventory Management


API10:2023 Unsafe Consumption of APIs





Detay için OWASP API Security Project sayfasına bakın. Sürüm yılını raporlarınızda belirtin.



[center][/center]



3) BOLA Nedir?

Broken Object Level Authorization, web'deki IDOR'un API dilindeki adıdır. Kullanıcı, erişmemesi gereken nesneye kimlik (id) ile ulaşır.



Kod:
# Tehlikeli
GET /api/v1/users/214/orders
# Authorization yalnızca "login oldu mu?" seviyesinde


Kod:
# Doğru yön
order = repo.get(order_id)
if order.owner_id != current_user.id:
    raise Forbidden()


4) BFLA Nedir?

Broken Function Level Authorization, işlev düzeyinde yetki eksikliğidir. Özellikle admin uçlarının gizlenerek "güvende" sanılması.



Kod:
DELETE /api/v1/admin/users/214
POST /api/v1/admin/settings/maintenance
# UI'da admin menüsü yok ama endpoint açık


Kod:
# Rol kontrolü
if "admin" not in current_user.roles:
    raise Forbidden()


BOLA nesne sahipliğine, BFLA ise role/işleve bakar; ikisi birlikte test edilmelidir.



5) Lab: Mini API Testi

Kendi bilgisayarınızda iki kullanıcı oluşturabileceğiniz bir lab API'si kullanın (Juice Shop API, crAPI, veya kendi Flask iskeletiniz).



Kod:
# A kullanıcısı token
TOKEN_A=...
TOKEN_B=...

# A kendi kaynağını okur
curl -s -H "Authorization: Bearer $TOKEN_A" http://127.0.0.1:8000/api/orders/1

# A, B'nin order id'sini dener
curl -s -o /tmp/out -w "%{http_code}" -H "Authorization: Bearer $TOKEN_A" \
  http://127.0.0.1:8000/api/orders/2
# 403/404 beklenir; 200 + B verisi = BOLA


Kod:
# BFLA denemesi
curl -s -o /tmp/out -w "%{http_code}" -H "Authorization: Bearer $TOKEN_A" \
  -X DELETE http://127.0.0.1:8000/api/admin/users/2
# 403 beklenir


[center][/center]



6) Kavram Referansı ve Korunma



Object property level (API3): Kullanıcı nesneyi görebilir ama Kod:
is_admin
, Kod:
salary
 alanlarını okuyamamalı / yazamamalıdır (mass assignment ile bağlantılı).



Kod:
# Allowlist serialize
return {"id": o.id, "item": o.item, "status": o.status}
# role, internal_notes yok


Resource consumption (API4): Rate limit, pagination tavanı, max page size, maliyetli aramalar için kota.



Kod:
# Örnek (nginx / API gateway)
limit_req_zone $binary_remote_addr zone=api:10m rate=5r/s;


Inventory (API9): Eski Kod:
/v1
 unutulmuş, shadow API, document edilmemiş debug uçları. OpenAPI envanteri tutun; gateway'de yalnızca bilinen route'ları açın.



Kod:
# OpenAPI'de tanımlı olmayan yolu reddet (gateway politikası)


Authn (API2): Credential stuffing'e karşı rate limit + MFA; JWT için bir önceki konudaki kurallar.



7) Uygulamalı Kontrol ListesiHer endpoint için: kim çağırabilir, hangi nesneler?


A/B hesap otomasyon testi CI'da


Admin prefix'leri ayrı authz middleware


Response'ta fazla alan sızıntısı var mı?


Rate limit ve payload size limit


WAF/gateway + uygulama içi kontrol (defense in depth)


Log: authz deny olayları





Kod:
# Pseudo test
def test_bola_forbidden(client, user_a, order_of_b):
    r = client.get(f"/api/orders/{order_of_b.id}", headers=auth(user_a))
    assert r.status_code in (403, 404)


[center][/center]



8) İleri Seviye

GraphQL: Tek endpoint; field-level authz, query depth/cost limit, introspection'ı production'da kapatma.



BFLA keşfi: OpenAPI / JS bundle içinde Kod:
/admin
, Kod:
role
, Kod:
internal
 string araması (kendi uygulamanız).



Unsafe consumption (API10): Üçüncü parti API yanıtına güvenerek komut/SQL birleştirmeyin; şema doğrulayın.



Kod:
# Rapor
Bulgu: BOLA (API1:2023) / CWE-639
Endpoint: GET /api/orders/{id}
Kanıt: Kullanıcı A, B siparişini 200 ile okudu
Öneri: object-level authz + otomatik test


9) Sonuç

API güvenliği, UI güvenlik varsayımlarını taşımaz. BOLA ve BFLA en sık atlanan yetki hatalarıdır; rate limit, şema ve envanter ile tamamlayın. OWASP API Top 10'u ekip içinde ortak dil yapın.







Ek: Partner API ve Versiyonlama Notları

Dışarıya açılan partner API'lerinde ek olarak:İstemci kimliği başına ayrı kimlik bilgisi ve scope


IP allowlist (mümkünse) + mTLS (yüksek güvenlikli B2B)


Değişiklik yönetimi: breaking change için yeni versiyon


Eski versiyonun kapatılma tarihi (inventory ile bağlantılı)





Kod:
# Scope örneği
Authorization: Bearer ...
# token içinde scope: "orders:read"
# orders:write gerektiren endpoint'te reddedin


Kod:
# Sayfalama tavanı
GET /api/orders?limit=1000  -> 400 Bad Request (max 50)


[center][/center]



API Top 10 maddelerini sprint Definition of Done listesine tek satırlık kontroller olarak eklemek, "sonra bakarız" riskini azaltır.



KaynakçaOWASP API Security Top 10 2023


API1 BOLA


API5 BFLA


OWASP REST Security Cheat Sheet


CWE-285 Improper Authorization





Yasal Uyarı

API testleri yalnızca kendi sistemleriniz veya yazılı pentest yetkisi kapsamında yapılmalıdır. İzinsiz API tarama ve veri erişimi TCK 243-245 kapsamında suç olabilir. Eğitim amaçlıdır.



Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).




  000-team-new-de9d96.png (Dosya Boyutu: 64.92 KB / İndirme Sayısı: 7)



JWT ve Oturum Güvenliği: Yaygın Hatalar ve Doğru Kullanım Rehberi
Sun, 18 Oct 2026 11:08:37 +0300
[center]
[/center]



Selam TurkTeam, BlueTornado burada.



JWT (JSON Web Token), iddia (claim) taşımak için yaygın bir formattır; "otomatik olarak güvenli oturum çözümü" değildir. Yanlış kullanıldığında alg:none, zayıf imza, uzun ömürlü token, secret sızıntısı gibi hatalar ortaya çıkar. Bu rehberde JWT yapısı, klasik oturum çerezi ile farkı, yaygın hatalar ve savunmacı doğru kullanım anlatılır.



Konuda Anlatılacaklar

JWT nedir, ne işe yarar?


Oturum çerezi ile karşılaştırma


Lab: token üretme ve inceleme


Yaygın hatalar (alg, secret, saklama)


Doğru kullanım: imza, süre, yenileme, iptal


İleri seviye: JWE, key rotation, browser saklama


Kaynakça ve yasal uyarı





1) JWT Nedir?

JWT genellikle üç Base64URL parçasından oluşur: header.payload.signature



Kod:
# Örnek yapı (sahte / eğitim)
header = {"alg":"HS256","typ":"JWT"}
payload = {"sub":"123","role":"user","exp":1735689600}
Header: algoritma ve tip


Payload: claim'ler (sub, exp, iss, aud, özel alanlar)


Signature: bütünlük; gizli anahtar veya özel anahtar ile





Payload varsayılan olarak şifreli değildir; Base64 decode herkes yapar. Gizlilik için TLS şarttır; ek gizlilik gerekirse JWE düşünülür.



Alıntı:JWT'yi "encrypt" sanmak yaygın hatadır. İmza bütünlük sağlar; içeriği gizlemez.


2) Klasik Oturum ile FarkSunucu oturumu: Çerezde rastgele session id; veri sunucuda. İptal kolay (store'dan sil).


Stateless JWT: Veri token içinde; ölçeklenmesi kolay, iptal zor (blacklist/ kısa ömür gerekir).





İkisi de doğru tasarlanırsa güvenli olabilir. Çoğu web uygulaması için HttpOnly Secure SameSite çerez + sunucu oturumu hâlâ sağlam bir seçimdir. JWT özellikle API'ler, mikroservisler ve mobil istemcilerde tercih edilir.



3) Lab: Token İnceleme

Kod:
# Python ile imzalı token (lab secret - üretime koymayın)
pip install pyjwt
python3 - <<'PY'
import jwt, datetime
key = "lab-only-change-me"
payload = {
  "sub": "42",
  "role": "user",
  "exp": datetime.datetime.utcnow() + datetime.timedelta(minutes=15),
  "iat": datetime.datetime.utcnow(),
  "iss": "turkteam-lab",
}
token = jwt.encode(payload, key, algorithm="HS256")
print(token)
print(jwt.decode(token, key, algorithms=["HS256"], issuer="turkteam-lab"))
PY


Kod:
# Parçaları görmek (imza doğrulaması değil!)
python3 - <<'PY'
import base64, json
t = input().strip().split('.')
for part in t[:2]:
    pad = '=' * (-len(part) % 4)
    print(json.loads(base64.urlsafe_b64decode(part + pad)))
PY


[center][/center]



4) Yaygın Hatalar



alg:none veya algoritma karışıklığı:

Kod:
# Kütüphane "alg" header'ına körü körüne güvenmemeli
# Doğrulamada algoritmayı allowlist ile sabitleyin
jwt.decode(token, key, algorithms=["HS256"])  # algorithms zorunlu
Eski kütüphane hatalarında saldırgan Kod:
alg
'ı none veya HS256'ya çevirip RSA public key ile imza atlatmayı denemişti. Güncel kütüphane + sabit algorithms kullanın.



Zayıf / sızmış secret:

Kod:
# Kötü
secret = "secret"
# İyi: uzun, rastgele, ortam değişkeni / KMS
# openssl rand -base64 48


exp yok veya çok uzun: Yıllarca geçerli access token çalınırsa uzun süre geçerlidir.



Hassas veri payload'da: TCKN, parola hash'i, kart numarası koymayın.



localStorage'da access token: XSS ile çalınır. Mümkünse Secure HttpOnly çerez; XSS'i de kapatın.



Imza doğrulamadan claim okumak:

Kod:
# YANLIŞ
payload = jwt.decode(token, options={"verify_signature": False})


[center][/center]



5) Doğru Kullanım PratikleriAccess token kısa ömürlü (dakikalar); refresh token uzun, sıkı saklı, rotate edilebilir


Kod:
iss
, Kod:
aud
, Kod:
exp
, Kod:
nbf
 doğrulayın


HS256 için güçlü secret; asimetrik için RS256/ES256 ve JWKS


Rol/yetki değişince eski token'lara güvenmeyin (kısa TTL veya sürüm claim'i)


Logout: refresh iptali + çerez silme; saf stateless'ta kısa TTL şart


TLS zorunlu; token'ı URL query'de taşımayın (loglara düşer)





Kod:
# Doğrulama örneği
jwt.decode(
  token,
  key,
  algorithms=["HS256"],
  issuer="turkteam-lab",
  audience="turkteam-api",
  options={"require": ["exp", "iss", "aud", "sub"]},
)


Kod:
# Refresh rotate (kavramsal)
# Her kullanımda yeni refresh üret, eskisini revoke et
# Çalınan refresh replay edilirse aile (family) iptali


6) Oturum Çerezi Sertleştirme (JWT kullanmasanız bile)

Kod:
Set-Cookie: session=...; Path=/; Secure; HttpOnly; SameSite=Lax; Priority=High
Session fixation: login sonrası id yenile


Idle / absolute timeout


Concurrent session politikası (isteğe bağlı)





7) İleri Seviye

JWKS ve key rotation: Kod:
kid
 header ile anahtar seçimi; eski kid kısa süre doğrulanmaya devam edebilir.



Kod:
GET /.well-known/jwks.json


JWE: Token içeriğini şifrelemek gerektiğinde. Karmaşıklık artar; çoğu API için TLS + minimal claim yeterlidir.



Service-to-service: Kullanıcı JWT'sini körü körüne iletmeyin; audience daraltın, impersonation claim'lerini dikkatli tasarlayın.



Kod:
# Rapor dili
Bulgu: JWT imza doğrulamasında algoritma sabitlenmemiş
Risk: Algorithm confusion / alg none sınıfı hatalara açıklık
Öneri: algorithms allowlist + güçlü anahtar + kısa exp


[center][/center]



8) Sonuç

JWT güçlü bir formattır; güvenlik tasarımında detaylarda gizlidir. İmza algoritmasını sabitleyin, süreyi kısa tutun, saklamayı XSS'e karşı düşünün, claim'leri doğrulayın. Gerekmiyorsa sunucu oturumu ile de ilerleyebilirsiniz.







Ek: Tarayıcı Saklama Karar AğacıBirinci taraf web uygulaması: mümkünse sunucu oturumu veya refresh'i HttpOnly çerezde tutun


Access token bellekte (memory) kısa ömürlü tutulabilir; sayfa yenilenince refresh ile yenilenir


localStorage/sessionStorage: XSS yüzeyi geniş; yalnızca risk kabulü ile


Mobil uygulama: OS güvenli depolama (Keychain / Keystore)





Kod:
# Nginx ile çerez örneği (uygulama Set-Cookie üretiyorsa)
# proxy_cookie_flags ~ secure httponly samesite=lax;


Test kontrol listesi:

Kod:
[ ] algorithms parametresi sabit mi?
[ ] exp / iss / aud doğrulanıyor mu?
[ ] Secret git'te yok mu?
[ ] Access TTL kısa mı?
[ ] Refresh rotate / revoke var mı?
[ ] Token URL'de taşınmıyor mu?
[ ] Logout sonrası refresh geçersiz mi?


[center][/center]



KaynakçaRFC 7519 - JWT


OWASP JWT Cheat Sheet


OWASP Session Management Cheat Sheet


JWT BCP tartışmaları / best practices (Auth0 özeti, RFC 8725 ile birlikte okuyun)


RFC 8725 - JWT Best Current Practices


PyJWT Documentation





Yasal Uyarı

Token üretme/kırma denemeleri yalnızca kendi labınızda veya yazılı yetki ile yapılmalıdır. Başkalarının oturum token'larını ele geçirmek veya kullanmak TCK 243-245 kapsamında suç olabilir. Eğitim amaçlıdır.



Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).




  000-team-new-ceebc8.png (Dosya Boyutu: 62.82 KB / İndirme Sayısı: 6)



CSRF Cross-Site Request Forgery Nedir? Tespit ve Korunma Rehberi
Sun, 18 Oct 2026 11:05:08 +0300
[center]
[/center]



Selam TurkTeam, BlueTornado yazıyor.



CSRF (Cross-Site Request Forgery), kimliği doğrulanmış bir kullanıcının tarayıcısını kandırarak, kullanıcının haberi olmadan siteye istek attırmaktır. XSS "saldırganın script'ini kurbanın tarayıcısında çalıştırır"; CSRF ise kurbanın mevcut oturumunu kullanarak istenmeyen bir eylemi tetikler. Bu rehberde teori, lab gözlemi, token/SameSite korunmaları ve modern API'lerdeki durumu inceliyoruz.



Konuda Anlatılacaklar

CSRF nedir, hangi koşullarda çalışır?


XSS ile farkı


Lab: DVWA CSRF sayfası


Klasik PoC formu ve cookie davranışı


Korunma: Anti-CSRF token, SameSite, pratikler


İleri seviye: JSON API, SameSite=None, login CSRF


Kaynakça ve yasal uyarı





1) CSRF Nedir?

Tarayıcılar, bir siteye istek atarken o siteye ait çerezleri (oturum çerezi dahil) varsayılan kurallara göre ekler. Saldırgan, kötü amaçlı bir sayfada şu tür bir istek tetiklerse:



Kod:


  
  



Kurban o anda bank.example oturumu açıksa, tarayıcı çerezi ekleyebilir ve transfer isteği "kurbandan gelmiş" gibi görünür. Sunucu, isteğin kullanıcının isteyerek mi yoksa başka siteden mi geldiğini ayırt edemiyorsa CSRF oluşur.



Gerekli koşullar (özet):İlgili sitede geçerli oturum (çerez tabanlı)


Tarayıcının çerezi o isteğe eklemesi


Sunucuda istek sahteciliğini engelleyen ek doğrulama olmaması


Değiştirici (state-changing) bir eylem (POST ile para transferi, e-posta değiştirme vb.)





Alıntı:CSRF, "çerezi çalmak" zorunda değildir. Çerez tarayıcıda kalır; saldırgan sadece isteği tetikler.


2) XSS ile FarkXSS: Güvenilmeyen verinin sayfada script olarak çalışması


CSRF: Güvenilen sitenin state-changing endpoint'ine çapraz siteden istek


XSS varsa çoğu CSRF koruması da aşılabilir (token okunur); ikisi ayrı ayrı kapatılmalıdır





3) Lab: DVWA CSRF

Kod:
git clone https://github.com/digininja/DVWA.git
cd DVWA
docker compose up -d


DVWA menüsünden CSRF sayfasına gidin. Low seviyede parola değiştirme formu genelde anti-CSRF tokensızdır.



[center][/center]



Adım 1: Normal şekilde parolayı değiştirip isteği DevTools/Burp ile inceleyin.



Kod:
POST /vulnerabilities/csrf/
password_new=...&password_conf=...&Change=Change
Cookie: PHPSESSID=...; security=low


Adım 2: Aynı parametrelerle, labınızda yerel bir HTML dosyasından formu işaret ederek davranışı gözlemleyin (yalnızca 127.0.0.1 DVWA). Impossible seviyede token eklenmiş olduğunu göreceksiniz.



Kod:







Çıktı yorumu: Low'da oturum açıkken bu sayfa yüklendiğinde parola değişiyorsa CSRF vardır. Impossible'da token eksik/yanlışsa işlem reddedilir.



[center][/center]



4) Kavram Referansı



Anti-CSRF synchronizer token: Sunucu, forma rastgele token koyar; POST'ta token oturumdaki ile eşleşmelidir. Saldırganın sitesi bu token'ı okuyamaz (same-origin policy), XSS yoksa.



Kod:



Kod:
# Sunucu tarafı (kavramsal)
if not hmac.compare_digest(session["csrf"], request.form["csrf_token"]):
    abort(403)


SameSite çerez özelliği:

Kod:
Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax
Kod:
Strict
: Çapraz site isteklerinde çerez gönderilmez (en sıkı; bazı akışları bozabilir)


Kod:
Lax
: Top-level GET navigasyonunda gönderilir; çoğu CSRF POST senaryosunu keser


Kod:
None
: Secure zorunlu; çapraz site çerez (dikkatli kullanın)





Origin / Referer kontrolü: Ek katman; Referer eksik olabilir, Origin daha güvenilirdir ama her istemci/senaryoda yetmeyebilir. Token ile birlikte düşünün.



Kod:
# Örnek kontrol (kavramsal)
origin = request.headers.get("Origin")
if origin and origin not in ALLOWED_ORIGINS:
    abort(403)


5) Korunma Kontrol ListesiState-changing işlemleri POST/PUT/DELETE ile yapın; önemli işleri GET'e bağlamayın


Anti-CSRF token (framework'ün built-in'i: Django, Rails, ASP.NET, Spring)


SameSite=Lax veya Strict + Secure + HttpOnly


Mümkünse oturumu çerez dışında authorization header (Bearer) ile taşıyan SPA'larda CSRF yüzeyi küçülür; XSS'e dikkat


Kritik işlemlerde re-auth (şifre yeniden sor)


CORS'u sıkı tutun; credentials ile * kullanmayın





Kod:
# Django'da middleware varsayılan olarak CSRF korur
# Şablon:
{% csrf_token %}


Kod:
# Flask-WTF örneği
form = FlaskForm()  # csrf_token alanı otomatik


[center][/center]



6) İleri Seviye

Login CSRF: Kurbanı saldırganın hesabına zorla giriş yaptırma; sonra kurban o oturuma veri kaydeder. Login formuna da token koyun.



JSON API + simple request: Kod:
Content-Type: application/json
 olan istekler tarayıcıda CORS preflight tetikleyebilir; yine de cookie tabanlı oturumda doğru CORS/CSRF tasarımı şarttır.



SameSite=None gereken üçüncü parti gömülü senaryolarda CSRF riski geri gelir; ek token zorunlu düşünün.



Double-submit cookie: Token'ı hem çerezde hem formda göndermek. Basit ama subdomain XSS/cookie injection varsa zayıflayabilir; synchronizer pattern genelde tercih edilir.



Kod:
# Rapor dili
Bulgu: CSRF (CWE-352)
Endpoint: POST /vulnerabilities/csrf/
Kanıt: Labda tokensız POST ile parola değişimi
Öneri: synchronizer token + SameSite=Lax


7) Sonuç

CSRF, tarayıcının çerez ekleme davranışından beslenir. Token + SameSite + güvenli metod kullanımı temel üçlüdür. DVWA Low/Impossible karşılaştırması korumayı somut gösterir.







Ek: Framework Notları ve Test Kontrol Listesi

Modern çerçeveler CSRF için hazır çözüm sunar; asıl risk "korumayı kapatmak"tır.



Kod:
# Django: CSRF_TRUSTED_ORIGINS doğru ayarlanmalı (HTTPS arkasında)
# @csrf_exempt yalnızca çok bilinçli istisnalarda; API için token veya auth tasarımını gözden geçirin


Kod:
# ASP.NET Core: Antiforgery middleware
# ValidateAntiForgeryToken attribute


Kod:
# SPA + cookie oturumu:
# 1) Frontend, login yanıtından veya cookie-olmayan bir endpoint'ten CSRF token alsın
# 2) Her state-changing istekte header olarak göndersin (ör. X-CSRF-Token)
# 3) SameSite=Lax + Secure


Manuel test listesi (izinli lab):Oturum açıkken çapraz origin HTML formu ile POST deneyin


Token'ı silerek/değiştirerek 403 bekleyin


Content-Type ve metod kombinasyonlarını not edin


Logout sonrası token'ın geçersiz olduğunu doğrulayın





[center][/center]



Unutmayın: CSRF koruması XSS varken zayıflar çünkü script token'ı okuyabilir. İkisini birlikte ele alın.



KaynakçaOWASP CSRF


OWASP CSRF Prevention Cheat Sheet


MDN SameSite


CWE-352


DVWA





Yasal Uyarı

CSRF testleri yalnızca kendi labınızda veya yazılı yetkili pentest kapsamında yapılmalıdır. Başkalarının oturumunu kötüye kullanmak TCK 243-245 ve ilgili maddeler kapsamında suç olabilir. Eğitim amaçlıdır.



Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).




  000-team-new-293496.png (Dosya Boyutu: 67.17 KB / İndirme Sayısı: 9)



SQL Injection Sıfırdan: DVWA ile Uygulamalı Rehber (Yasal Lab)
Sat, 17 Oct 2026 18:03:12 +0300
[center]
[/center]



Selam TurkTeam, BlueTornado ile devam.



SQL Injection (SQLi), uygulamanın SQL sorgusunu kullanıcı girdisiyle güvensiz biçimde birleştirmesi sonucu ortaya çıkan klasik bir enjeksiyon zafiyetidir. Bu rehberde sıfırdan teori, DVWA üzerinde Low/Medium/Impossible karşılaştırması, parametreli sorgular ve modern ORM hatalarını ele alıyoruz. Tüm örnekler yalnızca yerel lab içindir.



Konuda Anlatılacaklar

SQL Injection nedir, hangi riskleri taşır?


DVWA lab kurulumu


Kavramlar: union, boolean, error-based, blind


Low seviyede adım adım gözlem


Medium filtre ve prepared statement'a geçiş


Korunma: parametreli sorgu, ORM, least privilege


İleri seviye: second-order, WAF yanılsaması


Kaynakça ve yasal uyarı





1) SQL Injection Nedir?

Veritabanı, uygulamanın gönderdiği SQL metnini yorumlar. Saldırgan, girdi alanına SQL sözdizimi parçaları ekleyerek sorgunun mantığını değiştirebiliyorsa injection vardır.



Kod:
# Tehlikeli kalıp (kavramsal)
id = request.GET["id"]
sql = "SELECT first_name, last_name FROM users WHERE user_id = '" + id + "'"
# id = 1' OR '1'='1  olduğunda mantık bozulur


Olası etkiler: kimlik doğrulamayı atlama, veri okuma/değiştirme, bazı DB/konfigürasyonlarda OS komutuna giden yollar (ör. xp_cmdshell gibi özellikler açıksa). Etki, DB kullanıcısının yetkisine ve uygulama mimarisine bağlıdır.



OWASP Top 10 2021'de Injection A03:2021 altındadır. CWE karşılığı başlıca CWE-89'dur.



2) Lab Kurulumu

Kod:
git clone https://github.com/digininja/DVWA.git
cd DVWA
docker compose up -d


Kurulum sonrası DVWA Security'yi Low yapın. SQL Injection ve SQL Injection (Blind) sayfalarını kullanacağız.



[center][/center]



İsteğe bağlı olarak kendi MySQL/MariaDB labınızda da aynı mantığı kurabilirsiniz; önemli olan üretim verisine dokunmamaktır.



3) Kavram Referansı



In-band (Union / Error): Sonuç veya hata mesajı aynı kanalda döner.



Kod:
# Union temelli keşif (yalnızca lab, sözdizimi DB'ye göre değişir)
1' UNION SELECT null, null--
1' UNION SELECT user(), database()--


Boolean-based blind: Sayfa içeriği doğru/yanlış cevaba göre değişir; veri bit bit çıkarılır.



Kod:
1' AND 1=1--
1' AND 1=2--


Time-based blind: Kod:
SLEEP()
 / Kod:
WAITFOR DELAY
 ile zaman farkından çıkarım (labda dikkat: kendini DoS etme).



Kod:
# MySQL lab örneği (kendi DVWA'nız)
1' AND SLEEP(3)--


Prepared statement / parametreli sorgu: SQL yapısı ile verinin ayrılması. Asıl savunma budur.



Kod:
# Python psycopg / MySQL connector tarzı
cur.execute("SELECT * FROM users WHERE id = %s", (user_id,))


4) DVWA Low: Adım Adım



Adım 1 - Normal davranış:

Kod:
User ID: 1
# Beklenen: o kullanıcıya ait ad/soyad


Adım 2 - Mantığı bozma:

Kod:
1' OR '1'='1
# Low seviyede genellikle birden fazla satır döner


Çıktıyı yorumlayın: Uygulama girdi etrafına tırnak koyup birleştiriyorsa bu payload tüm satırları getirir. Bu, zafiyetin varlığını gösterir.



[center][/center]



Adım 3 - Sütun sayısını anlama (Union):

DVWA Low'da klasik union yolu kullanılır. Önce sütun sayısını bulun:



Kod:
1' ORDER BY 1--
1' ORDER BY 2--
1' ORDER BY 3--
# Hata aldığınız nokta sütun sayısını aştığınız yerdir


Kod:
1' UNION SELECT user, password FROM users--
# Labda hash'lerin görünmesi, üretimde felaket senaryosudur


Adım 4 - Hata mesajlarını okuma:

Verbose SQL hataları hem enjeksiyonu kolaylaştırır hem bilgi sızdırır. Production'da genel hata sayfası kullanın; detayı loglayın.



Kod:
# Kötü: ham SQL exception'ı kullanıcıya göstermek
# İyi: "Bir hata oluştu" + sunucu tarafı log


5) Blind SQLi Sayfası

DVWA SQL Injection (Blind) sayfasında sonuç satırları doğrudan basılmayabilir; "User ID exists" benzeri mesajlar görürsünüz.



Kod:
1' AND '1'='1
1' AND '1'='2


Birinde "exists", diğerinde farklı mesaj varsa boolean blind mümkündür. Otomatik araçlar (sqlmap) bu farkları ölçer; yalnızca kendi labınızda ve yasal kapsamda kullanın.



Kod:
# sqlmap lab örneği (DVWA localhost, kendi ortamınız)
sqlmap -u "http://127.0.0.1/vulnerabilities/sqli_blind/?id=1&Submit=Submit" \
  --cookie="security=low; PHPSESSID=..." \
  --batch --technique=B


sqlmap çıktısını yorumlarken: DBMS tipi, baner, tablolar. Üretimde izinsiz sqlmap çalıştırmak hem etik dışıdır hem yasadışıdır.



[center][/center]



6) Medium ve Impossible: Ne Değişiyor?

Medium'da DVWA genelde POST + mysql_real_escape_string benzeri kaçış veya seçim kutusu kullanır. Escape, yanlış bağlamda (ör. sayısal alan, farklı karakter seti) yeterli olmayabilir; asıl çözüm prepared statement'tır.



Impossible seviyede parametreli sorgu görürsünüz. Kaynak kodu (DVWA PHP) inceleyerek farkı not edin:



Kod:
# Kavramsal güvenli PHP
$stmt = $mysqli->prepare("SELECT first_name, last_name FROM users WHERE user_id = ?");
$stmt->bind_param("s", $id);
$stmt->execute();


Kod:
# ORM örneği (Django)
User.objects.filter(id=user_id)
# Dikkat: raw() / extra() ile tekrar injection açabilirsiniz


7) Korunma KatmanlarıBirincil: Parametreli sorgu / ORM güvenli API


Girdi doğrulama: Beklenen tip (int), uzunluk, allowlist


Least privilege: Uygulama DB kullanıcısına DROP/FILE vermeyin


Hata yönetimi: Detaylı SQL hatalarını gizleyin


WAF: Savunma derinliği; tek başına çözüm değil


Test: SAST, DAST, kod incelemesi, unit test ile raw SQL denetimi





Kod:
# Beklenen tip kontrolü
if not user_id.isdigit():
    abort(400)


Kod:
# PostgreSQL rol örneği (kavramsal)
GRANT SELECT, INSERT, UPDATE ON app_schema.* TO app_user;
-- FILE, SUPERUSER yok


[center][/center]



8) İleri Seviye

Second-order SQLi: Girdi önce güvenli saklanır, sonra başka bir sorguda güvensiz birleştirilir.



ORM / query builder tuzakları:

Kod:
# Tehlikeli: kullanıcı girdisini SQL parçası sanmak
User.objects.raw("SELECT * FROM users WHERE name = '%s'" % name)


NoSQL injection: MongoDB'de operatör enjeksiyonu (Kod:
$gt
 vb.) ayrı bir ailedir; "SQL yoksa injection yok" yanılgısına düşmeyin.



Rapor şablonu:

Kod:
Bulgu: SQL Injection (CWE-89)
Endpoint: GET /vulnerabilities/sqli?id=
Kanıt: Labda OR '1'='1 ile çoklu satır
Etki: users tablosu okuma (lab)
Öneri: prepared statement + least privilege


9) Sonuç

SQLi, girdinin sorgu yapısına karışmasıdır. DVWA Low'da görün, Impossible'da doğru kodu okuyun, kendi projelerinizde raw string birleştirmeyi yasaklayın. Araçlar yardımcı olur; kök neden kod ve tasarımda kalır.



KaynakçaOWASP SQL Injection


OWASP SQLi Prevention Cheat Sheet


DVWA


sqlmap resmi site


CWE-89


OWASP Top 10 2021 A03 Injection





Yasal Uyarı

SQL Injection testleri yalnızca kendi sistemlerinizde veya yazılı izinli lab/pentest kapsamında yapılmalıdır. İzinsiz veritabanı sorgulama ve araç kullanımı TCK 243, 244, 245 maddeleri kapsamında suç olabilir. Bu yazı eğitim amaçlıdır; sorumluluk uygulayana aittir.




  000-team-07-team-b4a3e5.png (Dosya Boyutu: 64.34 KB / İndirme Sayısı: 7)



IDOR ve Broken Access Control: Tespit ve Korunma Rehberi
Sat, 17 Oct 2026 16:40:26 +0300
[center]
[/center]



Selam TurkTeam, BlueTornado yazıyor.



Broken Access Control, OWASP Top 10 2021 listesinde A01 olarak birinci sıradaydı. Altındaki en sık pratik bulgulardan biri de IDOR (Insecure Direct Object Reference). Bu konuda IDOR'un ne olduğunu, Broken Access Control ile ilişkisini, labda nasıl güvenli test edileceğini ve sunucu tarafı korunmayı anlatıyorum.



Konuda Anlatılacaklar

Broken Access Control ve IDOR nedir?


Yatay / dikey yetki karışıklığı


Lab ortamı: Juice Shop ve basit demo API


Tespit adımları: parametre manipülasyonu


Korunma: yetki kontrolleri, dolaylı referanslar


İleri seviye: mass assignment, GraphQL, BOLA


Kaynakça ve yasal uyarı





1) Teori: Erişim Kontrolü Bozulunca Ne Olur?

Erişim kontrolü iki soruya cevap verir: "Bu kullanıcı kim?" (kimlik doğrulama) ve "Bu işlem / nesne için yetkisi var mı?" (yetkilendirme). Broken Access Control, ikinci sorunun atlanması veya yanlış cevaplanmasıdır.



IDOR: Uygulamanın iç nesneye (sipariş, dosya, mesaj) kullanıcı kontrollü bir kimlikle (id, uuid, dosya adı) doğrudan referans vermesi ve sahiplik/yetki kontrolü yapmaması.



Kod:
# Tehlikeli kalıp
@app.get("/api/orders/{order_id}")
def get_order(order_id: int):
    # Sadece login kontrolü var, sahiplik yok
    return db.orders.get(order_id)


Kod:
# Doğru yönde
@app.get("/api/orders/{order_id}")
def get_order(order_id: int, user=Depends(current_user)):
    order = db.orders.get(order_id)
    if order is None or order.owner_id != user.id:
        raise HTTPException(404)  # veya 403
    return order


IDOR yalnızca sayısal id'lerde olmaz. Tahmin edilebilir dosya yolları, e-posta adresleri, hesap numaraları da nesne referansı olabilir.



Alıntı:UUID kullanmak IDOR'u "çözmez". Keşfi zorlaştırabilir; yetki kontrolü olmadan bilinmeyen UUID hâlâ başkasının verisine açılan kapıdır (ör. sızıntı, referrer, bildirim linki).


2) Yatay ve Dikey ErişimYatay (horizontal): Aynı roldeki A kullanıcısı, B kullanıcısının kaynağına erişir (klasik IDOR).


Dikey (vertical): Normal kullanıcı admin işlevine erişir (Kod:
/admin/deleteUser
).


Bağlam / işlev: Kullanıcı kendi siparişini görebilir ama "iade onayla" gibi ayrıcalıklı işlemi yapamamalıdır.





Kod:
# Dikey örnek (kavramsal)
POST /api/admin/users/42/role  {"role":"admin"}
# Rol kontrolü yoksa Broken Access Control


3) Lab Ortamı

Kod:
docker pull bkimminich/juice-shop
docker run --rm -p 3000:3000 bkimminich/juice-shop


Juice Shop'ta sepet, geri bildirim ve kullanıcı challenge'larında erişim kontrolü zafiyetleri bilinçli olarak vardır. Spoiler vermeden: kendi hesabınızla oluşturduğunuz nesnelerin kimliklerini not alıp, başka hesapla aynı kimliğe istek atmayı deneyin (yalnızca localhost).



Basit bir yerel demo için:



Kod:
# Flask iskeleti (kasıtlı zayıf - sadece lab)
orders = {1: {"owner": "ali", "item": "kitap"}, 2: {"owner": "ayse", "item": "kalem"}}

@app.get("/orders")
def get(id: int):
    return orders[id]  # sahiplik yok!


[center][/center]



4) Kavram Referansı



Direct object reference:

Kod:
GET /invoices/18442.pdf
GET /api/v1/messages/9921


Indirect reference map: Kullanıcıya geçici, oturuma bağlı rastgele anahtar vermek. Yine de sunucuda yetki doğrulanmalıdır.



Kod:
# Kavramsal eşleme
session_refs["a8f0..."] = {"type":"invoice", "id":18442, "owner": user.id}


Forced browsing: Auth gerektiren URL'lerin tahmin edilerek gezilmesi.



Kod:
/admin/dashboard
/api/internal/metrics


CORS yanlış yapılandırması: Access-Control-Allow-Origin: * ve credentials birlikte veya aşırı geniş origin listesi, tarayıcıdan yetkisiz okumayı kolaylaştırabilir.



5) Tespit: Adım Adım (Yasal Lab)



Adım 1 - İki hesap oluşturun. A ve B. A ile kaynak yaratın (sipariş, not, dosya).



Adım 2 - İstekleri kaydedin. Burp / DevTools ile Kod:
order_id
, Kod:
userId
, Kod:
doc
 parametrelerini bulun.



Kod:
# Örnek istek
GET /api/orders/105 HTTP/1.1
Cookie: session=A_SESSION


Adım 3 - Kimliği değiştirin. 105 yerine B'nin veya A'nın diğer kaydını koyun; oturum A'da kalsın.



Kod:
GET /api/orders/106 HTTP/1.1
Cookie: session=A_SESSION


Adım 4 - Yanıtı yorumlayın.200 + B'nin verisi -> yatay IDOR güçlü aday


403/404 -> kontrol var (yine de başka uçları deneyin)


301 ile başka yere gitmek -> mantığı anlayın





[center][/center]



Adım 5 - Metotları deneyin. GET güvenli görünürken PUT/DELETE/PATCH açık kalmış olabilir.



Kod:
PUT /api/orders/106
{"status":"refunded"}


Adım 6 - Encoding / tip oyunları. Kod:
106
, Kod:
106.0
, dizi Kod:
[106]
, JSON Kod:
{"id":106}
 gibi alternatif temsiller bazı framework'lerde farklı kod yollarına düşebilir.



6) KorunmaHer istekte sunucu tarafı yetki kontrolü (deny by default)


"Bu nesne bu kullanıcıya mı ait?" sorusunu merkezi bir policy katmanında sorun


Sadece UI'da butonu gizlemek yetmez


Admin işlevlerini ayrı rol ve mümkünse ayrı ağ/segment ile koruyun


Loglayın: access.denied olayları


Otomatik test: A kullanıcısı B kaynağına 403 bekleyen entegrasyon testleri





Kod:
# Pseudo-policy
def authorize(user, action, resource):
    if user.role == "admin" and action in ADMIN_ACTIONS:
        return True
    if resource.owner_id == user.id and action in OWNER_ACTIONS:
        return True
    return False


Kod:
# Django örneği
class OrderDetail(LoginRequiredMixin, UserPassesTestMixin, DetailView):
    def test_func(self):
        return self.get_object().owner_id == self.request.user.id


[center][/center]



7) İleri Seviye

BOLA (Broken Object Level Authorization): OWASP API Top 10'da API'ler için IDOR'un karşılığıdır. API güvenliği konusunda ayrıca ele alınacak.



Mass assignment / bağlama: Kullanıcının Kod:
{"role":"admin"}
 alanını body'de gönderip profilini yükseltmesi.



Kod:
# Tehlikeli
user.update(request.json)
# Güvenli: allowlist
user.update({k: request.json[k] for k in ("name", "bio")})


GraphQL: Nesne id'leri ile başka kullanıcı kayıtlarını çekmek; field-level authorization gerekir.



Batch / IDOR otomasyonu: Intruder ile id bruteforce yalnızca yetkili labda; üretimde rate limit ve izleme şarttır.



Kod:
# Rapor dili
Bulgu: IDOR / Broken Access Control (CWE-639)
Endpoint: GET /api/orders/{id}
Kanıt: Kullanıcı A, kullanıcı B siparişini 200 ile okudu
Öneri: sahiplik kontrolü + test otomasyonu


8) Sonuç

IDOR, Broken Access Control ailesinin görünür yüzüdür. UUID, "gizli URL" veya sadece frontend kontrolü yetmez. Sunucuda her nesne erişiminde yetki sorun; A/B hesap testlerini CI'ya ekleyin.



KaynakçaOWASP Top 10 2021 A01


OWASP IDOR Prevention Cheat Sheet


OWASP API Top 10 - BOLA


CWE-639


OWASP Juice Shop





Yasal Uyarı

Erişim kontrolü testleri yalnızca kendi uygulamalarınızda veya yazılı yetki kapsamındaki pentestlerde yapılmalıdır. Başkasının hesabına veya sistemine izinsiz erişim denemesi TCK 243-245 kapsamında suç oluşturabilir. Eğitim amaçlıdır; sorumluluk uygulayana aittir.




  000-team-08-team-daccdd.png (Dosya Boyutu: 63.82 KB / İndirme Sayısı: 7)



XSS Nedir? Reflected, Stored ve DOM Tabanlı XSS (DVWA Lab ile Uygulamalı)
Sat, 17 Oct 2026 16:37:29 +0300
[center]
[/center]



Selam millet, BlueTornado burada.



Cross-Site Scripting (XSS), web uygulamalarında en sık karşılaşılan enjeksiyon zafiyetlerinden biridir. Bu konuda XSS'in ne olduğunu, üç ana tipini (Reflected, Stored, DOM), DVWA labında nasıl güvenli şekilde gözlemleyeceğinizi ve korunma yöntemlerini adım adım anlatacağım. Amaç saldırı senaryosu ezberletmek değil; neden oluştuğunu ve nasıl engellendiğini anlamanız.



Konuda Anlatılacaklar

XSS nedir, ne değildir?


DVWA lab kurulumu ve güvenlik seviyeleri


Reflected XSS: istekte yansıyan girdi


Stored XSS: kalıcı depolanan girdi


DOM-based XSS: tarayıcı tarafı


Çıktı encoding, CSP ve framework korumaları


İleri seviye: mutasyon XSS, cookie bayrakları, raporlama


Kaynakça ve yasal uyarı





1) XSS Nedir?

XSS, uygulamanın kullanıcıdan gelen veriyi, tarayıcının JavaScript olarak yorumlayabileceği biçimde doğrulamadan veya encode etmeden HTML/JS bağlamına yazmasıdır. Sonuçta saldırgan, kurbanın tarayıcısında kendi script'ini çalıştırabilir.



XSS ile yapılabilecekler (eğitim bağlamında riskleri anlamak için):Oturum çerezinin (HttpOnly değilse) okunması


Sayfa içeriğinin değiştirilmesi (defacement / phishing formu)


Kurban adına istek atılması (aynı origin içinde)


Keylogger benzeri script enjekte edilmesi





XSS bir "sunucuyu ele geçirme" zafiyeti değildir; kullanıcının tarayıcısını hedefler. Yine de admin paneline Stored XSS düşerse etki çok yüksek olabilir.



Alıntı:OWASP Top 10 2021'de XSS, A03 Injection kategorisi altında değerlendirilir. Ayrı bir Top 10 maddesi olarak listelenmese de pratikte en sık bulgulardan biridir.


2) Lab: DVWA Kurulumu

Yalnızca kendi bilgisayarınızda, izole ortamda çalıştırın.



Kod:
git clone https://github.com/digininja/DVWA.git
cd DVWA
docker compose up -d


Tarayıcı: Kod:
http://127.0.0.1
 (compose port eşlemenize göre değişebilir). Varsayılan giriş bilgileri DVWA dokümantasyonunda yer alır; ilk girişte Setup sayfasından veritabanını oluşturun.



Kod:
# Güvenlik seviyesini ayarlamak için DVWA menüsü:
# DVWA Security -> Low / Medium / High / Impossible


Bu konuda önce Low, sonra Impossible seviyesini karşılaştıracağız. Impossible, korunmuş referans implementasyondur.



[center][/center]



3) Kavram Referansı



Context (bağlam): Girdinin HTML gövdesine mi, attribute içine mi, JavaScript string'ine mi, URL'ye mi yazıldığı kritiktir. Encoding stratejisi bağlama göre değişir.



Kod:
# HTML gövde bağlamı (kavramsal tehlikeli)
echo "Merhaba $name"

# Attribute bağlamı
echo ""


Output encoding: Gösterilecek verinin HTML entity'ye çevrilmesi (Kod:
<
 -> Kod:
<
 gibi).



CSP (Content Security Policy): Tarayıcıya hangi script kaynaklarının çalışabileceğini söyleyen HTTP başlığı. XSS'i tamamen bitirmez ama etkisini ciddi azaltır.



Kod:
# Örnek CSP (sıkılaştırılmış, kavramsal)
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'


HttpOnly / Secure / SameSite çerez bayrakları:

Kod:
Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax
HttpOnly, document.cookie ile çerezin JS'ten okunmasını engeller (XSS'in oturum çalma etkisini azaltır; XSS'i yok etmez).



4) Reflected XSS (DVWA Low)

Reflected XSS'te zararlı girdi genellikle URL parametresi veya form alanı olarak gelir, sunucu cevabında hemen yansır ve depolanmaz. Kurbanın özel hazırlanmış bir linke tıklaması gerekir.



DVWA'da XSS (Reflected) sayfasına gidin, güvenlik seviyesini Low yapın.



Kod:
# Labda denenebilecek basit payload (yalnızca DVWA)


Forma yazıp gönderdiğinizde alert çıkıyorsa, girdi encode edilmeden HTML'e basılıyor demektir. Bu, "XSS var" kanıtı için klasik bir smoke test'tir; gerçek bir pentest raporunda daha anlamlı bir PoC (ör. çerez bayrağı kontrolü, DOM değişikliği) tercih edilir.



[center][/center]



Çıktıyı yorumlama:Alert çıktı -> girdi script olarak yorumlandı


Sayfada Kod:
<script>
 görünüyorsa encoding çalışıyor olabilir


WAF/filtre sadece Kod:


Sayfayı yenilediğinizde veya başka bir tarayıcı profiliyle girdiğinizde alert tekrarlanıyorsa Stored XSS söz konusudur. Etki yüzeyi Reflected'dan genelde daha yüksektir çünkü tek bir kurban linki gerekmez.



[center][/center]



Savunma gözlemi: Impossible seviyeye alıp aynı payload'ı deneyin. Veri saklansa bile gösterilirken encode edilmelidir. "Saklarken temizle, gösterirken encode et" ikilisinden özellikle gösterirken encode vazgeçilmezdir; çünkü veri birden fazla bağlamda kullanılabilir.



6) DOM-Based XSS

DOM XSS'te sunucu cevabı "temiz" görünebilir; zafiyet tarayıcıdaki JavaScript'in Kod:
location
, Kod:
hash
, Kod:
document.referrer
 gibi kaynaklardan okuduğu veriyi Kod:
innerHTML
, Kod:
document.write
, Kod:
eval
 gibi güvenli olmayan sink'lere yazmasından doğar.



Kod:
// Tehlikeli kalıp (kavramsal)
var q = location.hash.substring(1);
document.getElementById('out').innerHTML = q;

// Daha güvenli: textContent kullanmak
document.getElementById('out').textContent = q;


DVWA'da DOM XSS için ayrı sayfa/versiyon farklılıkları olabilir; Juice Shop challenge'larında da DOM XSS örnekleri bulunur. Kaynak (source) ve sink listeleri için OWASP DOM based XSS Prevention Cheat Sheet'e bakın.



Kod:
# Kaynak örnekleri: location, document.URL, postMessage
# Sink örnekleri: innerHTML, outerHTML, eval, setTimeout(string)


7) Uygulamalı: Filtreyi Anlamak (Adım Adım)

Low -> Medium -> High ilerleyin; her seviyede şu notları alın:



Kod:
# Not şablonu
Seviye: Medium
Denenen: 
Sonuç: script kelimesi silindi / sayfa boş / encode edildi
Çıkarım: blacklist mi, encoding mi?


Kod:
# High seviyede sık görülen: gelişmiş filtre veya kısmi encoding
# Impossible: doğru kütüphane encoding + katı kurallar


Burp Suite kullanıyorsanız Proxy ile isteği yakalayıp parametreyi Repeater'da değiştirerek sunucu cevabında girdinin nereye yazıldığını izleyin (yalnızca lab).



[center][/center]



8) Korunma: Geliştirici Kontrol ListesiŞablon motorunun otomatik escaping özelliğini kapatmayın (Django, Jinja2 autoescape, React JSX varsayılanı)


Kod:
dangerouslySetInnerHTML
, Kod:
|safe
, Kod:
v-html
 gibi kaçış kapılarını kod incelemesinde işaretleyin


Bağlama uygun encoding kullanın (HTML, attribute, JS, URL, CSS ayrıdır)


Zengin metin (WYSIWYG) gerekiyorsa sıkı HTML sanitizer (ör. DOMPurify) kullanın


CSP ekleyin; inline script'i azaltın


Çerezlerde HttpOnly; Secure; SameSite ayarlayın


WAF kara listesine güvenerek "XSS bitti" demeyin





Kod:
# Python / Jinja2 (otomatik escape açıkken)
{{ user_comment }}

# Bilerek ham HTML (kaçının veya sanitize edin)
{{ user_comment | safe }}


Kod:
# PHP örneği (bağlama göre)
echo htmlspecialchars($name, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');


9) İleri Seviye Notlar

Mutation XSS (mXSS): Tarayıcının HTML parser'ının beklenmedik şekilde DOM'u "düzeltmesi" sonucu sanitizer'ların bypass edilmesi. Kendi sanitizer'ınızı yazmak yerine bakımı yapılan kütüphaneleri kullanın.



Blind XSS: Payload'un admin panelinde, log görüntüleyicide veya destek aracında sonradan tetiklenmesi. BeAlert / XSS Hunter benzeri geri çağırma (callback) servisleri pentestlerde kullanılır; izinsiz sistemlerde asla.



Raporlama dili:

Kod:
Bulgu: Stored XSS (CWE-79)
Konum: /guestbook message alanı
Etki: Oturum çerezi HttpOnly değilse hesap ele geçirme riski
Kanıt: Lab ortamında alert PoC + HTML kaynak çıktısı
Öneri: Çıktı encoding + CSP + HttpOnly


[center][/center]



10) Sonuç

XSS; Reflected, Stored ve DOM olarak üç ana ailede incelenir. Ortak kök neden, güvensiz bağlama yazımdır. DVWA Low'da zafiyeti görün, Impossible'da doğru kodu inceleyin, kendi uygulamanızda escaping + CSP + çerez bayraklarını kontrol edin.



KaynakçaOWASP XSS


OWASP XSS Prevention Cheat Sheet


OWASP DOM based XSS Prevention


DVWA (GitHub)


MDN Content Security Policy


CWE-79





Yasal Uyarı

Bu içerik eğitim ve savunma amaçlıdır. XSS testleri yalnızca kendi labınızda veya yazılı yetki verilen sistemlerde yapılmalıdır. İzinsiz testler TCK 243-245 kapsamında suç oluşturabilir. Sorumluluk uygulayana aittir.




  000-team-06-team-1e62fe.png (Dosya Boyutu: 69.38 KB / İndirme Sayısı: 5)