Hızlı Enjeksiyon Bir Güvenlik Açığı mıdır?


Aynı Güvenlik Açığı Modeli

Arkadaşım Joseph Thacker’ın Prompt Injection ve bunun bir güvenlik açığı olup olmadığı hakkındaki blog yazısına yanıt vermek istiyorum.

Hızlı Enjeksiyon Bir Güvenlik Açığı Değildir (Çoğu Zaman)

josephthacker.com

Hızlı Enjeksiyon Bir Güvenlik Açığı Değildir (Çoğu Zaman)

Anında enjeksiyon neredeyse hiçbir zaman AI güvenlik açıklarının temel nedeni değildir; asıl sorun, modelin ne yapmasına izin verildiğidir

Ben de Joseph’le hızlı enjeksiyonun bir güvenlik açığı olup olmadığı konusunda tartışan arkadaşlardan biriydim.

Ben “Evet” tarafındayım ve gerekçemi belirtmek istiyorum.

Ama önce, insanı tam tersi bir pozisyona ikna etmek istiyorum, yani Hızlı Enjeksiyon Olumsuz bir güvenlik açığı.

Bu görüşe göre, hızlı enjeksiyon aslında sadece bir dağıtım mekanizmasıdır. Bir güvenlik açığı için değil, bir saldırı için hedefler bir güvenlik açığı.

Yani bu, bahçeye zehirli su gönderen bir hortum gibidir.

  • Hortum güvenlik açığı değildir (bu dağıtım mekanizmasıdır)
  • Zehir güvenlik açığı değildir (saldırıdır)
  • Zehirlenmeye yatkınlık güvenlik açığıdır
  • Ve hedef bahçedeki bitkiler

Bu oldukça ikna edici, o yüzden şimdi size neden aynı fikirde olmadığımı söyleyeyim.

Bu konuda en sevdiğim benzetme Papa’dır.

Papa’nın kalabalıkların arasına girmesi ve binlerce insana son derece yakın olması gerekiyor. Bu fiziksel yakınlık bir güvenlik açığıdır. Ona karşı kullanılabilecek asıl saldırı (zehirleme, havalı tüfek, ateş etme, yumruklama) saldırıdır. Onun kırılganlığı başka bir güvenlik açığı olabilir.

Ancak bunu risk yönetimi perspektifinden düşünürsek, ilk etapta bu günde binlerce insana yakın bir yerde bulunacak olması kesinlikle bir güvenlik açığıdır.

Bunu sessizce bir iş akışı olarak kabul etmek zorunda kalmamız, onu daha az savunmasız yapmaz.

Hızlı enjeksiyonla aynı şey. Uygulamamızda yapay zeka aracılarını kullanacaksak, ses veya metin yoluyla insan dilini kullanmak zorundayız; bu da sonuçta zarar verebilecek komutların enjekte edilebileceği bir metne dönüşür.

Bu, uygulamanın genel riskini düşünürken kesinlikle dikkate alınması gereken bir güvenlik açığıdır.

İşte buna bakmanın başka bir yolu.

SQL enjeksiyonu evrensel olarak bir güvenlik açığı olarak sınıflandırılır (CWE-89). Hiç kimse SQLi’nin şöyle olduğunu iddia etmiyor:

Sadece bir saldırı vektörü.

Veya:

Sadece bir iletim hattı.

Veritabanının sorgu yapısı ile kullanıcı tarafından sağlanan veriler arasında ayrım yapamaması nedeniyle buna güvenlik açığı diyoruz.

Desen aynıdır:

  • SQLi: Kullanıcı girişi SQL komutları olarak yorumlanır
  • Hızlı enjeksiyon: Kullanıcı girişi sistem talimatları olarak yorumlanır

Her ikisi de aynı mimari kusurdan kaynaklanıyor; kontrol düzleminin veri düzlemiyle karıştırılması. Güvenlik endüstrisi, girdi kanalının güvenlik açığı olmadığının farkına varmak için onlarca yıl harcadı; Güvenlik açığı, ayrıştırma katmanındaki kod ve verilerin temeldeki karışıklığından kaynaklanıyordu.

CWE-89’u bir güvenlik açığı olarak kabul edersek, entelektüel tutarlılık, hızlı enjeksiyon için aynı sınıflandırma mantığını uygulamamızı gerektirir.

Bazıları Papa’nın benzetmesine karşı çıkıyor:

Yakınlık bir güvenlik açığı değildir; yalnızca operasyonel bir maruziyettir. Güvenlik açığı, yetersiz tarama veya kurşun geçirmez camın olmaması olabilir.

Ama burada gözden kaçırılan şey şu.

Yakınlığın bir güvenlik açığı olduğunu düşünürsek, eleştirel düşüncemizi açık tutarız. Hedefleri yeniden değerlendirme seçeneğim var ve belki:

  1. Papa’yı holografik olarak yansıtın
  2. Bir çift vücut kullanın
  3. Vesaire.

Başka bir deyişle, hedefe ulaşmanın riski azaltan yeni yollarını bulabiliriz.

Yakınlığı şu şekilde göz ardı edersek:

İşlerin nasıl yürüdüğünü.

Veya:

Rolün doğasında var.

Bu yaratıcılık hatlarını kapatıyoruz.

Aynı durum LLM’ler için de geçerlidir. Eğer dersek:

Yüksek Lisans’ların metin girişini kabul etmesi gerekir, bu doğuştan gelen bir durumdur.

Alternatif aramayı bırakıyoruz. Ama şunu söylersek:

Talimatları verilerden ayırt edememek bir güvenlik açığıdır.

Talimat imzalama, donanım düzeyinde ayırma, tamamen yeni yaklaşımlar gibi yeni mimariler keşfedebiliriz.

Yapay zeka arkadaşım Kai bu argümanı bir araya getirdi. Evet, gerçekten – aslında bunun için oluşturulmuş bir kırmızı takım yeteneğim var. Başlangıçta bana çok şey öğreten, altını çizmeye değer bir hata yaptı:

Papa benzetmesi başarısız oluyor çünkü Papa teorik olarak kalabalıklardan izole edilebilirken Yüksek Lisans’lar dil girdisinden izole edilemez.

Ancak bu bir kategori hatasıdır.

LLM’nin hedefleri yoktur; başvuru hedefleri var. Yüksek Lisans sadece bir bileşendir, tıpkı Papa’nın fiziksel bedeninin bir bileşen olması gibi. “Papa’nın bedeninin amacı ne” diye sormuyorsunuz; “Papa’nın amacı ne” diye soruyorsunuz.

Doğru paralel:

Hedefleri Olan Varlık Bileşen Bileşendeki Güvenlik Açığı
Papa Fiziksel beden/varlık Kalabalığa yakın olmalı
Başvuru Yüksek Lisans Talimatları verilerden ayırt edemiyorum

Hem Papa’nın hem de uygulamanın hedefleri var (sadıklara hizmet etmek/kullanıcıya hizmet etmek). Her ikisi de risk yaratan doğal sınırlamalara sahip bileşenleri kullanır. Her ikisinin de mimarisi potansiyel olarak yeniden tasarlanabilir: Hologramlar yoluyla Papa, LLM’nin güvenlik açığı profili olmadan aynı hedefe ulaşan farklı mimariler aracılığıyla uygulama.

Benim görüşüme göre Prompt Injection bir güvenlik açığıdır çünkü:

  1. Saldırıya uğrayabilecek ve sistemin genel risk düzeyine katkıda bulunan teknik bir sorundur
  2. SQL enjeksiyonuna oldukça benzer, yani talimatları verilerden ayırt edememe
  3. Böyle bir sistemi ele alınamayan bir arka plan riski olarak düşünmek, bu riskin nasıl azaltılacağına dair yaratıcı düşünceyi devre dışı bırakır

Bu güvenlik açığını iş yapmanın bir maliyeti olarak kabul etmek zorunda kalabileceğimiz gerçeği (en azından 2025’te) onu daha az güvenlik açığı yapmıyor.

Papa yakınlık riskini kabul ediyor çünkü görevi bunu gerektiriyor. Kuruluşlar, uygulamalarının yapay zeka destekli arayüzlerle etkileşimde bulunmasını gerektirdiği için Prompt Injection riskini kabul eder. Haklısın.

Ancak bu mevcut gerçekliği kabul etmek, onu arka plandaki gürültü olarak silmekle aynı şey olmamalıdır.

Savunmacılar ve araştırmacılar olarak, bunu aktif bir güvenlik açığı gibi ele almamız gerekiyor, böylece zaman içinde ortaya çıkardığı riski azaltabilir ve potansiyel olarak ele alabiliriz.



Source link