(Savunma Odaklı Teknik İnceleme – VIP)

1) Yasal ve Etik Kapsam

Bu doküman yalnızca kendi uygulamanız veya yazılı izinli güvenlik testlerinde; risk analizi, tespit ve iyileştirme amacıyla kullanıma yöneliktir.

---

2) Neden Electron’da “DOM XSS” Daha Ağırdır?

Web uygulamalarında DOM-based XSS çoğu zaman “tarayıcı sandbox” içinde kalır. Electron’da ise yanlış yapılandırma varsa XSS, şu sınırlara çarpabilir:

• Renderer süreç → Node.js API’lerine erişim (dosya, süreç, ağ)
  
• Renderer → preload üzerinden yüksek yetkili köprüler
  
• Renderer → IPC ile ana süreçte (main) işlemler tetikleme
  
• Custom protocol / deep link ile “trusted” sanılan veri girişleri

Bu yüzden “XSS = UI hack” değil; Electron’da “XSS = sistem yetkisi kokusu” olabilir.

---

3) Tehdit Modeli: XSS’ten RCE’ye Giden Tipik Zincir (Yüksek Seviye)

Bu bölüm “nasıl exploit edilir” değil; savunmacının hangi halkaları denetlemesi gerektiğini anlatır.

3.1 Giriş Noktası: DOM-Based XSS Kaynağı

En yaygın kaynaklar:

• Markdown/HTML render (not alma, chat, preview, template)
  
• innerHTML/dangerouslySetInnerHTML benzeri kullanım
  
• URL parametreleri / hash fragment / localStorage verisinin DOM’a yazılması
  
• “Link preview”, “import”, “paste” gibi kullanıcı girdisi

Kırılma noktası: Güvenilmeyen veri, DOM’a “HTML olarak” giriyor.

---

3.2 Ayrıcalık Artırma Kapıları

A) nodeIntegration açık (en kritik kırmızı bayrak)

Renderer DOM’u ele geçirilince Node API’lerine giden yol açılabilir.
Savunma hedefi: Renderer = web gibi kalmalı.

B) preload + hatalı “exposed API”

En yaygın modern Electron modeli: contextIsolation: true, nodeIntegration: false, ama preload şunları yaparsa risk büyür:

• Geniş yetkili fonksiyonlar export eder (dosya okuma/yazma, komut çalıştırma vb.)
  
• Parametre doğrulaması yoktur
  
• “string kabul eden” tehlikeli operasyonlar vardır

Savunma hedefi: Preload API’si en küçük yetki + sıkı doğrulama.

C) IPC Tasarımı (renderer → main)

Main process genelde daha yetkilidir (FS, spawn, update, system integration). Renderer’dan gelen mesajlar:

• Allowlist yerine “genel komut kanalı” gibi tasarlanmışsa
  
• “path”, “url”, “cmd benzeri” serbest parametre alıyorsa
  zincirin ikinci halkası oluşur.

Savunma hedefi: IPC = RPC değil; kısıtlı komut seti.

---

3.3 RCE’nin “Gerçek Dünya”ya Yansıma Yolları (Sınıf Olarak)

Aşağıdaki sınıflar genelde “RCE etkisi” doğurur:

• Dosya sistemi yazma + “yüklenen modül/eklenti” mekanizması
  
• Auto-update/asset download gibi uzaktan içerik alma davranışları
  
• URL açma / protocol handler ile beklenmeyen kaynak yürütme
  
• Yerel servislerle entegrasyon (agent/daemon) ve gevşek doğrulama

Not: “RCE” burada çoğu zaman tek bir fonksiyon çağrısı değil, yetkili işlemleri tetikleyebilen bir zincirdir.

---

4) Riskin Artmasına Neden Olan Konfigürasyonlar (Kırmızı Bayraklar)

Aşağıdakiler “acil denetim” işaretidir:

• nodeIntegration: true
  
• contextIsolation: false
  
• enableRemoteModule: true (kullanılıyorsa ekstra risk)
  
• webSecurity: false
  
• allowRunningInsecureContent: true
  
• sandbox: false (özellikle renderer’larda)
  
• CSP yok veya unsafe-inline / aşırı geniş connect-src/script-src
  
• “Remote content” (harici domain’den UI yükleme) + zayıf pinning

---

5) Tespit (Detection): Blue Team / AppSec İçin Sinyaller

5.1 Uygulama Telemetrisi

• Renderer crash/exception artışı (özellikle template/preview ekranlarında)
  
• CSP violation raporları (varsa)
  
• Beklenmedik IPC çağrı patlaması (aynı view’da anormal sayıda mesaj)

5.2 Güvenlik Logları ve Olay İzleri

• Auto-update beklenmedik tetiklenmesi
  
• Renderer’dan tetiklenen file I/O anomali (özellikle user data dizinlerinde)
  
• Yeni oluşturulan şüpheli dosyalar / beklenmedik uzantılar
  
• “openExternal” veya link açma davranışlarında artış

5.3 Runtime İzleme (Kurumsal Dağıtım Senaryosu)

• EDR: beklenmeyen child process / ağ bağlantısı / yazma-çalıştır paterni
  
• Integrity check: uygulama dosyalarında değişiklik, imza bozulması
  
• Proxy log: uygulamanın normalde gitmediği alanlara trafik

---

6) Önleme (Mitigation): Zinciri Katman Katman Kırma

6.1 DOM XSS’i Kaynağında Bitir

• HTML injection yerine text render (escape)
  
• Güvenli sanitizer (allowlist yaklaşımı; “script/event handler” temizleme)
  
• Template engine’lerde auto-escape zorunlu
  
• URL/hash/localStorage verisini DOM’a yazmadan önce doğrula

Kritik prensip: UI katmanı “markup” tüketiyorsa, girdi güvenliği ürün özelliğidir, opsiyon değil.

---

6.2 Electron Güvenlik Baseline

Önerilen minimumlar:

• nodeIntegration: false
  
• contextIsolation: true
  
• sandbox: true (mümkünse)
  
• webSecurity: true
  
• Remote content gerekiyorsa: sıkı origin allowlist + pinned policy

6.3 Preload ve IPC’yi Güvenli Tasarla

• contextBridge ile sadece dar bir API aç
  
• Her çağrıda:
  
  • tip doğrulama (schema)
    
  • allowlist (komut/parametre)
    
  • path normalization (sadece app dizinleri)
• ipcRenderer.invoke / ipcMain.handle tarafında:
  
  • yetkilendirme (hangi pencere hangi çağrıyı yapabilir?)
    
  • rate limit (spam/anomali)
    
  • “string ile ifade edilen iş” yerine “enum komut” tasarımı

6.4 CSP ve Güvenli İçerik Politikaları

• script-src’te unsafe-inline kaçın
  
• Yalnız gerekli domain’lere connect-src
  
• object-src 'none', base-uri 'none' gibi sıkılaştırmalar
  
• CSP violation raporlarını topla (prod’da bile “sampled”)

6.5 Güncelleme ve Dağıtım Güvenliği

• Code signing zorunlu (Windows/macOS)
  
• Auto-update kanalı:
  
  • TLS + sertifikalı endpoint
    
  • update manifest bütünlük kontrolü
    
  • mümkünse pinned key/endpoint yaklaşımı
• “downloaded content” çalıştırma/yorumlama risklerini azalt

---

7) Güvenli Test Yaklaşımı (İzinli, Zarar Vermeden)

VIP ekipler için pratik doğrulama akışı:

1. Konfig denetimi: webPreferences + CSP + protocol handler + preload export listesi
   
2. Renderer yüzeyi haritası: HTML render edilen tüm ekranlar (markdown/preview/template)
   
3. IPC güvenlik incelemesi: main process handle’ları, parametre şemaları, allowlist
   
4. Update / external link davranışı: openExternal, deep link, custom protocol akışları
   
5. Fail-closed testi: beklenmeyen parametrelerde fonksiyonların reddetmesi beklenir

---