1. المدير العام

    المدير العام أدارة موقع أكتب كود

    ثغرة 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 بتاعتهم هتساعدك تفهم الموضوع بشكل اكبر وتشتغل بأيدك:
     
جاري تحميل الصفحة...