ان سائٹس پر نئے حملے کی تفصیلات جو فرنٹ اینڈ بیک اینڈ ماڈل استعمال کرتی ہیں، جیسے کہ مواد کی ترسیل کے نیٹ ورکس، لوڈ بیلنسرز یا پراکسیز کے ذریعے چلنے والی سائٹس۔ یہ حملہ، کچھ درخواستیں بھیج کر، فرنٹ اینڈ اور بیک اینڈ کے درمیان ایک ہی دھاگے میں پروسیس ہونے والی دیگر درخواستوں کے مواد کو جوڑنے کی اجازت دیتا ہے۔ مجوزہ طریقہ کو کامیابی کے ساتھ ایک حملے کو منظم کرنے کے لیے استعمال کیا گیا جس نے پے پال سروس کے صارفین کے توثیقی پیرامیٹرز کو روکنا ممکن بنایا، جس نے محققین کو ایک پروگرام کے حصے کے طور پر تقریباً 40 ہزار ڈالر ادا کیے تھے تاکہ غیر موزوں خطرات کی موجودگی کے بارے میں مطلع کیا جا سکے۔ حملے کا اطلاق اکامائی مواد کی ترسیل کے نیٹ ورک کا استعمال کرنے والی سائٹس پر بھی ہوتا ہے۔
مسئلہ کی جڑ یہ ہے کہ فرنٹ اینڈ اور بیک اینڈ اکثر HTTP پروٹوکول کے لیے مختلف سطحوں کی حمایت فراہم کرتے ہیں، لیکن ایک ہی وقت میں مختلف صارفین کی درخواستوں کو ایک مشترکہ چینل میں سمیٹتے ہیں۔ فرنٹ اینڈ موصول ہونے والی درخواستوں اور بیک اینڈ پروسیسنگ کی درخواستوں کو مربوط کرنے کے لیے، ایک طویل عرصے تک چلنے والا TCP کنکشن قائم کیا جاتا ہے، جس کے ذریعے صارف کی درخواستیں منتقل ہوتی ہیں، ایک کے بعد ایک سلسلہ کے ساتھ منتقل ہوتی ہیں، HTTP پروٹوکول کے ذریعے الگ ہوتی ہیں۔ درخواستوں کو الگ کرنے کے لیے، ہیڈر "مواد کی لمبائی" (درخواست میں ڈیٹا کے کل سائز کا تعین کرتا ہے) اور ""(آپ کو مختلف سائز کے بلاکس کو "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0" فارمیٹ میں بتاتے ہوئے حصوں میں ڈیٹا منتقل کرنے کی اجازت دیتا ہے)۔
مسئلہ پیدا ہوتا ہے اگر فرنٹ اینڈ صرف "مواد کی لمبائی" کو سپورٹ کرتا ہے لیکن "ٹرانسفر-انکوڈنگ: chunked" کو نظر انداز کرتا ہے (مثال کے طور پر، Akamai CDN نے ایسا کیا) یا اس کے برعکس۔ اگر Transfer-Encoding: chunked دونوں طرف سے تعاون یافتہ ہے، تو HTTP ہیڈر پارسرز کے نفاذ کی خصوصیات کو حملے کے لیے استعمال کیا جا سکتا ہے (مثال کے طور پر، جب فرنٹ اینڈ لائنز کو نظر انداز کرتا ہے جیسے "Transfer-Encoding: xchunked"، "Transfer-Encoding: chunked "، "ٹرانسفر-انکوڈنگ" :[ٹیب]چنکڈ"، "X: X[\n]ٹرانسفر-انکوڈنگ: chunked"، "Transfer-Encoding[\n]: chunked" یا "Transfer-Encoding: chunked"، اور پسدید ان پر کامیابی کے ساتھ کارروائی کرتا ہے)۔
اس صورت میں، ایک حملہ آور ایک درخواست بھیج سکتا ہے جس میں "Content-Length" اور "Transfer-Encoding: chunked" ہیڈر دونوں شامل ہوں، لیکن "Content-Length" میں موجود سائز کٹے ہوئے چین کے سائز سے مطابقت نہیں رکھتا، جو اصل قدر سے چھوٹا ہے۔ اگر فرنٹ اینڈ درخواست کو "مواد کی لمبائی" کے مطابق پروسیس کرتا ہے اور آگے بھیجتا ہے اور بیک اینڈ "ٹرانسفر-انکوڈنگ: chunked" کی بنیاد پر بلاک کے مکمل ہونے کا انتظار کرتا ہے، تو ڈیٹا کا اختتام "ٹرانسفر-انکوڈنگ: chunked" پر مبنی ہوگا۔ پہلے طے کیا جائے اور درخواست کی بقیہ پونچھ حملہ آور اگلی درخواست کے آغاز میں ہو گی، یعنی حملہ آور کسی اور کی اگلی منتقلی کی درخواست کے شروع میں صوابدیدی ڈیٹا منسلک کرنے کے قابل ہو گا۔
استعمال شدہ فرنٹ اینڈ بیک اینڈ مجموعہ میں مسئلہ کا تعین کرنے کے لیے، آپ فرنٹ اینڈ کے ذریعے اس طرح کی درخواست بھیج سکتے ہیں:
POST/HTTP/1.1 کے بارے میں
میزبان: example.com
منتقلی-انکوڈنگ: ٹکڑا
مواد کی لمبائی: 4
1
Z
Q
مسئلہ موجود ہے اگر بیک اینڈ فوری طور پر درخواست پر کارروائی نہیں کرتا ہے اور chunked ڈیٹا کے فائنل صفر باؤنڈنگ بلاک کی آمد کا انتظار کرتا ہے۔ مزید مکمل چیک کے لیے ایک خاص افادیت جو فرنٹ اینڈ سے "ٹرانسفر-انکوڈنگ: chunked" ہیڈر کو چھپانے کے ممکنہ طریقوں کی بھی جانچ کرتی ہے۔
حقیقی حملہ کرنا حملہ آور سائٹ کی صلاحیتوں پر منحصر ہے، مثال کے طور پر، ٹریلو ویب ایپلیکیشن پر حملہ کرتے وقت، آپ درخواست کے آغاز کو تبدیل کر سکتے ہیں (متبادل ڈیٹا جیسے "PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake") اور ایک پیغام بھیجیں جس میں فریق ثالث کے صارف کی اصل درخواست اور اس میں بتائی گئی تصدیقی کوکی بھی شامل ہے۔ saas-app.com پر حملے کے لیے، جواب میں JavaScript کوڈ کو درخواست کے پیرامیٹرز میں سے ایک میں بدل کر اسے تبدیل کرنا ممکن ہوا۔ redhat.com پر حملے کے لیے، حملہ آور کی ویب سائٹ پر ری ڈائریکٹ کرنے کے لیے ایک اندرونی ہینڈلر کا استعمال کیا گیا تھا (فارم کی درخواست "POST/search?dest=../assets/idx?redir=//[ای میل محفوظ]/ HTTP/1.1")۔
مواد کی ترسیل کے نیٹ ورکس کے طریقہ کار کو استعمال کرتے ہوئے "میزبان:" ہیڈر کی جگہ لے کر صرف درخواست کردہ سائٹ کو تبدیل کرنا ممکن بنا۔ اس حملے کو مواد کیشنگ سسٹمز کے مواد کو زہر آلود کرنے اور کیش شدہ خفیہ ڈیٹا کو نکالنے کے لیے بھی استعمال کیا جا سکتا ہے۔ اس طریقہ کار کی سب سے بڑی وجہ پے پال پر حملے کی تنظیم تھی، جس نے تصدیق کے دوران صارفین کے ذریعے بھیجے گئے پاس ورڈز کو روکنا ممکن بنایا (iframe کی درخواست کو paypal.com/us/gifts صفحہ کے تناظر میں جاوا اسکرپٹ پر عمل کرنے کے لیے تبدیل کیا گیا تھا۔ جس پر CSP (مواد کی حفاظت کی پالیسی) کا اطلاق نہیں کیا گیا تھا)۔
دلچسپ بات یہ ہے کہ 2005 میں تھا۔ بنیادی طور پر اسی طرح کی درخواست کی سپوفنگ تکنیک جو آپ کو ایک HTTP سیشن کے اندر کئی "GET" یا "POST" درخواستوں کی وضاحت کر کے کیشنگ پراکسیز (Tomcat، squid، mod_proxy) میں ڈیٹا کو سپوف کرنے یا فائر وال بلاکنگ کو بائی پاس کرنے کی اجازت دیتی ہے۔
ماخذ: opennet.ru