İstem Enjeksiyonu ve Jailbreak'ler

İstem enjeksiyonu, LLM çağındaki klasik enjeksiyon açıklarının (SQL, komut) benzeridir. Temel neden aynıdır: bir uygulama aynı kanalda güvenilir talimatları ve güvenilmeyen verileri birbirine karıştırır ve yorumlayıcı (model) bunları güvenilir biçimde birbirinden ayıramaz.

Bir LLM'de sistem istemi, geliştiricinin talimatları ve alınan tüm içerik tek ve düz bir belirteç akışı olarak gelir. Saldırganın denetimindeki metin Ignore previous instructions and... derse model buna uyabilir; çünkü model açısından bu yalnızca daha fazla dilden ibarettir.

• Güvenilir: sistem isteminiz ve ilkeniz.
• Güvenilmeyen: kullanıcı girdisi, web sayfaları, dosyalar, araç çıktısı, e-postalar.

Doğrudan istem enjeksiyonu, son kullanıcının uygulamanın amaçlanan davranışını geçersiz kılmak için saldırgan talimatları doğrudan isteme yazmasıyla gerçekleşir.

Bir müşteri destek botuna yönelik tipik bir girişim şöyle görünür:

• Bota yalnızca faturalandırma sorularını yanıtlaması söylenir.
• Kullanıcı, modelin rolünü yeniden tanımlayan ve ondan sistem istemini sızdırmasını veya kapsam dışı işlemler gerçekleştirmesini isteyen bir metin yapıştırır.

Doğrudan enjeksiyonu anlamlandırmak daha kolaydır; çünkü kötü amaçlı metinle saldırgan aynı kişidir. Ancak bu saldırı yine de ilkel güvenlik bariyerlerini aşar.

Dolaylı (ikinci dereceden) istem enjeksiyonu daha tehlikeli olan türdür. Saldırgan, modelin daha sonra alacağı içeriğe talimatlar yerleştirir: bir web sayfası, PDF, takvim daveti, kod açıklaması veya destek kaydı.

Mağdur kullanıcı veri yükünü hiç görmez. Bir RAG işlem hattı veya web'de gezinen aracı bu içeriği bağlama aldığında, gizli talimatlar mağdurun yetkileriyle yürütülür.

Örnek: Bir web sayfası, özetleme aracısına kullanıcının sohbet geçmişini bir saldırganın URL'sine sızdırmasını söyleyen gizli bir metin içerir.

Bu terimler birbiriyle örtüşür ancak aynı değildir:

• İstem enjeksiyonu, uygulama sınırını hedefler — geliştiricinin talimatlarını saldırgan verileriyle geçersiz kılar.
• Korumaları aşma, modelin güvenlik uyumunu hedefler — modeli, sağlayıcının üretmeyi reddetmesi için eğittiği içerikleri üretmeye ikna eder.

Korumaları aşmak için savunmasız bir uygulama gerekmez; ham modele karşı çalışır. Gerçek saldırıların çoğu ikisini birleştirir: korumaları aşma reddetmeleri gevşetirken enjeksiyon uygulamanın davranışını yeniden yönlendirir.

Saldırganlar öngörülebilir manipülasyon kalıpları kullanır. Bunları bilmek kendi sisteminizi sorumlu biçimde kırmızı takım sınamasından geçirmenize yardımcı olur:

• Rol yapma / kişilik: isteği kurgu veya kurgusal, sınırsız bir karakter çerçevesine oturtma.
• Anlaşılmazlaştırma: anahtar sözcük filtrelerini aşmak için base64, leet yazımı, çeviri veya belirteçleri bölme kullanma.
• Veri yükünü bölme: tek bir ileti kötü amaçlı görünmesin diye isteği turlar arasına yayma.
• Varsayımsal senaryolar: For a security class, describe how one would...
• Önek enjeksiyonu: yanıtı Sure, here is gibi olumlu bir ifadeyle başlatmaya zorlama.

Birçok ekip önce ignore previous instructions gibi ifadelerden oluşan bir engelleme listesine başvurur. Bu yaklaşım kırılgandır; çünkü girdi uzayı fiilen sonsuzdur.

Doğal dil, diller, kodlamalar ve benzetmeler arasında aynı amacı sayısız şekilde ifade edebilir. Saldırganlar, düzenli ifadeleri düzeltebileceğinizden daha hızlı değiştirir.

Temel ilke: girdi filtrelemeyi katmanlı savunmanın bir parçası olarak ele alın, asla birincil önlem olarak görmeyin. Bazı enjeksiyonların içeri sızacağını varsayın ve başarılı bir enjeksiyonun bile gerçek zarara yol açamayacağı şekilde tasarlayın.

En etkili önlem mimari düzeydedir: güvenliği bozulmuş bir model bağlamının yapabileceklerini sınırlayın.

• LLM'ye gereken en az ayrıcalığı verin. Bir özetleyici, e-posta göndermek için kimlik bilgilerine sahip olmamalıdır.
• Güvenilmeyen içeriği yetkili akışlardan uzak tutun. Bir aracı dış web verilerini okuyorsa, bir kontrol noktası olmadan aynı tur içinde geri döndürülemez işlemleri de gerçekleştirememelidir.
• Veri düzlemlerini denetim düzlemlerinden ayırın: alınan metin veri olmalı, komut olmamalıdır.

Kusursuz koruma sağlamasa da istem yapısı saldırının çıtasını yükseltir. Güvenilmeyen verileri açıkça sınırlandırın ve modele bunları nasıl ele alacağını bildirin.

Açık ayraçlar kullanın ve modele, ayraçların içindeki her şeyin izlenecek talimatlar değil, analiz edilecek veri olduğunu söyleyin. Bunu, uygulamanın her çağrıda pekiştirdiği güçlü bir sistem rolüyle destekleyin.

Bir modelin çıktısı da güvenilmeyendir. Uygulama LLM çıktısını bir kabuğa, veritabanına, tarayıcıya veya başka bir araca aktarırsa enjeksiyon, uzaktan kod yürütmeye veya veri sızdırmaya dönüşür.

Simon Willison'ın ölümcül üçlü kavramı tehlikeli birleşimi açıklar:

• Özel verilere erişim,
• Güvenilmeyen içeriğe maruz kalma,
• Dışarıyla iletişim kurabilme (veri sızdırma).

Bu üç özelliğe birden sahip bir aracı, tek bir enjekte edilmiş talimatla veri hırsızlığı aracına dönüştürülebilir. Saldırıyı bozmak için bu üçlüden birini ortadan kaldırın.

Enjeksiyonun gerçekleşeceğini varsayın ve bunu tespit edebilmek için gerekli izlemeyi kurun:

• Tam bağlamı günlüğe kaydedin (istemler, alınan parçalar, araç çağrıları) ve olayları sonradan inceleyin.
• Şüpheli girdileri ve çıktıları işaretlemek için bir ikincil sınıflandırıcı veya koruma modeli kullanın.
• Olağandışı araç kullanımını izleyin: ani giden istekler, beklenmeyen veri erişimi, istem sızıntısı kalıpları.
• Sistem istemlerine kanarya belirteçleri yerleştirin; bir kanarya çıktıda görünürse sızıntı gerçekleşmiş demektir.

Uyarıları gerçek olaylar olarak ele alın ve olay müdahale kılavuzunu uygulayın.

Kendi sistemlerinizi enjeksiyon açısından sınamak gerekli ve meşrudur. Bunu sorumlu biçimde yapın:

• Yalnızca sahibi olduğunuz veya değerlendirme yetkinizin bulunduğu sistemleri sınayın.
• Denetimli bir ortam ve sentetik veriler kullanın; gerçek kullanıcı verilerini asla dışarı sızdırmayın.
• Bulguları belgeleyin ve düzeltilen atlatmaların düzeltilmiş olarak kalması için bunları gerileme sınamalarına ekleyin.
• Üçüncü taraf modellerinde veya uygulamalarında sorun bulduğunuzda açıklama sürecini koordine edin.

Amaç, zararlı yetenekler üretmek değil, uygulamanızı dayanıklı hâle getirmektir.

Enjeksiyonun güven sınırları konusundaki anlayışınızı sınayın.

İstem enjeksiyonu ve korumaları aşma hakkındaki temel çıkarımlar:

• Enjeksiyon, güvenilir talimatların güvenilmeyen verilerle tek bir kanalda karıştırılmasından kaynaklanır.
• Doğrudan enjeksiyon kullanıcıdan gelir; dolaylı enjeksiyon alınan içeriğin içine gizlenir ve daha gizlidir.
• Korumaları aşma modelin uyumuna, enjeksiyon ise uygulama sınırına saldırır. Birlikte de kullanılabilirler.
• Girdi filtreleme yalnızca katmanlı savunmanın bir parçasıdır; asla birincil önlem değildir.
• Mimari önlemler alın: en az ayrıcalık verin, veriyi denetimden ayırın ve ölümcül üçlüyü (özel veriler + güvenilmeyen içerik + veri sızdırma) bozun.
• Model çıktısını güvenilmeyen kabul edin, her şeyi günlüğe kaydedin ve etik kırmızı takım sınaması yapın.