Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

BUG: HTTPTarget sends conflicting Content-Length and Transfer-Encoding headers

クローズ
  • 何か問題がありますか？
#3,202 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@Kaap10 がすでに取り組んでいます。

2026年10月6日 から。

  • #3008 @Kaap10 による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
python
領域
api

調査の方向性

Start in parse_raw_http_request in pyrit/prompt_target/http_target/http_target.py, where only content-length is popped from the parsed headers. Check open PR #3008 first, since it already touches this branch and may overlap. Done means neither framing header survives parsing and the body is sent intact, which the suggested MockTransport test in tests/unit/prompt_target/target/test_request_tracing.py can pin.

索引モデルが issue の本文から書いたものです。

説明

Bug: triage
Describe the bug

HTTPTarget.parse_raw_http_request strips content-length from the parsed header dict so that httpx can compute the correct value for the (possibly converter-modified) body:

https://github.com/microsoft/PyRIT/blob/main/pyrit/prompt_target/http_target/http_target.py#L290-L291

if "content-length" in headers_dict:
    del headers_dict["content-length"]

transfer-encoding is not stripped. When a raw request contains Transfer-Encoding: chunked (common when pasting from Burp), that header survives into the request, httpx/h11 chunk-frames the body, and httpx still adds its own Content-Length. Both framing headers ship on the same request.

RFC 9112 §6.1 states a sender MUST NOT send Content-Length in any message that contains a Transfer-Encoding header field. §6.3 requires recipients that receive both to treat the message as unrecoverable, and recommends intermediaries forwarding such a message strip Content-Length.

Two concrete impacts:

  1. Silent truncation / mojibake. The chunk-framed body is 20 bytes on the wire but Content-Length advertises 11 (the decoded length). Any intermediary or server that honors Content-Length reads a prefix of the chunked framing. With multibyte content this truncates mid-UTF-8 and the operator sees corrupted text rather than an error.
  2. Request smuggling shape. This is textbook CL.TE desync. PyRIT emits it with no warning, so an operator cannot tell whether an anomalous target response is a finding or a PyRIT framing artifact. For a tool whose output is security evidence, that ambiguity is the real cost.

This is pre-existing on main and unrelated to any open PR; I confirmed it reproduces both on main and on the branch in #3008.

Steps/Code to Reproduce
import asyncio, socket, threading

from pyrit.executor.attack import PromptSendingAttack
from pyrit.prompt_target import HTTPTarget
from pyrit.setup import IN_MEMORY, initialize_pyrit_async

captured = []
srv = socket.socket(); srv.bind(("127.0.0.1", 0)); srv.listen(1)
port = srv.getsockname()[1]


def serve():
    conn, _ = srv.accept()
    buf = b""
    while b"0\r\n\r\n" not in buf:
        chunk = conn.recv(65535)
        if not chunk:
            break
        buf += chunk
    captured.append(buf)
    conn.sendall(b"HTTP/1.1 200 OK\r\nContent-Length: 2\r\n\r\nok")
    conn.close()


threading.Thread(target=serve, daemon=True).start()

raw = (
    "POST / HTTP/1.1\r\n"
    f"Host: 127.0.0.1:{port}\r\n"
    "Transfer-Encoding: chunked\r\n"
    "Content-Length: 11\r\n"
    "\r\n"
    "{PROMPT}"
)


async def main():
    await initialize_pyrit_async(memory_db_type=IN_MEMORY)
    target = HTTPTarget(http_request=raw, prompt_regex_string="{PROMPT}", use_tls=False)
    await PromptSendingAttack(objective_target=target, max_attempts_on_failure=0).execute_async(
        objective="hello world"
    )
    print(captured[0].decode())


asyncio.run(main())
Expected Results

Exactly one framing header on the wire. Either transfer-encoding is stripped alongside content-length so httpx owns framing, or chunked framing is honored and no Content-Length is emitted.

Actual Results

Both framing headers are sent, and the Content-Length value does not describe the bytes actually transmitted:

POST / HTTP/1.1
host: 127.0.0.1:49678
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
User-Agent: python-httpx/0.28.1
transfer-encoding: chunked
content-length: 11

b
hello world
0

Body is chunk-framed (b\r\nhello world\r\n0\r\n\r\n, 20 bytes) while content-length: 11 describes the decoded length. No warning or error is raised.

Suggested fix

Strip both hop-by-hop framing headers in parse_raw_http_request and let httpx own framing, consistent with the existing intent for content-length:

for framing_header in ("content-length", "transfer-encoding"):
    headers_dict.pop(framing_header, None)

A regression test using httpx.MockTransport (matching the pattern in tests/unit/prompt_target/target/test_request_tracing.py) can pin that neither header survives parsing and that the body is sent intact.

If preserving operator-supplied chunked framing is considered in scope, that is a larger change and should be explicit rather than the current accidental middle state.

Screenshots

N/A

Versions
  • OS: Windows
  • Python version: 3.14
  • PyRIT version: installed from main in editable mode (1.2.0.dev0)
  • httpx: 0.28.1
主要言語
Python
スター
4.6k
フォーク
944
平均マージ
2日 18時間
マージ済み PR（30日）
358

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/PyRIT のほかの issue

microsoft/PyRIT の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。