WebのCDN関連のインシデントの事例
CDNを新たに導入した時、CDNを新しいCDNに移行する時に起こりがち 「cacheすべきでない情報(e.g. 個人情報)」を誤ってcacheしてしまうことで流出し、インシデントが生じる どのように対策すればよいのかは、報告文を読んでも殆ど参考にならない
Omiai
2021/5/22頃
コーポレートサイト(Omiaiそのものではない)の問い合わせフォームで送信された個人情報が、他のuserから閲覧できる状態になった
原因はサーバー増強のために行ったプラットフォーム移行に伴うシステム設定の不備
フォームに投稿した内容がcacheに残り、過去の記載内容を表示した
あんまり詳しく書いてないのでよくわからんmrsekut.icon
関連
↑Omiaiは、これの同時期に、不正アクセスにより会員情報(免許証の画像データ)を流出している
でもこのへんは、cache云々は関係なさそう
SOD
2020/3/16頃
CDNを新たに導入した際にインシデント発生
顧客情報の一部が他のユーザーから閲覧可能となった
雑な流れ
サービスの閲覧者数が増えてきたので急遽CDNを導入することになった
導入後、公開したが設定の不備がありそうなのでメンテナンスモードにし、
「個人情報をキャッシュしない」「画像/JS/CSSのみキャッシュで設定」などの設定し直して公開したが、何故かCDNに反映されなかったため再び流出した
最終的に、CDNを使用しないようにして対策した
再発防止のために
セキュリティの専門家に確認してもらう
メルカリ
2017/6/22頃
CDNを、旧のものから新のものに切り替えた際に、新での設定ミスでインシデント発生
一部ユーザーの個人情報が、他のユーザーから見れる状態になった
旧の使用時の設定
browser上のcache制御にはCache-Controlを使っていた
nginxでexpires -1でExpiresを1秒前にし、
Cache-Control: no-cacheでoriginに問い合わせするようにしてた
CDN上のcache制御は、CDNの設定を使っていた
つまりCache-Controlヘッダは無視されるようにしていた
以上により、
privateな情報はbroser上でのみcacheされ、かつ毎回freshになる
sharedなものはCDNで使用する
という理想的な状態にあった
新使用時の設定
browser上のcache制御
旧のときと同じ
CDN上のcache制御
Cache-Controlを見るようになっていた
つまり、Cache-Control: no-cache
インシデントが起きたのはFastlyの仕様がイミフだから
だけど、Fastlyを使っていなかったとしてもこれは設定がおかしいmrsekut.icon
という2段階のミスがあるmrsekut.icon
CDNがもしRFCに沿っているものだった場合、
Cache-Contro: no-cacheなので、CDN上でcacheされるものの、毎回originに問い合わせるので新しいものになるので問題は起きづらい
ただ、本来はprivateなものをCDN上にcacheするべきじゃないのでno-cacheは理想的ではないmrsekut.icon
Cache-Control: privateにしないとcacheされる
従って、個人情報もしっかりcacheされ、流出に至った
キャッシュの有効期限が0秒となる場合、CDNからオリジンへのリクエストの処理中に、同じURLに対してリクエストが発生すると、最初のレスポンスを待って、2つ目以降のリクエストにも同じレスポンスが返される仕様になっていました。
この「仕様」はFastlyがおかしいのか、そうじゃないのかわからない #?? 再発防止のために
CDNによる意図しないキャッシュを早期に検知できる仕組みを導入
具体的に何をしたかは書いてないのでわからんmrsekut.icon