اڳيون-آخر-پوئتي-آخر سسٽم تي حملو جيڪو اسان کي ٽئين پارٽي جي درخواستن ۾ ويهڻ جي اجازت ڏئي ٿو

پڌرو ٿيو سائيٽن تي نئين حملي جا تفصيل جيڪي فرنٽ-اينڊ-پئڪ-اينڊ ماڊل استعمال ڪن ٿا، جهڙوڪ جيڪي مواد ڊليوري نيٽ ورڪ، لوڊ بيلنس يا پراڪسيز ذريعي هلن ٿا. حملي جي اجازت ڏئي ٿي، ڪجهه درخواستن کي موڪلڻ سان، ٻين درخواستن جي مواد ۾ داخل ٿيڻ جي لاءِ ساڳئي سلسلي ۾ فرنٽ اينڊ ۽ پس منظر جي وچ ۾. تجويز ڪيل طريقو ڪاميابيءَ سان حملي کي منظم ڪرڻ لاءِ استعمال ڪيو ويو، جنهن پي پال سروس جي استعمال ڪندڙن جي تصديق جي ماپن کي روڪڻ ممڪن بڻايو، جنهن تحقيق ڪندڙن کي تقريباً 40 هزار ڊالر ادا ڪيا هڪ پروگرام جي حصي طور اڻ ڄاتل خطرن جي موجودگي بابت آگاهي ڏيڻ لاءِ. حملو اڪامي مواد پهچائڻ واري نيٽ ورڪ کي استعمال ڪندي سائيٽن تي پڻ لاڳو ٿئي ٿو.

مسئلو جو مسئلو اهو آهي ته فرنٽ اينڊ ۽ پس منظر اڪثر ڪري HTTP پروٽوڪول لاءِ مختلف سطحن جي مدد فراهم ڪن ٿا، پر ساڳئي وقت مختلف صارفين کان درخواستن کي هڪ عام چينل ۾ شامل ڪن ٿا. فرنٽ اينڊ وصول ڪندڙ درخواستن ۽ پسمنظر جي پروسيسنگ درخواستن کي ڳنڍڻ لاءِ، هڪ ڊگهي عرصي وارو TCP ڪنيڪشن قائم ڪيو ويو آهي، جنهن ذريعي صارف جون درخواستون منتقل ڪيون وينديون آهن، هڪ ٻئي کان پوءِ زنجير سان منتقل ٿينديون آهن، HTTP پروٽوڪول جي ذريعي الڳ ٿيل هونديون آهن. درخواستن کي الڳ ڪرڻ لاءِ، هيڊر "Content-Length" (درخواست ۾ ڊيٽا جي ڪل سائيز کي طئي ڪري ٿو) ۽ "منتقلي-انڪوڊنگ: ٽڪر"(توهان کي ڊيٽا کي حصن ۾ منتقل ڪرڻ جي اجازت ڏئي ٿي، مختلف سائزن جا بلاڪ بيان ڪندي فارميٽ ۾ "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").

مسئلو پيدا ٿئي ٿو جيڪڏهن فرنٽ اينڊ صرف "مواد جي ڊيگهه" کي سپورٽ ڪري ٿو پر "منتقلي-انڪوڊنگ: chunked" کي نظر انداز ڪري ٿو (مثال طور، Akamai CDN اهو ڪيو) يا ان جي برعڪس. جيڪڏهن Transfer-Encoding: chunked ٻنهي طرفن تي سپورٽ ڪئي وئي آهي، HTTP هيڊر پارسرز جي لاڳو ٿيڻ واريون خاصيتون حملي لاءِ استعمال ڪري سگهجن ٿيون (مثال طور، جڏهن اڳيون آخر ۾ لائنن کي نظر انداز ڪري ٿو جهڙوڪ "منتقلي-انڪوڊنگ: xchunked"، "Transfer-Encoding: chunked ”، “منتقلي-انڪوڊنگ” :[ٽيب]چنڪ ٿيل”، “X: X[\n]منتقلي-انڪوڊنگ: ٽڪرا ٿيل”، “منتقلي-انڪوڊنگ[\n]: ٽڪرا ٿيل” يا “منتقلي-انڪوڊنگ: ٽڪر ٿيل”، ۽ پس منظر ڪاميابيءَ سان ان تي عمل ڪري ٿو).

انهي صورت ۾، هڪ حملو ڪندڙ هڪ درخواست موڪلي سگهي ٿو جنهن ۾ "مواد جي ڊگھائي" ۽ "منتقلي-انڪوڊنگ: chunked" هيڊر شامل آهن، پر "Content-length" ۾ سائيز، chunked زنجير جي سائيز سان مطابقت نه رکي، جيڪا اصل قدر کان ننڍو آهي. جيڪڏهن فرنٽ اينڊ پروسيس ڪري ٿو ۽ درخواست کي "مواد جي ڊگھائي" جي مطابق اڳتي وڌائي ٿو ۽ پس منظر "منتقلي-انڪوڊنگ: chunked" جي بنياد تي بلاڪ جي مڪمل ٿيڻ جو انتظار ڪري ٿو، پوء ڊيٽا جي آخر ۾ "منتقلي-انڪوڊنگ: chunked" جي بنياد تي ختم ٿي ويندي. اڳ ۾ طئي ڪيو وڃي ۽ درخواست جو باقي دم حملو ڪندڙ ايندڙ درخواست جي شروعات ۾ هوندو، يعني. حملو ڪندڙ اڳتي هلي ڪنهن ٻئي جي درخواست جي شروعات ۾ صوابديدي ڊيٽا کي ڳنڍڻ جي قابل هوندو.

اڳيون-آخر-پوئتي-آخر سسٽم تي حملو جيڪو اسان کي ٽئين پارٽي جي درخواستن ۾ ويهڻ جي اجازت ڏئي ٿو

استعمال ٿيل فرنٽ اينڊ-پٺاڻ ميلاپ ۾ مسئلي کي طئي ڪرڻ لاءِ، توھان موڪلي سگھو ٿا درخواست ھن طرح فرنٽ اينڊ ذريعي:

پوسٽ / بابت 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").

مواد جي ترسيل نيٽ ورڪن لاءِ طريقو استعمال ڪندي ان کي ممڪن بڻايو ته صرف "ميزبان:" هيڊر کي متبادل ڪندي درخواست ڪيل سائيٽ کي تبديل ڪرڻ. حملو پڻ مواد ڪيشنگ سسٽم جي مواد کي زهر ڪرڻ ۽ ڪيش ٿيل رازداري ڊيٽا کي ڪڍڻ لاء استعمال ڪري سگهجي ٿو. طريقي جو مکيه ڪارڻ PayPal تي حملي جي تنظيم هئي، جنهن کي تصديق ڪرڻ دوران صارفين طرفان موڪليل پاسورڊ کي روڪڻ ممڪن ڪيو ويو (iframe جي درخواست ۾ تبديلي ڪئي وئي جاوا اسڪرپٽ کي هلائڻ لاء Paypal.com/us/gifts صفحي جي حوالي سان. جنهن تي CSP (مواد سيڪيورٽي پاليسي) لاڳو نه ڪئي وئي هئي).

دلچسپ ڳالهه اها آهي ته 2005 ۾ هو تجويز ڪيل هڪ لازمي طور تي هڪجهڙائي واري درخواست اسپفنگ ٽيڪنڪ جيڪا توهان کي اجازت ڏئي ٿي ڊيٽا کي اسپوف ڪرڻ جي ڪيشنگ پراڪسيز (Tomcat, squid, mod_proxy) ۾ يا هڪ HTTP سيشن اندر ڪيترن ئي “GET” يا “POST” درخواستن کي بيان ڪندي فائر وال بلاڪنگ کي بائي پاس ڪري.

جو ذريعو: opennet.ru

تبصرو شامل ڪريو