> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/ja/web/host-header/bypassing-validation-by-connection-state.md).
# 接続状態による検証のバイパス
接続状態による検証のバイパスの PortSwigger Web Security Academy ラボ向けノート。攻撃フロー、ペイロードテスト、Burp Suite による検証、および是正策の文脈を含みます。
### 接続状態攻撃によるホスト検証のバイパス
**脆弱性の説明**
このラボには **Host 経由のルーティングに基づくSSRF型の脆弱性が** あり、サーバー側接続の状態管理が不十分なことに関連しています。
フロントサーバーは適切に `Host` ヘッダーを検証しているように見えますが、危険な\*\*仮定\*\*をしています:
> 同じTCP接続で送信されたすべてのリクエストは、 **最初のリクエスト** が有効であれば信頼できると見なされます。
これにより、後続の悪意あるリクエストを同じ接続上に挿入し、最初の検証をバイパスできます。
**ラボの目的**
* 内部管理パネルにアクセスする: / `HTTP://192.168.0.1/admin`
* ユーザーを削除 **carlos**
**初期観察**
内部IPへの直接リクエストはブロックされます:
```http
GET / HTTP/1.1
Host: 192.168.0.1
```
サーバーはこのリクエストを拒否します。これは `Host` 検証が行われている **ことを最初のリクエストで**.
**操作: 接続状態攻撃**
考え方は、\*\*同じTCP接続で複数のリクエストを送信する\*\*ことです:
1. 公開ホストへの正当な最初のリクエスト（受理される）。
2. 内部IPへの2つ目の悪意あるリクエストを **同じ接続上で送信する。**.
Burp Suite では、これは次のように行います:
* リクエストをグループ化する
* を使用する **Send group in single connection**
**管理パネルへのアクセス**
有効なクエリで接続が確立されると、内部管理者宛ての次のリクエストは受理されます:
```http
GET /admin HTTP/1.1
Host: 192.168.0.1
```
その後、内部管理パネルにアクセス可能になります。
**ユーザーの削除**
ユーザーを削除するにはPOSTクエリが必要です:
```http
POST /admin/delete HTTP/1.1
Host: 192.168.0.1
csrf=ppBVKn8wVrgZifEETHsn48Hykwiq8yFO&username=carlos
```
サーバー応答:
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://hacking-notes.jord4n.pro/ja/web/host-header/bypassing-validation-by-connection-state.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
