Hızlı cevap: Güvensiz çıktı işleme, bir dil modelinin ürettiği metnin doğrulanmadan ve temizlenmeden başka bir bileşene aktarılmasıyla ortaya çıkan açıktır. Model çıktısı bir web sayfasına basıldığında tarayıcıda XSS, bir URL alıcısına verildiğinde SSRF, bir kabuk komutuna veya veritabanı sorgusuna konduğunda komut enjeksiyonu ve SQL enjeksiyonu doğabilir. Buradaki asıl hata modelde değil, modelin çıktısına güvenilir bir kaynakmış gibi davranılmasındadır. DSET bu açığı yerel yapay zekâ motoru KAOS ile test eder ve her bulguyu çalışan bir kanıtla doğrular.

Yapay zekâ uygulamalarında güvenlik tartışması çoğu zaman modele giren girdiye, yani prompt injection'a odaklanır. Oysa riskin yarısı modelden çıkan veridedir. Bir model güvenilir bir veri kaynağı değildir, saldırganın yönlendirmesiyle istediği metni üretebilir. Bu metin bir sonraki sistemde sorgusuz işlenirse, on yıllardır bildiğimiz web açıkları yeni bir kılıkta geri döner. Bu yazı, güvensiz çıktı işlemenin ne olduğunu, hangi senaryoları doğurduğunu ve DSET ile KAOS yaklaşımını anlatır.

Güvensiz çıktı işleme nedir

OWASP'ın büyük dil modeli uygulamaları için listesinde güvensiz çıktı işleme ayrı bir madde olarak yer alır. Tanım basittir: uygulama, modelin ürettiği çıktıyı kullanıcı tarafından üretilmiş güvenilmez bir veri gibi değil, güvenilir bir sistem çıktısı gibi ele alır. Bir kullanıcıdan gelen veriyi doğrulamadan veritabanına koymazsınız, aynı titizlik model çıktısı için de geçerli olmalıdır. Çünkü saldırgan, prompt ile modeli belirli bir metni üretmeye zorlayabilir ve o metin doğrudan bir sonraki bileşene akarsa, modeli bir enjeksiyon aracı olarak kullanmış olur.

Hangi senaryoları doğurur

Çıktının nereye aktığı, hangi açığın oluşacağını belirler. Aynı güvensiz çıktı, farklı hedeflerde farklı sonuç verir.

Çıktının gittiği yer Oluşan açık Tipik sonuç
Tarayıcıda HTML olarak gösterim Depolanmış veya yansıyan XSS Oturum çalma, hesap ele geçirme
Sunucu tarafı URL çağrısı SSRF İç servislere erişim, bulut üstverisi sızıntısı
Kabuk komutu olarak çalıştırma Komut enjeksiyonu, RCE Sunucuda kod çalıştırma
Veritabanı sorgusuna yerleştirme SQL enjeksiyonu Veri sızıntısı, veri değiştirme
Dosya yolu olarak kullanma Dizin gezinme Yetkisiz dosya okuma

Tablonun özü şu: güvensiz çıktı işleme tek bir açık değil, model çıktısının güvenildiği her noktada yeniden beliren bir açık ailesidir. Bu yüzden modelden çıkan veri, tıpkı kullanıcıdan gelen veri gibi, her hedefe özgü biçimde temizlenmeli ve kodlanmalıdır. Bu temizleme mantığı, klasik güvenli kodlama ilkeleriyle birebir örtüşür; kaynak kodu güvenlik denetimi ve güvenli kod inceleme burada doğrudan devreye girer.

Prompt injection ile birlikte neden daha tehlikeli

Güvensiz çıktı işleme tek başına da bir açıktır, ama asıl tehlike prompt injection ile birleştiğinde ortaya çıkar. Saldırgan önce bir prompt ile modeli belirli bir zararlı metni, örneğin bir XSS yükünü üretmeye yönlendirir, ardından uygulama o metni doğrulamadan sayfaya basınca açık tetiklenir. İki açık bir zincir oluşturur: biri modele ne üreteceğini söyler, diğeri o üretilenin zarar vermesine izin verir. Bu zincir mantığı, yapay zekâ uygulama testinin neden uçtan uca yürütülmesi gerektiğini gösterir.

Savunma katmanı ve güvenlik duvarı ilişkisi

Model çıktısını filtrelemek için bir yapay zekâ güvenlik duvarı kullanmak faydalı bir katmandır, ama tek başına yeterli değildir; bu katmanın nasıl çalıştığı için yapay zekâ güvenlik duvarı ve guardrails konusu başvuru noktasıdır. Asıl savunma, çıktının aktığı her bileşende hedefe özgü kodlama yapmaktır. Tarayıcıya giden çıktı HTML olarak kodlanır, sorguya giden çıktı parametreli sorgu ile ayrılır, komuta giden çıktı ise hiçbir zaman doğrudan kabuğa verilmez.

Ne zaman test edilir

Doğru pratik, modeli bir kullanıcı arayüzüne veya bir arka uç iş akışına bağlayan her yapay zekâ özelliği yayına çıkmadan önce test yapmaktır. Özellikle modelin çıktısını otomatik olarak bir işleme, bir e postaya veya bir API çağrısına dönüştüren akışlar yüksek risklidir. Bir bulgu doğrulandıktan sonra düzeltmenin gerçekten işe yaradığını görmek için yeniden test ve remediation doğrulaması uygulanır.

KAOS ve DSET yaklaşımı

DSET, güvensiz çıktı işleme açığını daha geniş yapay zekâ ve LLM uygulama sızma testi hizmetinin parçası olarak, yerel yapay zekâ motoru KAOS ile test eder. KAOS, modeli kontrollü yüklerle belirli çıktıları üretmeye yönlendirir ve o çıktının bir sonraki bileşende temizlenmeden işlenip işlenmediğini sınar. Bulduğu her açığı, kanıt temelli doğrulama ilkesiyle çalışan bir kanıtla raporlar. Fark şudur: bir çıktının teorik olarak tehlikeli olabileceğini söylemekle yetinilmez, o çıktının gerçekten tarayıcıda çalıştığı veya sunucuda bir isteği tetiklediği kanıtlanır.

Sık sorulan sorular

Modelin çıktısını neden güvenilmez kabul etmeliyim, sonuçta onu ben çalıştırıyorum? Modeli siz çalıştırıyor olsanız da, modele ne üreteceğini söyleyen girdi büyük ölçüde dış kaynaklıdır. Kullanıcı mesajları, çekilen web sayfaları, belgeler ve veritabanı kayıtları modelin çıktısını etkiler. Saldırgan bu girdilerden birini kontrol ediyorsa, modelin çıktısını da dolaylı olarak kontrol eder. Bu yüzden çıktı, kaynağı ne olursa olsun güvenilmez kabul edilmelidir.

Bir yapay zekâ güvenlik duvarı bu açığı tamamen çözer mi? Hayır, güvenlik duvarı yardımcı bir katmandır ama tek savunma olamaz. Filtreler atlatılabilir ve her zararlı deseni önceden bilmek mümkün değildir. Kalıcı çözüm, çıktının aktığı her noktada hedefe özgü kodlama ve doğrulama yapmaktır, güvenlik duvarı bunun yerine değil üstüne eklenir.

Bu açık klasik web güvenliğinden farklı mı? Teknik olarak sonuç aynıdır, çıkan açık XSS, SSRF veya komut enjeksiyonudur. Fark, açığın kaynağındadır: zararlı içerik doğrudan kullanıcıdan değil, modelin ürettiği metinden gelir. Bu yüzden klasik web güvenliği bilgisi geçerlidir ama modelin bir enjeksiyon kaynağına dönüşebileceği yeni bir bakış eklenmelidir.

Kaynaklar

Yapay zekâ özelliklerinizin çıktısını kanıt temelli bir testle incelemek için DSET ile iletişime geçin. Ankara Hacettepe Teknokent laboratuvarımızdan yapay zekâ uygulama sızma testi ve danışmanlık sağlıyoruz.