Güvenlik Mühendisleri için filter(): Deterministik İş Hatları, Daha Az Yanlış Pozitif ve Sıfır "Temizleyici Olarak Filtre" Efsanesi
Eğer aradıysanız "javascript filtresi"Bu sonuçlardan birini istiyor olma ihtimaliniz yüksek:
- Gürültülü tarama çıktısını temiz bir çıktıya dönüştürün, eyleme geçirilebilir Kısa liste.
- Spagetti döngüler yazmadan nesne dizilerini (varlıklar, bulgular, IOC'ler, kurallar) filtreleyin.
- Filtrelemeyi CI, tarayıcı sandbox'ı veya güvenlik boru hattı içinde çalışacak kadar hızlı hale getirin.
- Klasik tuzaktan kaçının: "dizeleri filtreleme" ≠ "güvenilmeyen girdiyi güvenli hale getirme".
Bu sonuncusu, pek çok güvenlik aracının sessizce başarısız olduğu yerdir.
Uzun kuyruklu sorgunun bir nedeni var "javascript filtre nesne dizisi" her zaman yeşil: tam olarak bu başlıklı kanonik bir Stack Overflow başlığı şurada bulunur "228 bin kez görüntülendi"Bu da uygulayıcıların gerçekte neyi tıkladıkları, kopyaladıkları ve dağıttıklarına dair güçlü bir sinyaldir. (Yığın Taşması)
Ne Array.prototype.filter() garantiler (ve kesinlikle garanti etmediği şeyler)
Dil düzeyinde, filter():
- Bir döndürür yeni dizi yüklemi doğruluk döndüren öğeleri içerir.
- Üretir sığ kopya (nesne referansları paylaşılır, klonlanmaz). (MDN Web Dokümanları)
- Atlar boş yuvalar seyrek dizilerde (yükleminiz "delikler" için çağrılmaz). (TC39)
MDN hem "sığ kopyalama" hem de "seyrek dizilerdeki boş yuvalar için çağrılmaz" konusunda açıktır. (MDN Web Dokümanları)
ECMAScript spesifikasyonu ayrıca geri aramaların eksik elemanlar için çağrılmadığını açıkça belirtmektedir. (TC39)
Güvenlik işlem hatlarında seyrek diziler neden önemlidir?
Seyrek diziler beklediğinizden daha fazla ortaya çıkar: JSON dönüşümleri, "dizin silme" hataları, çok kaynaklı birleştirmeden elde edilen kısmi sonuçlar veya naif tekilleştirme.
const results = [ {id: 1}, , {id: 3} ]; // deliğe dikkat edin
const tutulan = results.filter(() => true);
console.log(kept); // [{id: 1}, {id: 3}] (delik kaybolur)
Eğer işlem hattınız "aynı uzunlukta giriş, aynı uzunlukta çıkış" varsayımına dayanıyorsa, seyrek diziler bunu bozacaktır. Bir triyaj işlem hattında, bu şu anlama gelebilir Sessiz veri kaybı.
Yüksek TO modeli: nesne dizilerini filtreleme
Gerçek "javascript filtresi" kullanımının çoğu nesne dizilerini (varlıklar/bulgular/IOC'ler) filtrelemektir.
Örnek: yalnızca istismar edilebilir web bulgularını ekli kanıtlarla birlikte saklayın
const bulgular = [
{ id: "XSS-001", tür: "xss", önem derecesi: "yüksek", doğrulanmış: doğru, kanıt: ["req.txt", "resp.html"] },
{ id: "INFO-009", tür: "banner", önem derecesi: "info", verified: false, evidence: [] },
{ id: "SSRF-004", tür: "ssrf", ciddiyet: "kritik", doğrulanmış: doğru, kanıt: ["dnslog.png"] },
];
const actionable = findings.filter(f =>
f.verified &&
(f.severity === "high" || f.severity === "critical") &&
f.evidence?.length > 0
);
console.log(actionable.map(f => f.id)); // ["XSS-001", "SSRF-004"]
Örnek: kapsam kontrolü (programınızı mahvetmek için en kolay yer)
const inScopeHosts = new Set(["api.example.com", "admin.example.com"]);
const varlıklar = [
{ ana bilgisayar: "api.example.com", ip: "203.0.113.10", canlı: true },
{ ana bilgisayar: "cdn.example.com", ip: "203.0.113.11", canlı: true },
{ ana bilgisayar: "admin.example.com", ip: "203.0.113.12", canlı: yanlış },
];
const hedefler = varlıklar
.filter(a => a.alive)
.filter(a => inScopeHosts.has(a.host));
console.log(hedefler);
// [{host: "api.example.com", ...}]
Kullanmak Set kazayı önler O(n²) desen (includes() içeride filter() büyük diziler arasında). Bu, on binlerce varlığı filtrelediğinizde önemlidir.
Performans gerçeği: paketlenmiş ve delikli diziler ve neden sadece biraz önemsemelisiniz
V8'de aşağıdakiler arasında iyi bilinen bir ayrım vardır paketlenmiş ve holey dizileri; paketlenmiş diziler üzerindeki işlemler genellikle delikli dizilere göre daha verimlidir. (V8)
Güvenlik uygulaması: açıklar yaratan boru hatları (arr[i]'yi sil, seyrek birleştirme) performansı düşürebilir ve doğruluk. Pratik kural basittir:
- Delikler oluşturmayın. Tercih et
ekleme,filtreveya dizileri yeniden oluşturun. - Büyük veri kümelerini işliyorsanız, sıcak dizilerdeki türleri karıştırmaktan kaçının.
Bir güvenlik mühendisinin karar tablosu: filtre vs bazı vs bulmak vs azaltmak
| Bir güvenlik boru hattında hedef | En iyi araç | Neden | Yaygın hata |
|---|---|---|---|
| Tüm eşleşmeleri sakla (kısa liste) | filter() | Bir alt küme dizisi döndürür | Yüklem sırasında mutasyona uğrayan kaynak |
| İlk maçta durun (politika kapısı) | some() | Erken çıkış boolean | filter().length > 0 |
| İlk eşleşmeyi al (rota seçimi) | find() | Erken çıkış + unsur | filter()[0] |
| Metrikler oluşturun (sayılar, puanlar) | reduce() | Tek geçişli toplama | Redüktörde pahalı I/O yapma |
Bu, stilden ziyade boru hattınızı deterministik ve her yerde (CI, tarayıcı sandbox'ı, ajan koşucuları) çalışabilecek kadar ucuz hale getirmekle ilgilidir.
Tehlikeli aşırı yüklenme: "filtreleme" "sterilizasyon" değildir
Şimdi güvenlik mühendislerinin acımasız olması gereken kısım: dize filtreleme bir güvenlik sınırı değildir.
OWASP'ın XSS Önleme kılavuzu şunları vurgulamaktadır çıktı kodlaması (ve doğru bağlam için doğru savunmayı kullanarak) girdi filtrelemeye güvenmek yerine. (OWASP Hile Sayfası Serisi)
OWASP'ın kendi XSS Filtre Kaçırma içeriği, girdi filtrelemeyi eksik bir savunma olarak açıkça çerçevelemekte ve baypasları kataloglamaktadır. (OWASP Hile Sayfası Serisi)
PortSwigger'ın XSS hile sayfası (Ekim 2025'te güncellendi), WAF'ları ve filtreleri atlamaya yardımcı olan vektörleri içerdiği konusunda benzer şekilde açıktır. (PortSwigger)
Gerçekçi bir örnek: Ayrıştırma farklılıkları altında çöken URL "filtreleri"
Kötü model:
function allowUrl(u) {
return !u.includes("javascript:") && !u.includes("data:");
}
Daha iyi model: ayrıştır + izin listesi + normalleştir:
function allowUrl(u, allowedHosts) {
const url = new URL(u, ""); // göreli girdiler için güvenli taban
if (!["https:"].includes(url.protocol)) return false;
return allowedHosts.has(url.hostname);
}
const allowedHosts = new Set(["docs.example.com", "cdn.example.com"]);
Bu zihinsel değişimdir: dizeleri eşleştirmeyi durduryapılandırılmış verileri doğrulamaya başlayın.
"Filtrelerin/dezenfektanların" üretimde başarısız olduğunu kanıtlayan CVE'ler ve bunları neden kontrollerinize dahil etmeniz gerektiği
Kuruluşunuz "HTML'yi sterilize ediyoruz" dediğinde, tehdit modeliniz hemen şunları içermelidir: hangi dezenfektan, hangi sürüm, hangi yapılandırma ve hangi bypass geçmişi?
CVE-2025-66412 (Açısal şablon derleyicisi depolanmış XSS)
NVD, Angular'ın şablon derleyicisinde, Angular'ın yerleşik sanitizasyonunu atlamaya izin verebilecek eksik bir dahili güvenlik şeması nedeniyle depolanmış bir XSS'yi açıklar; yamalı sürümlerde düzeltildi. (NVD)
Güvenlik paketi: "çerçeve sanitizasyonu" kalıcı bir garanti değildir. Bunu diğer güvenlik kontrolleri gibi ele alın: sürüm, danışmanlık, regresyon testleri.
CVE-2025-26791 (Hatalı regex aracılığıyla DOMPurify mXSS)
NVD, 3.2.4'ten önce DOMPurify'ın bazı durumlarda mutasyon XSS'sine yol açabilecek hatalı bir şablon-literal regex'e sahip olduğunu belirtiyor. (NVD)
Güvenlik paketi: sanitizer seçenekleri önemlidir. Yapılandırma kombinasyonları, "saygın bir kütüphane kullandığınızda" bile istismar koşulları yaratabilir.
CVE-2024-45801 (DOMPurify derinlik kontrolü baypası + prototip kirliliği zayıflaması)
NVD, özel yuvalama tekniklerinin derinlik kontrolünü atlayabileceğini bildiriyor; prototip kirliliği onu zayıflatabilir; sonraki sürümlerde düzeltildi. (NVD)
Güvenlik paketi: Sezgisel yöntemlere (derinlik sınırları, yuvalama kontrolleri) dayanan savunmalar genellikle baypas hedefleri haline gelir.
CVE-2025-59364 (express-xss-sanitizer özyineleme DoS)
NVD, iç içe geçmiş JSON istek gövdelerinin sanitizasyonu sırasında sınırsız özyineleme derinliğine dikkat çekiyor; GitHub danışmanlığı, etki ve düzeltilmiş sürümleri ayrıntılarıyla anlatıyor. (NVD)
Güvenlik paketi: "sanitization" kodu kullanılabilirlik hatalarına yol açabilir. Saldırganlar hizmetinizi güvenilir bir şekilde çökertebiliyorlarsa XSS'ye ihtiyaç duymazlar.
Pentest otomasyonu için pratik "javascript filtresi" modelleri
1) Güven geçişi: pahalı doğrulama için yalnızca yüksek güvene sahip adayları tutun
const adaylar = [
{ id: "C1", sinyal: 0,92, maliyet: 3,0 },
{ id: "C2", sinyal: 0,55, maliyet: 1,2 },
{ id: "C3", sinyal: 0,81, maliyet: 9,5 },
];
const bütçe = 10;
const kısa liste = adaylar
.filter(c => c.signal >= 0.8) // güven eşiği
.filter(c => c.cost c.id)); // ["C1"]
2) Kanıt bütünlüğü: raporların kanıtsız gönderilmesine izin vermeyin
const reportItems = findings.filter(f =>
f.verified &&
Array.isArray(f.evidence) &&
f.evidence.length >= 1
);
3) Kill-switch filtreleri: herhangi bir istismar adımından önce politikayı uygulayın
Kullanım some() "herhangi bir eşleşme varsa reddet" için:
const forbidden = [/\\.gov$/i, /\\.mil$/i];
const isForbidden = host => forbidden.some(rx => rx.test(host));
Penligent'ın uyduğu yer
"Kanıt öncelikli" bir iş akışında, filter() için harika deterministik orkestrasyon: bir sonraki aşamada neyin doğrulanacağına, hangi yolların keşfedileceğine ve nihai rapora neyin gireceğine karar vermek. Zor kısım ise doğrulama döngüsüdür: yeniden üretme, kanıt toplama ve sonuçları çalıştırmalar arasında tutarlı tutma.
Yapay zeka odaklı bir pentest platformunun doğal olarak uyabileceği yer burasıdır: adayları kodda filtrelersiniz, ardından doğrulamak, kanıt toplamak ve yürütmeyi ortamlar arasında tutarlı tutmak için otomatik bir sistem kullanırsınız. Penligent'in bir yapay zeka pentest platformu olarak konumlandırılması, özellikle boru hattının bu "doğrulama + kanıt + rapor" segmentinde anlamlıdır.
Penligent: https://penligent.ai/
"Javascript filtresi" kullanımını güvenlik seviyesinde tutmak için kısa bir kontrol listesi
- Tedavi
filter()olarak veri şekillendirme"girdi sterilizasyonu" değil. - Seyrek dizilerden kaçının; boş yuvalar için geri çağrıların atlandığını unutmayın. (TC39)
- Kullanım
Set/Haritaölçekte üyelik filtreleri için. - Tercih et
some()/find()Erken çıkışa ihtiyacınız olduğunda. - XSS savunması için kara liste filtrelerini değil, OWASP'ın bağlam tabanlı kodlama kılavuzunu izleyin. (OWASP Hile Sayfası Serisi)
- Dezenfektan/çerçeve CVE'lerini birinci sınıf tedarik zinciri riski olarak takip edin. (NVD)
Referanslar ve yetkili bağlantılar (kopyala/yapıştır)
- MDN
Array.prototype.filter(): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter (MDN Web Dokümanları) - Eksik öğeleri atlama hakkında ECMAScript teknik notu: https://tc39.es/ecma262/multipage/indexed-collections.html (TC39)
- V8 "Element çeşitleri" (paketlenmiş vs delikli): https://v8.dev/blog/elements-kinds (V8)
- Stack Overflow "javascript filter array of objects" (228k kez görüntülendi): https://stackoverflow.com/questions/13594788/javascript-filter-array-of-objects (Yığın Taşması)
- OWASP XSS Önleme Hile Sayfası: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html (OWASP Hile Sayfası Serisi)
- OWASP XSS Filtresi Kaçırma Hile Sayfası: https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html (OWASP Hile Sayfası Serisi)
- PortSwigger XSS Hile Sayfası (2025): https://portswigger.net/web-security/cross-site-scripting/cheat-sheet (PortSwigger)
- NVD CVE-2025-66412 (Angular depolanmış XSS): https://nvd.nist.gov/vuln/detail/CVE-2025-66412 (NVD)
- Angular danışmanlığı (CVE-2025-66412): https://github.com/angular/angular/security/advisories/GHSA-v4hv-rgfq-gp49 (GitHub)
- NVD CVE-2025-26791 (DOMPurify mXSS): https://nvd.nist.gov/vuln/detail/CVE-2025-26791 (NVD)
- NVD CVE-2024-45801 (DOMPurify derinlik kontrolü atlaması): https://nvd.nist.gov/vuln/detail/CVE-2024-45801 (NVD)
- NVD CVE-2025-59364 (express-xss-sanitizer DoS): https://nvd.nist.gov/vuln/detail/CVE-2025-59364 (NVD)
- GitHub danışmanlığı GHSA-hvq2-wf92-j4f3: https://github.com/advisories/GHSA-hvq2-wf92-j4f3 (GitHub)
