ソース：
脆弱性：Web Cache
訳：
- 最初のリクエストをリピーターに送信し
- 応答が正常にキャッシュされた場合、ブラウザで URL を開くと、400 Bad Request が表示されるはずで。
アプリケーションにログイン機能がある場合
- アカウントを作成する
- ページ内に機密情報が開示されているかどうかを確認し (セッション トークンなど)
- 認証されたアカウントを使用して変更された URL を開き
- Curl またはプライベート Web ブラウザ ウィンドウを使用して同じ URL を開く
アプリケーションがCloudflare CDNを使用している場合
不正なヘッダーは機能せず、現在、ほとんどの Cloudflare 顧客は Cache Deception Armorを使用していて。
本当に未知の拡張子ファイルである .avif ファイルを使用して、この保護をバイパスすることができ。
ただし、この保護が有効になっていないサイトもあり、キャッシュポイズニング/欺瞞を完全にテストでき。
実際の事例
キャッシュ詐欺によるアカウント乗っ取り → 報奨金 = 1,500 ドル
まとめ：
すべての Cookie (HTTP のみの Cookie も含む) は https://host.com/app/conversation/1.js で公開されていて。
認証されたユーザーがこの URL にアクセスすると、すべての Cookie がキャッシュに保存されて。
その後、攻撃者は Cookie を抽出してセッションをハイジャックすることができて。
- 注記：
場合によっては、応答が「404 Not found」の場合、Akamai は応答を 10 秒未満しかキャッシュしないため、攻撃者にとってこれが難しくなり。
この場合、攻撃者は迅速である必要がありますが、Akamai が 200 OK レスポンスを検出した場合、レスポンスは少なくとも 24 時間持続し。
- ヒントとコツ
一部のアプリケーションでは、拡張子の前にセミコロン (;) を追加すると、200 OK 応答が返される場合があり。
例えば
/xxxx/xxxxxx/;.js
応答
キャッシュポイズニングによる DoS → 報奨金 = 1,000 ドル
まとめ：
Akamai CDN でバックスラッシュを送信すると、 \ ヘッダーとして、サーバーは 400 で応答します。 Bad Request 応答
リクエスト：
レスポンス：
これは、サイトでキャッシュ サーバーを使用している場合に問題になり。
通常、サイトは JavaScript、CSS、その他のファイルのみをキャッシュしますが、サイトが次のような場合は、 www.host.com 次のような通常の応答もキャッシュし。
www.host.com/products/*
www.host.com/*
等..
非常に影響の大きいバグとなり。
- ヒントとコツ
アカマイには、 workaround このエクスプロイトでは、400 応答がキャッシュ内で 5 秒間だけ残るようにすることで、攻撃者がげっぷの侵入者を使用してヌル ペイロードを送信できるため、同じ 400 応答が永久にキャッシュされるようになり。
保存された XSS へのキャッシュ ポイズニング → 報奨金 = 1,000 ドル
まとめ：
経由の XSS があります。 n_vis クッキーパラメータ
サーバーはこの応答をキャッシュするため、攻撃者は XSS ペイロードを保存できる可能性があり。
ほとんどのペイロードをブロックする強力なフィルター (および WAF) がありますが、サイトは Jquery を使用しているため、攻撃者は $.getScript これを悪用する機能。
リクエスト
レスポンス
- ヒントとコツ
リクエスト ヘッダー、Cookie、カスタム ヘッダー、X-Forwarded-* ヘッダーの XSS をテストします。
ほなほな。
