HackCert
Intermediate 10 min read May 25, 2026

Request Smuggling: ওয়েব সার্ভার এবং প্রক্সির মধ্যে ডেটা পার্সিংয়ের দুর্বলতা ব্যবহার করে হ্যাকিং!

HTTP Request Smuggling-এর মূল ধারণা, CL.TE/TE.CL/TE.TE ভেরিয়েন্ট এবং ক্যাশ পয়জনিংসহ এক্সপ্লয়টেশন।

Ayesha Siddika Rahman
Web Application Security Researcher
share
Request Smuggling: ওয়েব সার্ভার এবং প্রক্সির মধ্যে ডেটা পার্সিংয়ের দুর্বলতা ব্যবহার করে হ্যাকিং!
Overview

ওয়েব নিরাপত্তার দুনিয়ায় কিছু আক্রমণ প্রকৃতিতে এতই সূক্ষ্ম যে তাদের শনাক্ত করতে এবং বুঝতে বছরের পর বছর লেগেছে। HTTP Request Smuggling তেমনই একটি আক্রমণ। ২০০৫ সালে Watchfire-এর গবেষকরা প্রথম এই দুর্বলতা ডকুমেন্ট করেছিলেন, কিন্তু এটি প্রকৃত মনোযোগ পায় ২০১৯ সালে যখন PortSwigger-এর James Kettle তার গবেষণা "HTTP Desync Attacks: Request Smuggling Reborn" প্রকাশ করেন। সেই থেকে এই আক্রমণ ক্লাস Slack, PayPal, Akamai এবং অসংখ্য বড় কোম্পানির ইনফ্রাস্ট্রাকচারে গুরুতর দুর্বলতা প্রকাশ করেছে—কেউ কেউ ছয় অঙ্কের bug bounty payout পেয়েছেন। এই নিবন্ধে আমরা Request Smuggling-এর প্রযুক্তিগত গভীরতায় যাব—কীভাবে এটি কাজ করে, কেন আধুনিক architecture এটি সম্ভব করে, এবং কীভাবে নিজেদের রক্ষা করা যায়।

সমস্যার মূলে: HTTP/1.1 Ambiguity

HTTP/1.1 প্রোটোকল একটি request-এর body length নির্ধারণের জন্য দুটি ভিন্ন পদ্ধতি অনুমোদন করে: Content-Length (CL) হেডার এবং Transfer-Encoding (TE) হেডার। RFC 7230 বলে যে যদি উভয় header উপস্থিত থাকে, Transfer-Encoding অগ্রাধিকার পাবে। সমস্যা হলো বিভিন্ন HTTP server এবং proxy বিভিন্নভাবে এই specification interpret করে।

আধুনিক ওয়েব আর্কিটেকচারে সাধারণত একটি reverse proxy বা CDN (Cloudflare, Akamai, Fastly, AWS CloudFront) frontend-এ থাকে এবং backend application server (Apache, Nginx, Node.js, Tomcat) থাকে অন্যপাশে। যখন frontend এবং backend একই request-এর boundary ভিন্নভাবে interpret করে, তখন request smuggling সম্ভব হয়। একটি single HTTP message-কে দুটি ভিন্ন interpretation দেওয়া হয়—একটি frontend-এর জন্য, একটি backend-এর জন্য।

এর ফল হয় ভয়াবহ। Attacker একটি কৌশলে structured request পাঠায় যা frontend একভাবে parse করে এবং backend আরেকভাবে। ফলে backend-এর queue-এ একটি "smuggled" request প্রবেশ করে যা পরবর্তী legitimate user-এর request-এর সাথে মিশে যায়।

প্রধান Variants

Request Smuggling-এর সাধারণত চারটি প্রধান variants রয়েছে:

CL.TE (Content-Length Frontend, Transfer-Encoding Backend): Frontend Content-Length follow করে, backend Transfer-Encoding follow করে। একটি সাধারণ exploit এরকম দেখায়:

POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

Frontend Content-Length 13 দেখে পুরো request body পড়ে এবং backend-এ forward করে। কিন্তু backend Transfer-Encoding: chunked দেখে, "0" chunk-কে end-of-body হিসেবে interpret করে। ফলে "SMUGGLED" পরবর্তী request-এর শুরু হিসেবে treat হয়।

TE.CL (Transfer-Encoding Frontend, Content-Length Backend): ঠিক উল্টো। Frontend chunked encoding প্রক্রিয়া করে, backend Content-Length অনুসরণ করে।

TE.TE (Transfer-Encoding Obfuscation): উভয়ই TE অনুসরণ করে, কিন্তু attacker একটি obfuscated TE header পাঠায় যেমন Transfer-Encoding: chunked\r\nTransfer-Encoding: x বা Transfer-Encoding : chunked (space included)। দুটি server এই obfuscation ভিন্নভাবে interpret করে।

CL.0 এবং H2.CL: HTTP/2 ডাউনগ্রেড আক্রমণ। যখন HTTP/2 frontend HTTP/1.1 backend-এর সাথে কথা বলে, h2c smuggling, CRLF injection-এর মাধ্যমে header injection ঘটতে পারে।

HTTP/2-এর সমস্যা

অনেকে ধরে নিয়েছিল HTTP/2-এর strict binary protocol request smuggling-এর সমাপ্তি ঘটাবে। কিন্তু James Kettle এর "HTTP/2: The Sequel Is Always Worse" গবেষণা প্রমাণ করেছে এর বিপরীত। অনেক frontend HTTP/2 গ্রহণ করে কিন্তু backend-এর সাথে HTTP/1.1-এ কথা বলে—এই downgrade পয়েন্টে নতুন smuggling সুযোগ তৈরি হয়।

H2.CL Smuggling: HTTP/2-তে Content-Length optional, কিন্তু downgrade হলে frontend একটি Content-Length যোগ করে যা backend-এর parsing-এর সাথে সামঞ্জস্যপূর্ণ নাও হতে পারে।

H2.TE: HTTP/2-তে Transfer-Encoding header নিষিদ্ধ, কিন্তু কিছু implementation এটি allow করে যা downgrade-এর পর chaos সৃষ্টি করে।

CRLF Injection in HTTP/2 Headers: HTTP/2 binary, তাই CRLF নিষিদ্ধ। কিন্তু কিছু implementation header value-তে CRLF অনুমোদন করে, যা HTTP/1.1-এ downgrade-এর সময় new header inject করার সুযোগ দেয়।

Exploitation Scenarios

Request Smuggling নিজে একটি দুর্বলতা, কিন্তু এর প্রকৃত শক্তি কী অর্জন করা যায় তাতে।

Bypassing Frontend Security Controls: যদি frontend-এ WAF থাকে যা শুধু request-এর শুরু পরীক্ষা করে, smuggled request সেই inspection এড়িয়ে যেতে পারে। একটি admin endpoint যা শুধু internal network থেকে accessible, frontend bypass করে সরাসরি hit করা যায়।

Capture Other Users' Requests: এটি সবচেয়ে ভয়ংকর exploitation। একটি smuggled request যা একটি POST endpoint-এ data save করে এবং পরে retrieve করা যায়—তার দ্বারা পরবর্তী victim user-এর full HTTP request (headers, cookies সহ) capture করা যায়। PortSwigger-এর Web Security Academy-তে এই lab বিশেষভাবে শিক্ষণীয়।

Cache Poisoning: যদি smuggled request একটি cached resource-এর response পরিবর্তন করে, পরবর্তী users malicious content পায়। ২০২০ সালে PayPal-এ এই ধরনের একটি দুর্বলতা পাওয়া গিয়েছিল যা session hijacking-এর দিকে নিয়ে যেতে পারত।

Web Cache Deception: Smuggled request-এর মাধ্যমে private content-কে public cache-এ পৌঁছানো যায়।

Reflected XSS Without User Interaction: যেহেতু আপনি অন্য user-এর request prefix নিয়ন্ত্রণ করছেন, traditional XSS যা সাধারণত user interaction দাবি করে, সেটি unauthenticated বা automated হয়ে যায়।

Cross-Site Request Forgery (CSRF) Token Bypass: CSRF protection বাইপাস করা সম্ভব হয় যখন backend মনে করে request একটি বৈধ session থেকে এসেছে।

Detection টেকনিক

Request Smuggling শনাক্ত করা কঠিন কারণ traffic দেখতে বৈধ মনে হয়। কিছু পদ্ধতি ব্যবহার করা হয়:

Timing-Based Detection: PortSwigger Burp Suite-এর HTTP Request Smuggler extension জনপ্রিয় টুল। যদি একটি smuggled request backend-এ pending থেকে যায়, পরবর্তী legitimate request-এর response time অস্বাভাবিকভাবে বৃদ্ধি পায়। এই timing differential দিয়ে দুর্বলতা শনাক্ত করা যায়।

Differential Response Detection: দুটি ভিন্ন payload পাঠিয়ে response-এর পার্থক্য বিশ্লেষণ। যদি একটি payload smuggled request তৈরি করে যা পরবর্তী response-এ visible হয়, এটি একটি confirmation।

Smuggler Tool: defparam-এর Smuggler একটি জনপ্রিয় Python টুল যা বিভিন্ন payload mutation চেষ্টা করে।

Real-World Cases

Slack Bug Bounty: ২০২০ সালে evan ricafort এবং পরে others Slack-এ multiple smuggling vulnerabilities আবিষ্কার করেন যা সংস্থাকে গুরুতর কনফিগারেশন পরিবর্তন করতে বাধ্য করে।

PayPal CL.TE: একটি জনপ্রিয় report যেখানে PayPal-এর backend গুরুত্বপূর্ণ authentication-related endpoint-এ smuggling-এর দুর্বল ছিল।

Akamai এবং অন্যান্য CDN: এমনকি বিশ্বের বৃহত্তম CDN provider-রাও smuggling দুর্বলতার শিকার হয়েছে, কারণ প্রতিটি CDN ও origin combination একটি unique attack surface।

AWS ALB Smuggling: Application Load Balancer-এ ২০২২ সালে আবিষ্কৃত একটি দুর্বলতা যা attackers-দের internal request inject করার সুযোগ দিয়েছিল।

প্রতিরোধ ও প্রতিকার

Request Smuggling-এর প্রতিরক্ষা একটি multi-faceted approach দাবি করে।

Use HTTP/2 End-to-End: সবচেয়ে কার্যকর প্রতিরোধ হলো frontend এবং backend উভয়ের মধ্যে HTTP/2 ব্যবহার করা। কোনো downgrade না থাকলে অনেক smuggling variant অসম্ভব হয়ে যায়। কিন্তু এটি সব backend support করে না।

Strict HTTP Parsing: Backend server-এ strict parsing mode সক্রিয় রাখুন। Apache-এ RequestReadTimeout, Nginx-এ client_header_buffer_size এবং large_client_header_buffers-এর সঠিক configuration। ambiguous request পেলে সেগুলো reject করা।

Normalize Headers at the Frontend: Frontend proxy ক্ষেত্রে CL এবং TE উভয় header থাকলে সেটিকে reject করা বা frontend-এ স্বাভাবিকীকরণ করে শুধু একটি পাঠানো।

Reject Obfuscated Headers: Transfer-Encoding: chunked\r\nTransfer-Encoding: x বা space-included variants reject করতে হবে। RFC-compliant parsing বাধ্যতামূলক।

Disable Connection Reuse: যদিও performance-এ প্রভাব পড়ে, frontend এবং backend-এর মধ্যে connection reuse disable করা smuggling-এর impact কমায়। কারণ smuggled request পরবর্তী request-এর সাথে মিশতে পারে শুধু shared connection-এ।

Web Application Firewall: AWS WAF, Cloudflare এবং অন্যান্য আধুনিক WAF-এ ক্রমাগত smuggling-এর জন্য signature যোগ করা হচ্ছে। তবে WAF একটি স্বাধীন প্রতিরক্ষা নয়—দুর্বল underlying parsing fix করা মূল সমাধান।

Vulnerability Scanning: Burp Suite Pro-এর built-in scanner এবং HTTP Request Smuggler extension দিয়ে নিয়মিত স্ক্যানিং। CI/CD pipeline-এ ZAP বা commercial DAST integrate করা।

Defense in Depth: যদি smuggling সম্ভব হয়, তবে এর impact কমাতে strict session management, short token lifetime এবং sensitive operation-এ MFA prompt গুরুত্বপূর্ণ।

Patching: Apache, Nginx, IIS, Tomcat-এর সকল recent CVE-এর জন্য প্রতিরোধমূলক patching। CDN provider-এর security bulletin-এ নজর রাখুন।

Tooling এবং Learning

PortSwigger-এর Web Security Academy এই আক্রমণ শেখার সর্বোত্তম platform। সেখানে free lab আছে যেখানে CL.TE, TE.CL, TE.TE সবগুলো variant practice করা যায়। James Kettle-এর Black Hat talks (২০১৯, ২০২১) দেখা অপরিহার্য। Burp Suite Pro-এর HTTP Request Smuggler extension বাস্তব testing-এর জন্য সবচেয়ে কার্যকর টুল।

Key Takeaways

HTTP Request Smuggling প্রমাণ করে যে কেন একটি প্রোটোকলের specification-এর প্রতিটি কোণা পরিষ্কারভাবে define করা গুরুত্বপূর্ণ। দুই দশক ধরে HTTP/1.1 ব্যবহার করার পরেও আমরা নতুন smuggling variant খুঁজে পাচ্ছি, কারণ প্রতিটি নতুন combinatione frontend-backend pair একটি unique attack surface তৈরি করে। আধুনিক web architecture-এ একটি smuggling দুর্বলতা একটি প্রতিষ্ঠানের পুরো security posture কে নষ্ট করতে পারে। তাই strict parsing, end-to-end HTTP/2 এবং নিয়মিত security testing—এই সব মিলে এই সূক্ষ্ম কিন্তু ভয়ংকর আক্রমণের বিরুদ্ধে কার্যকর প্রতিরক্ষা গড়ে তুলতে পারে।

আপনার জ্ঞান যাচাই করতে প্রস্তুত? আজই HackCert-এ Request Smuggling MCQ Quiz-টি দিন!

Related articles

back to all articles