Hello there, ('ω')ノ
保存された XSS へのキャッシュ ポイズニングの連鎖を。
脆弱性：
Stored XSS
記事：
https://nahoragg.medium.com/chaining-cache-poisoning-to-stored-xss-b910076bda4f
開発者であることの利点の 1 つは、サーバ側で物事がどのように動作しているかを
推測できることで。
特にアプリケーションが何らかのフレームワークまたは CMS で構築されている場合、
開発者が特定の機能をどのようにコーディングしたか、またはアプリケーションを
どのように構成したかをデバッグしてみることができ。
たとえば、Rails フレームワークを使用する多くの開発者は、Scaffold を使用して、
モデル、ビュー、コントローラーなどのアプリケーションの主要部分を
1 回の操作で迅速に生成し。
これに加えて、Scaffold は各ルートの JSON API エンドポイントも自動的に作成して。
これはほとんどの場合、開発者によって見落とされているか、運用環境に
プッシュするときにこの JSON エンドポイントを削除するのを忘れていて。
そのため、通常のルートから機密情報を削除した開発者は、そのルートの
JSON エンドポイントから同じ情報を削除することを忘れる可能性があり。
このような構成ミスをチェックすると、Rails アプリケーションの機密データが
漏洩する可能性があり。
したがって、アプリケーション テクノロジに関する知識があると、
他の人よりも優れた発見が得られ。
Hackerone のバグ報奨金プログラムで Drupal アプリケーションを見つけ。
以前に Drupal を使用したことがあったので、Drupal に関連する一般的な
設定ミスを探し始めました。 そして10分以内に1つ見つけ。
以前に Drupal で開発したことがある場合は、デフォルトで有効になっている
独自の内部キャッシュ システムがあることをご存じかもしれませんが。
キャッシュが有効かどうかを確認する最も簡単な方法は、応答内の
x-drupal-cache ヘッダを探すことです。
したがって、リクエストで一意のキー（エンドポイント + パラメータ）を
指定すると、応答で x-drupal-cache: MISS ヘッダが返されますが、
同じキーで再度リクエストすると、応答で x-drupal-cache: HIT ヘッダーが返され、
キャッシュされ有効になっていて。
キャッシュが有効になっていることを知った後、悪用できる方法の 1 つは、
XSS ペイロードでキャッシュを汚染することで。
ただし、そのためには、応答に反映される HTTP ヘッダを見つける必要があり。
drupal は他の PHP フレームワークと同様に、Zend のおかげで
X-Original-URL ヘッダと X-Rewrite-URL ヘッダをサポートする場合があるため、
これらのヘッダーをリクエストに挿入しようとしましたが、残念ながら
アプリケーションは受け入れず。
何もうまくいかない場合は、ブルートフォース攻撃を試して。
そこで、一般的なヘッダを総当たり攻撃する Param Miner と呼ばれる
Burp Suite拡張機能を使用し数秒後、当たりが出て。
応答に反映されていた style という名前のヘッダが見つかり。
XSS に対して脆弱かどうかをすぐに確認したところ、脆弱で。
その後、保存された XSS にキャッシュ ポイズニングを簡単に連鎖させることが
できることがわかり。
一意のキーを作成し、XSS ペイロードを含むスタイル ヘッダを追加して、
リクエストを起動し。
XSS ペイロードを含む応答は、上記の一意のリクエストに対してキャッシュされ。
これで、誰かが www.redacted.com/?q=admin&liec4897=1 にアクセスするたびに、
有害な応答が drupal によって提供され、保存された XSS が生成され。
Drupal の単純な構成ミスにより、保存された XSS が発生して。
Best regards, (^^ゞ
