ثغرة HTTP Request Smuggling Attack ؟ بالبلدي كدا الثغرة دي بتسمح للـattacker إنه يبعت للـweb-server شوية http-requests عشان اللـserver دا يخلي اللـusers تنفذها (دا بشكل عام).. ولكن قبل ما نتكلم عن الثغرة دي خلونا نرجع لشوية مفاهيم مهمة لازم تكون عارفها عشان تفهم الثغرة دي.. تخيل كدا إنك في كل مرة تبعت HTTP Request لapplication ساعتها هيتم فتح TCP-Link بينك وبين السيرفر.. وبالتالي السيرفر هيكون عليه حمل نوعًا ما، وعشان كدا بروتوكول HTTP1.1 اتضافو له 2 features وهما اللـKeep-Alive , Pipeline طيب دورهم ايه؟ 1- Connection: Keep-Alive : دا عبارة عن Request header مهمته إنه يقول للـServer اول ما تستلم اللـHTTP Request متقفلش اللـTCP-Link بتاعه بالتالي كل اللـRequests/Responses اللبينهم هتكون خلال TCP-Link واحد فقط ومش هيحصل TCP-Handshaking غير مرة واحدة ودا بيزود سرعة اللـconnection وبيخفف الحمل من على السيرفر. واللـfeature دي موجودة بشكل افتراضي "by default" في HTTP1.1 .. 2- Pipeline : إحنا عارفين إن اللـBrowser بيبعت request واللـserver بيرد عليه بـResponse اللـPipeline بقى بتخلي اللـBrowser يبعت اكتر من Request مرة واحدة ويستنى رد اللـServer عليهم كلهم وهنا اللـServer بيمشي بنظام FIFO "First in First Out" اللهو اول Request هيجيلي هو اول Response هيطلع وهكذا .. طيب هل كل دا كافي عشان نضمن اللـspeed up access, save resources ونقلل من اللـserver overhead ؟ فـهنا لازم نكلم عن حاجة إسمها CDN اختصار لـContent Delivery Network ودي عبارة عن شبكة بتحتوي سيرفرات موزعة على العالم غرضها إنها تزود من سرعة تصفح الuser للـweb-application طب ازاي دا بيحصل؟ تخيل معايا مثلًا إنه انت عندك موقع اللهو بيتكون من JS,CSS Fiels - Images,Videos ..etc وجه واحد من الصين يتصفح الموقع بتاعك ساعتها اللداتا دي هتسافر من السيرفر في مصر لحد الصين! وهنا هياخد وقت كبير مش ملحوظ عقبال ما الموقع يحمل عنده.. لو كنت بتستخدم اللـCDN هنا فـبدل ما الموقع بتاعك يحمل بشكل مباشر من السيرفر في مصر لحد الشخص دا في الصين كان ممكن تستخدم اللـCDN فالمهمة دي، وبما إنه بيكون موزع سيرفراته على العالم ساعتها الشخص الصيني دا كان هيتبعتله الموقع بتاعك من خلال CDN Server قريب منه جغرافيًا وبالتالي هيحصل page load time للموقع بتاعك وهيوصله بشكل اسرع.. طيب اللـCDN Server دا بيكون إسمه Proxy Server او Front-end Server .. واللـServer الحقيقي بيكون إسمه Back-end Server .. طيب تخيل معايا إن فيه web application بيستخدم اللـProxy server عشان يحسن من سرعة موقعه ولكن اللـProxy server معمول عليه implementation مختلف عن اللـBack-end server فـساعتها لما اللـHTTP Request هيروح للـProxy Server هيتعامل معاه بطريقة ولما بيروح للـBack-end server هيتعامل معاه بطريقة تانية خالص، ومن هنا ظهرت ثغرة اللـHTTP Request Smuggling إنه اللـAttacker بيعتمد على عدم التوافق بين اللـFront-End server و Back-end Server طيب ايه النقطة اللبيلعب عليها اللـAttacker هنا؟ او ايه عدم التوافق يعني اللبين السيرفرين اللبيؤدي لحدوث الثغرة؟ وهنا هنروح نتكلم عن 2 headers مهمين جدًا جدًا وهما - Content-Length - Transfer-Encoding بص يا غالي، اللـContent Length بيكون شكله عامل كدا في اللـRequest Content-Length: 5 شايف الرقم اللجمبه دا؟ هو عبارة عن اللـsize بتاع اللـRequest اللبيبعته .. (message body) ولكن in bytes .. شوف كدا اللـRequest دا كود: POST /index.html HTTP/1.1 Host: Example.com Content-Length: 6 QWERTY هنا اللـContent Length عبارة عن 6 bytes اللهما كلمة QWERTY .. إنما اللـTransfer-Encoding : دا عبارة عن header بيكون غرضه إنه يعمل encoding للـrequest body عشان يحصل secure transmission او نقل آمن للـrequest دا .. وهو ممكن يحتوي علي 5 قيم ولكن احنا يهمنا واحدة فقط chunked | compress | deflate | gzip | identity يهما اللـChunked ودا عبارة عن إننا بنقسم اللـRequest لمجموعة chunks كل chunk منهم له Size مكتوب باللـHexadecimal بعدين newline بعدين محتوي اللـchunk واللـmessage body بتنتهي برقم 0 متبوعًا بـnewline. مش فاهم؟ طيب بص على اللـRequest دا كدا .. كود: GET / HTTP/1.1 Host: Example.com Content-length: 56 Transfer-Encoding: chunked 6\r\n QWERTY 2\r\n HI 4\r\n test 0\r\n \r\n تعالى نشرحه حته حته ونفهمه.. بص يا باشا احنا هنا استخدمنا Content-Length: 56 و Transfer-Encoding: chunked وفي الحالة دي ما دام استخدمنا اللـTransfer-Encoding بشكل افتراضي هيتم حذف اللـContent-Length ولا كأنه مكتوب في Request وخليك فاكر الحتة دي كويس عشان هنحتاجها قدام.. بعد كدا كتبنا رقم 6\r\n ورقم 6 عبارة عن Hexadecimal بيحمل size اللـchunk وبعدين للـ\r\n اللـ\n عبارة عن newline و اللـ\r بيخليه يروح على بداية اللـnewline دا.. وفالأخر هتلاقي chunk اللـsize بتاعها 0 ودا معناه إنه خلاص هنا نهاية اللـrequest body .. طيب زي ما قولتلك فوق إن في حالة استخدام اللـContent-Length و Transfer-Encoding في نفس اللـrequest ساعتها بشكل افتراضي اللـContent-Length بيتشال وبيتم استخدام اللـTransfer-Encoding فقط .. == اللـscenario اللفات دا بيشتغل في حالة إنه اللـconnection بين user و server فقط.. ولكن لو كان فيه Proxy Server ما بينهم ساعتها هتظهر هنا security risk خطير جدًا ! ودا بسبب إنه 1- فيه سيرفرات مش بتدعم اللـTransfer-Encoding header في اللـRequests .. 2- حتى لو اللـServer بيدعمه اللـAttacker يقدر من خلال اللتلاعب في request يخلي اللـServer ميعملهوش process. وهنا بقى بيظهر هجوم اللـHTTP Request Smuggling إنه اللـProxy Server بيتعامل بطريقة مختلفة عن اللـBackend Server مع اللـRequest فاللـAttacker بيستغل الخلل دا لصالحه .. من خلال إنه بيبعت 2 headers بيحدده نهاية اللـmessage body في نفس الوقت وهما اللـContent-Length, Transfer-Encoding.. دلوقتي لما اللـUser بييجي يفتح web application ساعتها اللrequest بيروح للـfront-end server واللـFront-End Server بيبعته للـBack-end Server .. فـ هنا بقى اللـAttacker بيبعت smuggling request ودا عبارة عن request عادي جدًا لكنه بيحمل request تاني بداخله وهنا بسبب إن اللـfront-end server بيتعامل بطريقة مختلفة مع اللـrequest عن الطريقة اللبيتعامل بيها اللـbackend server بالتالي اللـFront-end server بيشوف اللـsmuggled request على إنه Request طبيعي وبيعته للـBack-end Server واللـback-end server بيشوف اللـsmuggled request على إنه فعلًا فيه 2 requests فـ هو بيقوم بتنفيذ request واحد فقط واللـRequest التاني دا بيقوم بتنفيذه بدل اي request هيجيله بعد كدا من اي شخص بيتصفح الموقع.. بشرط إنه اللـRequest بتاعه بيكون بيستخدم نفس اللـfront-end server , back-end server وقدام هقولك ازاي تزود احتمالة ان دا يحصل.. فيه كذا نوع للـHTTP Request smuggling attacks وهما اللـ CL.TE , TE.CL , CL.CL *** خليك فاكر إنه كل مهمتنا إننا نضحك على Front-End Server بإننا نخليه يوصل اللـSmuggled Request بشكل كامل للـBack-end server *** - CL.TE دا معناه إنه لما بييجي request فيه 2 headers اللهما اللـContent-Length, Transfer-Encoding اللـFront-end server بيقوم فقط بتنفيذ اللـContent-Length واللـBack-End Server بيقوم فقط بتنفيذ اللـTransfer-Encoding كود: POST / HTTP/1.1 Host: example.com Content-Length: 24 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1 هنا اللـAttacker بعت smuggled request اول ما يوصل للـFront-End proxy بما إنه بيقرأ Content-Length فقط فـ هنا اللـContent-Length عبارة عن 24 bytes وهو اللـRequest كله بشكل كامل بيتبعت للـBack-end Server (يعني كل الفكرة هنا إننا لازم نوصل اللـRequest بشكل كامل للـBackend-server ونضحك على اللـFront-End server) ولكن لما يوصل للـBackend-server وهو بيقرأ اللـTransfer-Encoding فقط ساعتها اول ما يشوف اللـ0 دي هيفهم إنه كدا اللـMessage body انتهى ف بيروح يـTerminate اللـConnection دا ولكنه بيتفاجئ بعدها إنه فيه Request تاني وهو اللـGET /admin HTTP/1.1 فـ ساعتها اي user بيحاول يخش على الموقع دا بشكل تلقائي اللـbackend-server بيخليه يبعت اللـGET /admin HTTP/1.1 request دا ! - TE.CL دا معناه إنه لما بييجي request فيه 2 headers اللهما transfer-Encoding , Content-Length اللـFront-end server بيقوم فقط بتنفيذ اللـTransfer-Encoding و اللـBack-end server بيقوم فقط بتنفيذ اللـContent-Length كود: POST / HTTP/1.1 Host: example.com Content-Length: 4 Transfer-Encoding: chunked 12 GPOST / HTTP/1.1 0 هقولها تاني .. خليك فاكر إنه كل مهمتنا إننا نضحك على Front-End Server بإننا نخليه يوصل اللـSmuggled Request بشكل كامل للـBack-end server هنا بقى اول ما Request دا يوصل للـFront-End Server في حالة إنه بينفذ فقط اللـTransfer-Encoding يعني ساعتها اول ما يلاقي اللـ0 هيـterminate اللـRequest .. فـهنا فاللـRequest لقاه اخر حاجة .. بالتالي هيروح يبعت اللـRequest كله للـBack-End Server .. وبما إن اللـBack-end server بينفذ فقط اللـContent-Length فـ هنا اللـContent-Length بيقرأ فقط 4 bytes اللهما اللـnewline ورقم 12 بالتالي هو دا اللـRequest بالنسباله ولكن بيتفاجئ إنه فيه Request تاني محطوط بالتالي بيروح ينفذه على اول user هيبعت request للـbackend-server دا واللهو اللـGPOST / HTTP/1.1 .. ورقم 12 هنا هو اللـHexadecimal number للـSize بتاع اللـchunked request.. *** لاحظ *** إنه هنا احنا كل اللـrequests اللبنبعتها بتكون POST method ودا بسبب إن اللـGET مش بـcarry اللـrequest body زي اللـPOST وكل دا سبب اللـimplementations بتاع اللـHTTP Protocol .. فـ انت في اي request هتعمل من خلاله Smuggling تأكد إنه POST ولو كان GET غير اللـMethod لـPOST يمكن تنفع.. - CL.CL وهنا بقى انت بتبعت في اللـRequest 2 headers واللإتنين هيكونوا Content-Length ولكن من المعروف إنه لما اللـRequest بيوصل للـServer بيحتوي على 2 Content-Length بنفس القيمة بيحصل Error 400 .. ولكن بعض اللـServers مش بيقوموا بتنفيذ اللـspecification بشكل صحيح.. وبالتالي اللـAttacker يقدر يستفيد من دا فـي عمل smuggled request .. اللـImpact بتاع اللـHTTP Request Smuggling بيكون على حسب اللـScenario اللنت فيه.. ولكن عموما تقدر تعمل الأتي بيها - Deliver SELF-XSS to Reflected XSS - Capture other user's requests - perform web-cache poisining, deception >> وعلى حسب السيناريو اللى أنت فيه .. فـ انا انصحك تروح تطبق بأيدك على PortSwigger labs لإنهم شارحين الثغرة بطريقة رائعة و مبسطة وكمان اللـlabs بتاعتهم هتساعدك تفهم الموضوع بشكل اكبر وتشتغل بأيدك: https://portswigger.net/web-security/request-smuggling
