RamenHire جاب بورڈ میں ایک stored HTML injection بگ کی وجہ سے کوئی بھی عوامی فارم بھر سکتا تھا اور ٹیم کے نوٹیفکیشن ای میلز کو فشنگ پلیٹ فارم میں تبدیل کر سکتا تھا۔
یہ بگ کیسے پیدا ہوا
RamenHire Next.js اور Supabase پر چلتا ہے اور اسٹارٹ اپس کو لاگ ان کیے بغیر ملازمتیں پوسٹ کرنے کی اجازت دیتا ہے۔ ہر درخواست (submission) ہائرنگ ٹیم کو ایک ای میل بھیجتی ہے۔ ای میل کا متن (body) فارم کے خام ڈیٹا—کمپنی کا نام، جاب ڈسکرپشن، رابطہ کار کا نام—کو براہ راست ایک HTML اسٹرنگ میں جوڑ کر بنایا جاتا ہے۔ میل سروس تک پہنچنے سے پہلے اس اسٹرنگ کی کسی قسم کی escaping یا sanitisation نہیں کی جاتی۔
چونکہ ٹیمپلیٹ صارف کے ان پٹ کو محفوظ HTML سمجھتا ہے، اس لیے ایک بدنیتی پر مبنی درخواست گزار ایک جعلی "click here to verify" لنک شامل کر سکتا ہے۔ یہ پی لوڈ (payload) سرور پر جاب لسٹنگ کے حصے کے طور پر محفوظ ہو جاتا ہے، لہذا اس کے بعد آنے والی ہر نوٹیفکیشن ای میل میں وہ نقصان دہ کوڈ شامل ہوتا ہے۔ ایک حملہ آور اس لنک کو اصل "View Dashboard" بٹن کے ساتھ چھپا سکتا ہے، جس سے ٹیم کا رکن دھوکے سے اپنے کریڈنشلز (credentials) ظاہر کر سکتا ہے یا کسی فشنگ سائٹ پر جا سکتا ہے۔
یہ کیوں اہم تھا
یہ ای میلز ہائرنگ ٹیم کے اہم ارکان کو بھیجی جاتی ہیں، جو امیدواروں کے عمل (pipeline) کو آگے بڑھانے کے لیے مسلسل لنکس پر کلک کرتے رہتے ہیں۔
تکنیکی خلا
HTML escaping کوئی ایک مرحلہ نہیں ہے۔ دو مختلف صورتحال (contexts) میں تحفظ کی ضرورت ہوتی ہے:
- Text nodes – ٹیگز کے درمیان موجود مواد۔
<کو<اور>کو>میں تبدیل کرنے سے ٹیگز تو رک جاتے ہیں، لیکن یہ حملہ آور کو کسی ایٹریبیوٹ ویلیو (attribute value) سے باہر نکلنے سے نہیں روک سکتا۔ - Attribute values – ٹیگز کے اندر موجود اسٹرنگز جیسے کہ
href="…"۔ ایک کوٹیشن مارک ("یا') شامل کرنے سے حملہ آور ایٹریبیوٹ کو وقت سے پہلے بند کر کے اپنا مارک اپ (markup) ڈال سکتا ہے۔
اصل کوڈ صرف سادہ متن (plain text) کو ہینڈل کرتا تھا، جس کی وجہ سے ایٹریبیوٹ انجیکشن (attribute injection) کا راستہ کھلا رہ گیا۔
مسئلے کا حل
ڈویلپر نے ایک چھوٹا escapeHtml ہیلپر شامل کیا اور انٹروپولیشن (interpolation) سے پہلے صارف کے فراہم کردہ ہر ویلیو پر اسے لاگو کیا، چاہے وہ ویلیو ٹیکسٹ نوڈ میں ہو یا ایٹریبیوٹ میں۔
تصدیقی مراحل
- Local testing – ٹیمپلیٹ فنکشنز میں انجیکشن اسٹرنگز کا ایک مجموعہ شامل کیا گیا۔ ہر ٹیسٹ میں صرف escaped کیریکٹرز نظر آئے، کوئی بھی قابلِ عمل (executable) ٹیگ نہیں تھا۔
- Production testing – پیچ (patch) لگانے کے بعد، لائیو سائٹ کے ذریعے ایک پی لوڈ جمع کرایا گیا، جس نے Cloudflare Turnstile بوٹ چیک کو بھی پاس کر لیا۔ نتیجہ کے طور پر ای میل ڈویلپر کے ان باکس میں پہنچی؛ نقصان دہ لنک اور کوئی بھی اسکرپٹ ٹیگ بکھرے ہوئے متن (garbled text) کے طور پر ظاہر ہوئے، نہ کہ کلک کرنے کے قابل عناصر کے طور پر۔
Gmail کے بارے میں ایک نوٹ: یہ سروس اب بھی URL کو نیلا رنگ دے سکتی ہے اور اسے کلک کرنے کے قابل بنا سکتی ہے، لیکن یہ کلائنٹ سائیڈ کی سہولت ہے اور اس کا مطلب یہ نہیں کہ HTML انجیکشن کامیاب ہو گیا۔ یہ حل انجیکشن کو اصل بٹن بنانے یا اسکرپٹس چلانے سے روکتا ہے۔
ڈویلپرز کو کن باتوں کا خیال رکھنا چاہیے
- عوامی فارمز سے حاصل کردہ ڈیٹا پر کبھی بھروسہ نہ کریں – بے ضرر نظر آنے والے فارمز بھی ایسا stored output پیدا کر سکتے ہیں جو کہیں اور استعمال ہوتا ہو۔
- استعمال کے مقام پر escape کریں – رینڈرنگ (rendering) سے عین پہلے سیاق و سباق کے مطابق (text بمقابلہ attribute) escaping لاگو کریں، نہ کہ پائپ لائن میں اس سے پہلے۔
- کلائنٹ سائیڈ اور سرور سائیڈ دونوں کو ٹیسٹ کریں – یونٹ ٹیسٹ واضح ناکامیوں کو پکڑ لیتے ہیں؛ لائیو UI کے ذریعے دستی (manual) اینڈ ٹو اینڈ ٹیسٹ اس بات کی تصدیق کرتا ہے کہ دفاعی نظام اصل ٹریفک کے دوران برقرار رہتا ہے۔
- ای میل کلائنٹس کی مخصوص خصوصیات سے باخبر رہیں – کچھ کلائنٹس خود بخود URL کو لنک بنا دیتے ہیں، جس سے تحفظ کا غلط احساس پیدا ہو سکتا ہے۔ اس بات کی تصدیق کریں کہ بنیادی HTML میں کوئی فعال (active) عناصر موجود نہ ہوں۔
خلاصہ
صارف کے ان پٹ کو ہینڈل کرنے میں ایک معمولی سی غلطی نے معمول کی نوٹیفکیشن ای میلز کو فشنگ کے ذریعے حملہ کرنے کا ذریعہ بنا دیا۔ ایک جامع HTML-escaping طریقہ کار متعارف کرانے اور مقامی طور پر اور پروڈکشن میں اس کی تصدیق کرنے سے ان باکس کی سالمیت بحال ہو گئی۔ یہ واقعہ کسی بھی ایسی ویب ایپ کے لیے ایک لازوال سبق ہے جو غیر قابلِ اعتماد ڈیٹا سے HTML تیار کرتی ہے: مناسب sanitisation پر سمجھوتہ نہیں کیا جا سکتا، اور اسے نظر انداز کرنا آپ کے صارفین کے ان باکس تک براہ راست راستہ کھول سکتا ہے۔