بیک ڈور کے طور پر براؤزر: کلائنٹ سائیڈ ایل ایل ایم سیکرٹ ایکسٹریکشن ڈیمیسٹیفائیڈ | B4N1

بیک ڈور کے طور پر براؤزر: کلائنٹ سائیڈ ایل ایل ایم سیکرٹ ایکسٹریکشن ڈیمیسٹیفائیڈ

1 month ago · b4n1 Read time: 7 min

ایک بیک ڈور کے طور پر براؤزر: کلائنٹ سائیڈ ایل ایل ایم سیکرٹ ایکسٹریکشن ڈیمیسٹیفائیڈ

کافی عرصے سے، ہم نے "AI سیکیورٹی وارننگز" کو دور دراز کے خطرات یا علمی تجسس کے طور پر سمجھا ہے۔ ہم نے فوری انجیکشن، جیل بریک، اور ڈیٹا لیک ہونے کے بارے میں سنا ہے خاموش لہجے میں، جس کے بعد اکثر کندھے اچکاتے ہیں اور "ہم اس تک پہنچ جائیں گے۔" تاہم، حالیہ انٹرایکٹو مظاہروں نے اس آرام دہ بھرم کو توڑ دیا ہے۔ یہ اب کوئی نظریاتی کمزوری نہیں ہے۔ یہ لارج لینگویج ماڈلز (LLMs) سے حساس معلومات نکالنے کے لیے ایک لائیو، براؤزر پر مبنی، کلائنٹ سائیڈ ایکسپلائٹ ہے [2]۔ اگر آپ LLM سے چلنے والی ایپلی کیشنز کو تعینات کر رہے ہیں، خاص طور پر کوئی بھی ویب کا سامنا ہے، تو آپ کا "مستقبل کا مسئلہ" ایک بہت ہی موجودہ، بہت ہی عوامی، اور ممکنہ طور پر انتہائی شرمناک ذمہ داری بن گیا ہے۔

یہ کوئی اور عام "AI خطرناک ہے" کی سرخی نہیں ہے۔ یہ اس بات کا ایک مخصوص، ٹھوس مظاہرہ ہے کہ کس طرح ایک بدنیتی پر مبنی اداکار، صرف اپنے براؤزر کا استعمال کرتے ہوئے، آپ کے LLM کو حساس معلومات کو ظاہر کرنے پر مجبور کر سکتا ہے۔ ایک لمحے کے لیے اس پر غور کریں۔ یہ پیچیدہ سرور سائیڈ حملوں یا گہرے ماڈل کے خود شناسی کے بارے میں نہیں ہے۔ یہ تعامل کی پرت کے بارے میں ہے — آپ کی درخواست کا بالکل سامنے کا دروازہ — جس کا کچھ احتیاط سے تیار کردہ کرداروں سے فائدہ اٹھایا جا رہا ہے۔ یہ کسی ایسے شخص کا ڈیجیٹل مساوی ہے جو آپ کے سمجھے جانے والے محفوظ چیٹ بوٹ کے لیے صحیح جملہ تیار کرتا ہے، اور یہ فرضی طور پر اہم ڈیٹا کے حوالے کرتا ہے، اکثر تھوڑا تھوڑا کر کے۔

ماڈل سیکیورٹی کا وہم

بہت سے کاروباری اداروں نے "محفوظ" LLMs میں بہت زیادہ سرمایہ کاری کی ہے، یا تو فائن ٹیوننگ ملکیتی ماڈلز یا سمجھے گئے گارڈریلز کے ساتھ انٹرپرائز گریڈ APIs پر انحصار کرتے ہیں۔ مضمر مفروضہ یہ ہے کہ اگر ماڈل خود مضبوط ہے، تو اس کے اوپر بنی ہوئی ایپلیکیشن اس سیکیورٹی کی وارث ہوگی۔ حالیہ مظاہرے اسے ایک خطرناک غلط فہمی کے طور پر بے نقاب کرتے ہیں۔ کمزوری ماڈل کی بنیادی ذہانت یا اس کے تربیتی ڈیٹا میں نہیں ہے۔ یہ انٹرفیس میں ہے جسے ہم اس کے ارد گرد بناتے ہیں [1]۔ یہ کلاسک "مضبوط والٹ، کمزور سامنے کا دروازہ" کا مسئلہ ہے۔ آپ کے پاس دنیا کا سب سے جدید، سخت LLM ہو سکتا ہے، لیکن اگر آپ کی ایپلیکیشن کا ان پٹ پارسر سادہ ہے، یا آپ کا آؤٹ پٹ فلٹر موجود نہیں ہے، تو آپ بنیادی طور پر اہم معلومات کو کسی کے لیے تلاش کرنے کے لیے چھوڑ رہے ہیں۔

یہ "فوری انجیکشن" تکنیک خاص طور پر اس لیے ہے کہ یہ LLM کی فطری نوعیت کا فائدہ اٹھاتی ہے: ہدایات اور مکمل نمونوں پر عمل کرنے کی اس کی صلاحیت۔ صارف کے ان پٹ میں احتیاط سے بنائے گئے سابقے کو انجیکشن لگا کر، حملہ آور ماڈل کی اندرونی حالت میں ہیرا پھیری کر سکتا ہے، اور اسے ایسی معلومات ظاہر کرنے پر مجبور کر سکتا ہے جس کا ارادہ کبھی نہیں تھا [3]۔ "ایک بٹ" یا تکراری پہلو یہاں بہت اہم ہے۔ اس کا مطلب ایک طریقہ کار، کنٹرول شدہ اخراج ہے، نہ کہ صرف ایک افراتفری والا ڈیٹا ڈمپ۔ تصور کریں کہ ایک حملہ آور بار بار پوچھ رہا ہے، "کیا خفیہ 'A' کا پہلا کردار ہے؟" پھر "کیا یہ 'B' ہے؟" اور اسی طرح. یہ سست ہے، ہاں، لیکن یہ ناقابل یقین حد تک موثر اور اس کا پتہ لگانا مشکل ہے کہ آیا آپ اسے خاص طور پر تلاش نہیں کر رہے ہیں۔

آپ کا براؤزر، ان کا ہتھیار

حقیقت یہ ہے کہ یہ ایک براؤزر پر مبنی استحصال گیم کو مکمل طور پر بدل دیتا ہے۔ اس کا مطلب ہے:

  • داخلے میں کم رکاوٹ: کوئی بھی بنیادی ویب ڈویلپمنٹ کی مہارت اور براؤزر کے ساتھ اس کی کوشش کرسکتا ہے۔ کسی خصوصی ٹولز یا گہری AI علم کی ضرورت نہیں ہے۔
  • کلائنٹ سائیڈ ایگزیکیوشن: حملہ صارف کی مشین سے شروع ہوتا ہے، جس سے نیٹ ورک کے کنارے پر صارف کے جائز ان پٹ سے فرق کرنا مشکل ہوجاتا ہے۔
  • فوری خطرہ: اگر آپ کی LLM ایپلیکیشن لائیو ہے اور ویب انٹرفیس کے ذریعے قابل رسائی ہے، تو یہ پہلے سے ہی اس ویکٹر کے لیے خطرناک ہے۔ یہ مستقبل کا پیچ نہیں ہے۔ یہ ایک موجودہ ایمرجنسی ہے۔

مضمرات پر غور کریں: ملکیتی کوڈ کے ٹکڑوں، اندرونی دستاویزات، کسٹمر ڈیٹا، API کیز، یا یہاں تک کہ غلط معلومات پھیلانے یا نقصان دہ مواد تیار کرنے کے لیے آپ کے LLM کے رویے میں ٹھیک ٹھیک ہیرا پھیری۔ یہ سب کچھ ایک سادہ ٹیکسٹ باکس کے ذریعے تھوڑا سا محنت سے نکالا یا متاثر کیا جا سکتا ہے۔

ذمہ داری آپ کی ہے۔

یہ OpenAI یا Google جیسے ماڈل فراہم کنندگان کے لیے اپنی اگلی ماڈل اپ ڈیٹ میں درست کرنے کے لیے کوئی مسئلہ نہیں ہے۔ یہ ایک ایپلی کیشن سیکیورٹی کا مسئلہ ہے، اور تخفیف کی ذمہ داری پوری طرح سے ڈویلپرز، سیکیورٹی ٹیموں اور ان سسٹمز کو تعینات کرنے والے CTOs کے کندھوں پر آتی ہے۔ آپ کا LLM ایک طاقتور، لیکن بالآخر سادہ، انجن ہے۔ یہ وہی کرے گا جو اسے بتایا گیا ہے، چاہے وہ ہدایات بظاہر بے ضرر صارف کے ان پٹ میں چھپی ہوں۔

تو، اب آپ کیا کرتے ہیں*؟

فوری انسدادی اقدامات:

  1. جارحانہ ان پٹ سینیٹائزیشن: یہ ایس کیو ایل انجیکشن یا XSS کو روکنے سے بالاتر ہے۔ آپ کو اپنے LLM میں داخل ہونے والے ہر کردار کی جانچ پڑتال کرنے کی ضرورت ہے۔ فوری انجیکشن، غیر معمولی کردار کی ترتیب، یا متوقع بات چیت کے بہاؤ سے باہر نکلنے کی کوششوں کی نشاندہی کرنے والے نمونوں کی تلاش کریں [4]۔ یہ "برے الفاظ" کو روکنے کے بارے میں نہیں ہے۔ یہ مخالفانہ اشارے کی شناخت کے بارے میں ہے۔ بنیادی ریجیکس اور ہیورسٹک تجزیہ سے ہٹ کر، بدنیتی پر مبنی ارادے کا پتہ لگانے کے لیے سیمنٹک تجزیہ لاگو کریں۔ غیر معمولی ان پٹ پیٹرن کی شناخت کے لیے ٹوکنائزیشن اور ایمبیڈنگ تجزیہ کا استعمال کریں۔ ثانوی، چھوٹے LLM یا اصول پر مبنی نظام کو استعمال کرنے پر غور کریں جو خاص طور پر فوری انجیکشن کی کوششوں کا پتہ لگانے کے لیے تربیت یافتہ ہو۔ کردار ادا کرنے کی ہدایات، واضح ڈیٹا نکالنے کی درخواستیں، یا پچھلی ہدایات کو نظرانداز کرنے کی کوششوں جیسے نمونے تلاش کریں۔
  2. مضبوط آؤٹ پٹ فلٹرنگ اور توثیق: کبھی بھی LLM کے آؤٹ پٹ پر واضح طور پر بھروسہ نہ کریں۔ LLM سے تیار کردہ کوئی بھی متن کسی صارف کو ظاہر کرنے یا کسی دوسرے سسٹم کے ذریعے استعمال کرنے سے پہلے، اسے ضروری ایک سخت توثیق کی پرت سے گزرنا چاہیے۔ کیا یہ حساس کلیدی الفاظ پر مشتمل ہے؟ کیا یہ متوقع فارمیٹس سے میل کھاتا ہے؟ کیا یہ کوڈ پر عمل درآمد کرنے کی کوشش کرتا ہے یا اندرونی نظام کے اشارے کو ظاہر کرتا ہے؟ اگر آپ کے LLM کو کسی دستاویز کا خلاصہ کرنا ہے، لیکن یہ فائل کے راستوں کی فہرست بنانا شروع کر دیتا ہے، تو آپ کو ایک مسئلہ ہے۔
  3. لیئرڈ پرامپٹ انجینئرنگ: اگرچہ ایک مکمل حل نہیں ہے، اچھی طرح سے ڈیزائن کردہ سسٹم پرامپٹ اور چند شاٹ مثالیں مطلوبہ رویے کو تقویت دینے اور حملہ آور کے لیے ماڈل کو ہائی جیک کرنا مشکل بنا سکتی ہیں۔ تاہم، سمجھیں کہ صرف فوری انجینئرنگ ناکافی ہے۔ یہ گہرائی میں دفاع ہے، بنیادی ڈھال نہیں۔
  4. LLM تعاملات کے لیے کم سے کم استحقاق: کیا آپ کے LLM کو واقعی ڈیٹا کے ہر ٹکڑے تک رسائی کی ضرورت ہے جسے ظاہر کرنے کے لیے اسے ممکنہ طور پر کہا جا سکتا ہے؟ سخت رسائی کے کنٹرول کو نافذ کریں۔ اگر LLM کو صرف عوامی دستاویزات کے بارے میں سوالات کا جواب دینا ہے، تو یقینی بنائیں کہ اسے اندرونی ڈیٹا بیس یا حساس APIs تک کوئی پروگرامیٹک رسائی نہیں ہے۔
  5. مانیٹرنگ اور بے ضابطگی کا پتہ لگانا: آپ کو غیر معمولی LLM رویے کو فعال طور پر تلاش کرنے کی ضرورت ہے۔ مخصوص قسم کے سوالات، آؤٹ پٹ جو عام پیٹرن سے ہٹ جاتے ہیں، یا معلومات کو نکالنے کی بار بار کوششوں میں اضافہ فوری انتباہات کو متحرک کرنا چاہیے۔

یہ اب وسیع "AI سیکیورٹی" کے بارے میں نہیں ہے۔ یہ آپ کے LLM ایپلی کیشنز کی تعامل کی تہہ کو ایک مخصوص، ظاہر شدہ، اور فوری طور پر قابل استعمال حملہ آور ویکٹر کے خلاف محفوظ کرنے کے بارے میں ہے۔ ہم یہ ناقابل یقین، طاقتور سسٹم بنا رہے ہیں، اکثر انٹرفیس پر ناکافی حفاظتی اقدامات کے ساتھ۔ حالیہ مظاہروں نے ہمیں بخوبی دکھایا ہے کہ ان خلاوں سے فائدہ اٹھانا کتنا آسان ہے۔ نظریاتی بحث کا وقت گزر چکا ہے۔ LLM درخواستوں کو محفوظ بنانے کے لیے فوری کارروائی کی ضرورت ہے۔

ذرائع

[1] بڑی زبان کے ماڈل ایپلی کیشنز کے لیے OWASP ٹاپ 10 — https://owasp.org/www-project-top-10-for-large-language-model-applications/ [2] لیکیرا گینڈالف: ایک انٹرایکٹو پرامپٹ انجیکشن چیلنج — https://gandalf.lakera.ai/ [3] فوری انجیکشن حملے | ویب سیکیورٹی اکیڈمی - https://portswigger.net/web-security/llm-attacks/prompt-injection [4] فوری انجکشن کیا ہے اور اسے کیسے روکا جائے؟ — https://www.tenable.com/blog/what-is-prompt-injection-and-how-to-prevent-it


Have Questions?

Let's Talk

Contact me on LinkedIn