の件について思ったことをつらつらと
IPアドレスで個人特定可能か、IPアドレスは個人情報かどうか
これについては楠さんの説明が良さげ。単体で個人特定は難しいけど、いろいろ紐付けることができると個人特定できる可能性がある。そして紐付いた状態で保存されていると個人情報保護法の対象になる。
原因
今は修正済みなので自分は解析していないのだが、以下の方によるとAPIの出力にIPアドレスが入っていて、それをHTMLに出力したっぽい。
noteのIPアドレスの不具合の件。
— 池田 泰延 / Yasunobu Ikeda (@clockmaker) 2020年8月14日
外野から分析してみました。
■原因(予想)
・Nuxt.jsのSSR処理が引き金
・API返却値に含まれたIPをSSRでうっかりHTMLに出力
GoogleキャッシュやWaybackMachineに昔のコードが残っており、現時点でも追跡可能なので早急に対策を。https://t.co/EQRpE3Bckw
該当のAPIの出力を今見ると、IPアドレス等は出力されていないのだが、問題発生時は以下のような属性が出力されていたようだ。
APIの「このクリエイターの人気記事」の箇所にユーザーの詳細情報が存在し、「メールアドレスの認証状態」「下書きの数」らしきフィールドが存在します。
— 池田 泰延 / Yasunobu Ikeda (@clockmaker) 2020年8月14日
ここにIPアドレスのフィールド「last_sign_in_ip」（今は空文字）も存在しますね。 pic.twitter.com/KbH0T6XLK8
last_sign_in_ipはRails+Deviseでユーザモデルが保持する属性なので、このAPIはRails+Deviseで構成されていると予想される。
Devise批判
Deviseの属性をそのまま出しているということから、以下のようなDeviseに対する批判も出てきている。
ただ、自分の意見は以下の方の意見に近いかな。
DeviseはRailsを深く理解しないと使ってはダメと言っているのか
深く理解というのがどのレベルなのか曖昧なのだが、README読んだ感じだと、Railsの認証周りの文書を読んで、動きを理解してから使えよというぐらいかと。
Devise使うとIPアドレスが漏洩するか
User.attributes.to_jsonするとipアドレスが含まれるようだが、User.to_jsonでは含まれない。それ以前に、モデルクラスを何も加工せずにWeb APIのレスポンスとして出力する方が問題なので、DeviseではなくWeb API仕様・設計の問題だと思う。
再発防止策
noteが示している対策はそんなに悪くないのではという気がする。
対策
・全ソースコードに対して、IPアドレス及びそれ以外のセンシティブな情報が露出するような同様の欠陥がないことを調査し、さらに対応するデータベースからIPアドレスのデータを削除しました
・CEO・CTO直轄の特別対策チームを結成して、直接の対策と構造的な課題や開発体制までを含めた徹底的な見直しを行います
・ソースコードのレビューおよびテストに今回の不具合や関連するセキュリティに対する観点を追加します
・データの持ち方やセンシティブな情報にアクセスするプロセスを見直します
・外部の複数の専門企業に依頼し、noteの脆弱性を発見・対策できるよう第三者の目線からの脆弱性診断をおこなってまいります
ただ、Web API仕様・設計のセキュリティ観点のレビューもした方が良いと思う。
