alkimcoskun/yordam-kutuphane-otomasyonunda-coklu-html-enjeksiyonuCVE-2026-77818 - Yordam Kütüphane Otomasyon Sistemi - Üç ayrı noktada yansıtılmış HTML enjeksiyonu, form action ele geçirme ve kimlik bilgisi hırsızlığı (CWE-79)
CVE-2026-77818 · CVSS 3.1 6.1 (Orta) · Siber Güvenlik Başkanlığı · Yayımlanma 2026-09-04 · TR-26-1011
Durum: Zafiyetler v22.2 sürümünde giderilmiştir. Etkilenen kurulumların v22.2 veya üzerine yükseltilmesi gerekmektedir.
Yordam Kütüphane Otomasyon Sistemi, Türkiye'de üniversite, halk ve kurum kütüphanelerinde yaygın kullanılan ticari bir kütüphane otomasyonu ve çevrimiçi katalog (OPAC) yazılımıdır. Kurulum on-premise'dır; her müşteri kurumda ayrı bir kopya çalışır.
Ürünün v22.1 sürümünde, birbirinden bağımsız üç ayrı noktada yansıtılmış HTML enjeksiyonu bulunmaktadır. Üçü de kimlik doğrulaması gerektirmez, üçü de tek bir bağlantıyla tetiklenir.
| # | Nokta | Kök neden |
|---|---|---|
| 1 | Oturum açma sayfası, devam parametresi | Escape hiç uygulanmıyor |
| 2 | Gizli form alanı value attribute'u | Escape'ten sonra ikinci kez URL decode |
| 3 | Gizli form alanı name attribute'u | Escape yalnızca değere uygulanıyor, ada uygulanmıyor |
Üçü aynı ürünün aynı sürümünde ve aynı zafiyet sınıfında olduğu için tek bildirim altında toplanmış, tek bir CVE kimliği altında yayımlanmıştır. Etki bakımından en ağır olanı 1 numaralı noktadır.
devam ParametresiEn kritik olan bu. Enjeksiyon noktası doğrudan kimlik doğrulama formunun kendi HTML etiketi.
devam parametresi kullanıcının girişten sonra döneceği adresi taşır ve hex kodlu gelir — 2f796f7264616d2f değeri /yordam/ demektir. Uygulama bu değeri hex'ten çözer ve giriş formunun açılış etiketine yazar. Arada hiçbir escape işlemi yoktur:
<form class='girisForm collapse show ikiAdimliGiris' method='post'
action='inc/islem.fm.inc.php'
data-url='<HEX ÇÖZÜLMÜŞ KULLANICI GİRDİSİ>'
autocomplete="off">
Çıktıda <, > ve tırnak karakterleri ham olarak yer alır. Payload'ı tutan tek şey data-url attribute'unun tek tırnakla sarılmış olmasıdır. Girdinin içine tek tırnak konduğunda o da biter: attribute kapanır, <form> etiketi kapanır ve saldırganın yazdığı HTML sayfanın kimlik doğrulama formunun yerine geçer.
Form action'ı ele geçiriliyor. Burada sahte bir form çizilmiyor — uygulamanın kendi formu boş bırakılıp kapatılıyor, hemen ardından aynı CSS sınıflarını taşıyan yeni bir <form> açılıyor. Sayfadaki kullanıcı adı, parola ve doğrulama kodu alanlarının hepsi uygulamanın orijinal HTML'i olduğu için bu yeni formun içinde kalıyor. Kullanıcı gerçek formu görüyor, gerçek formu dolduruyor; girdiği bilgiler saldırganın sunucusuna gidiyor. Görsel olarak ayırt edilebilecek hiçbir fark yok.
Kritik olan nokta: enjeksiyon rastgele bir sayfada değil, kullanıcının parolasını girmesinin zaten beklendiği sayfada gerçekleşiyor. Sıradan bir reflected injection'da saldırganın kurbanı ikna etmesi gerekir; burada ikna işini uygulamanın kendi arayüzü yapıyor.
value Attribute'u — Çift URL Kod ÇözmeArama sayfasında GET parametrelerinin değerleri gizli form alanlarına yazılır. Bu noktada escape uygulanır — ama yanlış sırada.
Aynı q değeri tek yanıt içinde üç ayrı bağlamda kullanılır ve her biri farklı kod çözme derinliğine sahiptir:
| Bağlam | Kod çözme | Durum |
|---|---|---|
<script> bloğunda JS string | 1 kez | Güvenli |
Ana arama kutusu <input value="…"> | 1 kez | Güvenli |
Gizli form alanları <input type='hidden' value="…"> | 2 kez | Zafiyetli |
İşlem sırası şöyle:
İstemci girdisi : %2522
↓ $_GET çözümlemesi
PHP değişkeni : %22
↓ giriş filtresi → zararlı içerik görmüyor, ortada tırnak yok
↓ htmlspecialchars → kaçıracak karakter yok, değişiklik olmuyor
↓ urldecode → %22 çözülüyor
Sayfaya basılan : " ← ham tırnak, attribute'tan çıkış
Giriş filtresi ve escape birinci kod çözme katmanında çalışırken, çıktı ikinci katmandan besleniyor. Aynı payload'ın tek ve çift kodlanmış hâlleri karşılaştırıldığında fark net görülüyor:
| Gönderilen | Yanıt | Gizli alan çıktısı |
|---|---|---|
q=foo%22… (tek kodlama) | 302 Found | value="foo"…" — filtre yakalıyor |
q=foo%2522… (çift kodlama) | 200 OK | value="foo"><…>" — ham HTML |
Zafiyet q parametresine özgü değil. Gizli alan üreten blok, istekteki tüm GET parametreleri üzerinde dolaşır; tip ve alan üzerinde de ayrıca doğrulanmıştır.
name Attribute'u — Parametre Adında EnjeksiyonAynı blok her GET parametresi için şu yapıyı üretir:
<input type='hidden' name="<PARAMETRE ADI>" value="<PARAMETRE DEĞERİ>"/>
Escape yalnızca value tarafına uygulanır. name tarafına hiç uygulanmaz. Bu noktada çift kodlamaya da gerek yoktur — tek kodlama yeterlidir, çünkü ortada atlatılacak bir escape zaten yoktur.
Uydurulmuş bir parametre adı doğrudan name attribute'una ham olarak yazılır ve attribute'tan çıkılabilir. Parametre adı saldırgan kontrolünde olduğundan, uygulamanın tanıdığı bir parametre olmasına da gerek yoktur.
Bu üç noktanın 2 ve 3 numaralıları aynı kod bloğundan kaynaklanır ve bu blok altı ayrı formda tekrar eder: dilForm, adetForm, siralaForm, tkForm, ekForm, tmForm. Yani tek bir istekte enjeksiyon altı kez gerçekleşir.
Bloğun dinamik olduğu iki isteğin çıktısı karşılaştırılarak doğrulanmıştır:
İstek A: ?p=1&dil=0&alan=&tip=basit&gorunum=liste&q=…
Çıktı A: name="p" · name="alan" · name="tip" · name="gorunum" · name="q"
İstek B: ?p=2&dil=0&devam=…
Çıktı B: name="p" · name="devam"
Üretilen alanlar sabit bir listeden değil, doğrudan istekteki parametrelerden türetilmektedir. Dolayısıyla hem name hem value attribute'una yazılan içerik saldırgan kontrolündedir.
Saldırganın ihtiyacı olan tek şey, kurbanın açacağı bir bağlantı. Oturum açmasına, hesabının olmasına gerek yok.
action hedefi saldırgana çevriliyor. Doğrulandı.Etkilenen platform kütüphane üyelerinin kimlik bilgilerini ve kişisel verilerini barındırdığından, ele geçirilen hesaplar üzerinden üye kayıtlarına erişim mümkün olmaktadır.
Uygulama CSP kullanıyor ve script-src ile object-src nonce tabanlı; yani klasik script tabanlı XSS bu sayfalarda çalışmıyor. İlk bakışta bu, bulguyu "sadece içerik tahrifi" seviyesine indirir gibi görünüyor.
Politikanın tamamı şu:
Content-Security-Policy: script-src 'nonce-...'; object-src 'nonce-...'; frame-ancestors 'self'
form-action yok. default-src de yok — dolayısıyla tanımlanmamış direktifler için geri düşülecek bir varsayılan da yok. Sonuç: formun saldırganın sunucusuna POST atması tarayıcı tarafından hiçbir şekilde engellenmiyor.
Kimlik bilgisi çalmak için JavaScript çalıştırmak gerekmiyor. Düz HTML yetiyor, CSP de düz HTML'i durdurmuyor.
Birincil
İlgili
CVE kaydında birincil zayıflık CWE-79 olarak sınıflandırılmıştır. Kök neden düzeyinde CWE-116 daha açıklayıcıdır: üç noktanın da nedeni çıktı escape'inin ya hiç uygulanmaması ya da yanlış sırada uygulanmasıdır.