- بواسطة x32x01 ||
ثغرة 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 دا
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 دا كدا ..
تعالى نشرحه حته حته ونفهمه..
بص يا باشا احنا هنا استخدمنا 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
هنا اللـ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
هقولها تاني .. خليك فاكر إنه كل مهمتنا إننا نضحك على 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 بتاعتهم هتساعدك تفهم الموضوع بشكل اكبر وتشتغل بأيدك:
بالبلدي كدا الثغرة دي بتسمح للـ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 دا
Code:
POST /index.html HTTP/1.1
Host: Example.com
Content-Length: 6QWERTY
هنا اللـ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 دا كدا ..
Code:
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
Code:
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
Code:
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 بتاعتهم هتساعدك تفهم الموضوع بشكل اكبر وتشتغل بأيدك: