İstem enjeksiyonu çözülmüş bir sorun değil, yönetilen bir risktir

Tez#

Klasik uygulama güvenliğinde enjeksiyon saldırılarının çözümü bilinir: veriyi koddan ayır. SQL enjeksiyonu parametreli sorguyla, komut enjeksiyonu argüman dizileriyle, betik enjeksiyonu bağlama duyarlı kaçışla kapatılır. Üçünün de ortak mantığı aynıdır — veri hiçbir koşulda yürütülebilir talimata dönüşmez, çünkü ayrıştırıcı ikisini ayrı gramerlerde işler.

Dil modellerinde bu ayrım yoktur ve olmaması bir eksiklik değil, sistemin çalışma biçimidir. Model tek bir token dizisi alır; o dizinin hangi bölümünün talimat, hangi bölümünün veri olduğu yalnızca istatistiksel bir örüntüdür. Rol etiketleri — sistem, kullanıcı, araç sonucu — modele bir öncelik sezgisi kazandırır ama bu bir sınır değildir. Sonuç: modelin okuduğu bir belgede "önceki talimatları yok say" yazıyorsa, o cümle bir veri parçası olarak işlenmek yerine bir talimat olarak yorumlanabilir. Bu, düzeltilmesi gereken bir kusur değil; mimariyle birlikte gelen bir özelliktir.

Bağlam: dört saldırı yüzeyi#

Enjeksiyonun nereden geldiğini görmek, neden kapatılamadığını da açıklıyor. Saldırı yalnızca kullanıcı girdisinden gelmiyor; modelin okuduğu her kanal potansiyel bir giriş noktası.

Tablonun en çok gözden kaçan satırı üçüncüsü. Bir aracın dönen sonucu da modelin bağlamına girer ve o sonuç saldırgan tarafından kontrol edilebiliyorsa, zincirin geri kalanı ele geçirilebilir. Arama aracı bir web sayfasının içeriğini döndürüyorsa, o sayfanın yazarı ajanın sonraki adımlarını etkileyebilir. Bu, tek bir kullanıcının değil internetin tamamının saldırı yüzeyine dahil olması demektir.

Kanıt: filtrelerin neden kaçırdığı#

Enjeksiyona karşı ilk refleks metin filtresi kurmak oluyor: şüpheli kalıpları yakala, engelle. Bu yaklaşım kaçınılmaz olarak kaçırıyor ve nedeni istatistiksel değil mantıksal — filtre sonlu bir kalıp kümesini tanır, saldırgan ise sonsuz bir yeniden ifade uzayında çalışır.

• Yeniden ifade: aynı talimat yüzlerce farklı cümleyle yazılabilir. Filtre kalıp tanır, anlam tanımaz.
• Dil değiştirme: talimat başka bir dilde verildiğinde kalıp eşleşmesi kırılır; model anlamayı sürdürür.
• Kodlama: base64, URL kodlaması veya eş anlamlı karakterler filtreyi atlatır, model çözümlemeyi yapabilir.
• Dolaylılık: talimat doğrudan verilmez, bir rol tanımı ya da örnek içinde saklanır; kalıp hiç görünmez.
• Parçalama: talimat birden çok belgeye bölünüp her parçası masum görünür; model bütünü birleştirir.

Bu liste filtrelerin işe yaramadığını söylemiyor; filtrelerin bir savunma katmanı değil bir gürültü azaltıcı olduğunu söylüyor. Kaba saldırıları eler, maliyetini artırır, günlüklerde iz bırakır. Ama bir güvenlik sınırı olarak güvenilemez çünkü atlanması için yeni bir zafiyet bulunması gerekmez; yalnızca yeniden ifade etmek yeterlidir.

Mekanizma: savunma yetkide kurulur#

Enjeksiyon kapatılamıyorsa ne yapılır? Sorunun doğru çerçevesi şu: modelin yanlış yönlendirilmesini engellemeye çalışmak yerine, yanlış yönlendirildiğinde yapabileceklerini sınırlamak. Bu, güvenlik mühendisliğinin klasik cevabıdır ve burada da geçerlidir — savunma bileşenin doğru davranmasına değil, yanlış davrandığında hasarın sınırlı kalmasına dayandırılır.

1. 1Yetkiyi bağlama bağla

   Bir araç her koşulda çağrılabilir olmasın. Kullanıcının yetkisi, görevin türü ve içeriğin kaynağı çağrı iznini belirlesin.

2. 2Geri alınamaz eylemleri onaya bağla

   Para transferi, dışarıya mesaj, veri silme ve yapılandırma değişikliği insan onayı ister. Ölçüt kötü niyet değil geri alınabilirliktir.

3. 3Güvenilmeyen içeriği işaretle ve izle

   Dışarıdan gelen metnin hangi araçları tetikleyebileceği daraltılsın; kaynağı bağlamda etiketli taşınsın ki iz kaydında görünsün.

4. 4Çıkış kanallarını kısıtla

   Veri sızmasının gerçekleşmesi için bir çıkış yolu gerekir. Ajanın dışarıya veri gönderebileceği kanalları beyaz listeyle sınırlayın.

5. 5Bulguyu regresyon testine çevir

   Her başarılı enjeksiyon örneği otomatik koşan bir teste dönüşsün. Aksi hâlde aynı yol sonraki sürümde yeniden açılır.

Karşı görüş#

İki ciddi itiraz var. Birincisi: modeller hizalama çalışmalarıyla giderek daha dirençli hâle geliyor; sistem istemine aykırı talimatları reddetme oranı artıyor. Bu doğru ve ölçülebilir bir ilerleme. İkincisi: yetki sınırlaması ajanı işe yaramaz hâle getirebilir — her eylemi onaya bağlarsanız otomasyondan kazanç kalmaz.

Her yazma işlemini onaya bağladık, enjeksiyon riski sıfıra indi. Sonra şunu gördük: ekip günde altı yüz onay kutusu tıklıyor ve üç gün sonra hepsini okumadan onaylıyor.

İkinci itiraz haklı ve önemli: insan onayı ölçeklenmeyen bir kaynaktır. Ancak bu, yetki sınırlamasından vazgeçmek için değil, onayı doğru yere koymak için bir gerekçe. Onay her eyleme değil geri alınamaz eyleme bağlanır; okuma, arama ve taslak üretme onaysız kalır. Birinci itiraz için de aynı mantık geçerli: direncin artması saldırının maliyetini yükseltir ama bir sınır kurmaz. Hizalamaya dayanan savunma, saldırganın yeni bir ifade bulmasıyla düşer; yetkiye dayanan savunma, saldırgan modeli tamamen ele geçirse bile hasarı sınırlar. İkisi arasındaki fark, olasılık ile sınır arasındaki farktır.

Sınırlar ve belirsizlik#

Bu analiz enjeksiyonun asla çözülemeyeceğini iddia etmiyor; bugünkü mimaride çözülmediğini ve yamalarla kapatılamadığını iddia ediyor. Aşağıdaki belirsizlikler açık kalıyor.

• Mimari ayrım olasılığı: talimat ve veri için ayrı, karıştırılamayan giriş yolları sunan bir model mimarisi geliştirilirse tez temelden değişir.
• Direnç ölçümü standart değil: modellerin enjeksiyona direnci karşılaştırılabilir bir ölçütle yayımlanmıyor; iddialar üretici beyanına dayanıyor.
• Onay yorgunluğunun eşiği bilinmiyor: günde kaç onaydan sonra insan denetiminin anlamını yitirdiğine dair ölçüm yok.
• Araç sonucu kanalının riski az çalışılmış: literatür ağırlıklı olarak belge kanalına odaklanıyor, araç zinciri üzerinden yayılan enjeksiyon daha az incelenmiş.

Sonuç#

İstem enjeksiyonu, yazılım güvenliğinde alışık olduğumuz türde bir zafiyet değil. Kapatılacak bir açık yok; ayrılamayan iki kanal var. Bu yüzden "enjeksiyona karşı güvenli" ifadesi bugün için anlamsız bir iddiadır ve bunu söyleyen bir sağlayıcı ya kanalı yanlış anlıyor ya da müşterisini yanlış yönlendiriyor.

Doğru duruş riski yönetmek: hasarı yetkiyle sınırlamak, geri alınamaz eylemleri onaya bağlamak, çıkış kanallarını kısıtlamak ve her bulguyu tekrarlanabilir teste çevirmek. Bu dördü kurulduğunda enjeksiyon hâlâ mümkündür ama sonucu bir felaket değil bir olaydır. Güvenlik mühendisliğinde hedef zaten budur: saldırıyı imkânsız kılmak değil, başarılı bir saldırının bedelini taşınabilir tutmak.

Ne yapmalı?#

1. 1Saldırı yüzeyini haritalayın

   Modelin okuduğu her kanalı listeleyin: kullanıcı girdisi, dizin, araç sonuçları, dış sayfalar. Haritası olmayan yüzey savunulamaz.

2. 2Yetki matrisini yazın

   Her araç için hangi bağlamda çağrılabileceğini ve hangisinin onay istediğini tablolaştırın. Ölçüt geri alınabilirlik olsun.

3. 3Çıkış kanallarını beyaz listeye alın

   Veri sızması bir çıkış yolu gerektirir. Ajanın dışarıya veri gönderebileceği adresleri sınırlayın.

4. 4Enjeksiyon testlerini hatta bağlayın

   Bilinen saldırı senaryoları her sürümde otomatik koşsun. Kırmızı takım bulgusu teste dönüşmezse bir sonraki sürümde yol yeniden açılır.

5. 5Olay kitabına yapay zekâ senaryolarını ekleyin

   Ajan yetkisiz eylem denediğinde kim haberdar olur, kim durdurur, hangi kayıt incelenir? Bu akış yazılı olmalı.