【書評】Webブラウザセキュリティ、を読んだ

こんにちは、こふです。

Web ブラウザセキュリティ Web アプリケーションの安全性を支える仕組みを整理するを読みました。

お忙しい方のためのカンタン評価です。あくまで個人的感想です。

• もう一度読みたいか
  • Yes
  • 理解を後回しにした部分が大きいため
• 定価の価値があったか
  • Yes
• 誤字脱字・編集ミスを見つけたか
  • No

• 他人にオススメするなら
  • ★★★☆☆
  • 少なくともハズレ本という人はいないと思う
• 文章の読みやすさ
  • ★★★★☆
  • 論理的に説明してくれているため比較的スムーズ
  • 当然、知識レベルにもよる
• わかりやすさ
  • ★★★☆☆
  • 前提知識によるため、個人差あり

• Web ブラウザを介して何かをすることは現状まだまだあるし、今後もある。
• そのため、ブラウザのセキュリティ面での問題点がどのようにあって、どのように対策されてきたかを知りたかった（歴史を知る意味を込めて）
  • モバイルアプリの内部でも Web ブラウザが開いていることもある
  • 何よりパソコンで Web にアクセスするのは今後もしばらくは必ず続くから（技術的な革新があるかもしれないけど）
  • 歴史を知ることは面倒に思えるけど、経緯を理解して今後の流れをなんとなく掴む上では必要だと割り切っている
  • 【書評】最新 いまさら聞けないビットコインとブロックチェーン、を読んだ - こふぶろぐもその理由で読んでもいる
• 全体像を知りたかった
  • コードを実際に動かしたり、難解な箇所は完全にスキップして、全体像の把握だけをすることにした

• Web アプリケーション開発、ツール開発において脆弱性を生まないために簡単な調査をしたことがあった
  • XSS
    • 簡単なデモは試したことあり（ローカルで）
  • CSRF
    • 推測不可能な Token を渡してリクエスト元が本当に正当なリクエスト元かを判断するような大雑把なことは知っていた。実装はしていない
• また、セキュリティ対策（SQLインジェクション・CSRF・XSS）はライブラリに完全に任せていた
  • 例えば、React で以下のは脆弱性を生むため、使わないなどはしている
  • Using dangerouslySetInnerHTML in a React application - LogRocket Blog
  • バックエンドのライブラリに CSRF の実装は任せているし、完全にただ使っていただけだった
• 要するに完全な初心者
• ネットでググってもある程度記事が出てくるが、セキュリティ分野はネットで是非を判断しづらいから怖かった（企業の記事でもミスは全然あるらしい）
• また、本の方が知識が体系化されているため理解が容易に思っている

• 世の中にあまりない分野の本ではあったが非常に詳しい記述をしている本で読み応えがあった
• 参考文献も RFC が多く、丁寧に調査された内容だと推測できたし、好感が持てた

詳細は書ききれないし、読むべきなので大まかに。順不同。

思い出せる範囲でとりあえずメモ。

• 同一オリジンかクロスオリジンかの判別の考え方
  • 低いレイヤーで考えており、理解がしやすかった
  • スキーマ、ホスト、ポート番号など複数あるが、どれが同じなら同一オリジンか？ということ
• クライアント・サーバーモデルのように分けてシステムが構築されるが、それぞれを対策（Web ブラウザ側なら XSS、サーバーなら SQL インジェクションなどの対策）していても、キャッシュの使い方を間違えて機密情報が漏れるなどの危険性もあるということ
  • 過去にメルカリで CDN のミスがあったが、これに関連している事件だと思った
  • CDN 切り替え作業における、Web 版メルカリの個人情報流出の原因につきまして | メルカリエンジニアリング
• ブラウザ自体が非常に複雑で難しいという点
  • マルチスレッドに動かさないと遅いが、どこをどう分けるかなど、難しすぎて想像がつかない
  • メモリ空間が共有されていたら、一つの脆弱性で読み取られて他のも奪われるみたいなのが発生しうる
• https へのアクセスを強制させる仕組み
  • 結構感動した、今まで疑問にあまり思わないくらい当然だと思ってしまっていた
  • 当然 Web サーバー側で証明書発行して対応していることが前提として、だけど
    • TLS のハンドシェイクの流れは知っていた
  • 初回アクセスで meta タグから何かを指定して https にリダイレクト
  • その後のリクエストでも https にアクセスすることをブラウザに覚えてほしい、となる
  • そこで HSTS がある
  • これにより https へのアクセスをする、ということを記憶してくれる
  • Cookie 同様に期限も決められる
• HTTP リクエストの Header にセキュリティに関するルールがたくさん書かれている（そこで決めている）事実
• Cookie の仕組み（というより仕様）
  • 有効な期間を指定するのは知っていたが、指定しない場合はブラウザのセッションがきれたら無効になる
  • 無効になる＝過去を指定という考え
  • HTTP Only にするとどうなるか
    • XSS の対策にはならない
    • 単に JavaScript の cookie オブジェクトが呼び出せなくなるだけだった
    • 回避するために Cookie を上書きするくらいまで追加する攻撃もある
• 関連ワード（自分用のメモ、思い出せる範囲で）
  • SOP、CORS、JSONP、CSP、CORB、CORP、COOP、COEP、TOFU、

• GitHub にコードが公開されている
• 仮想的な環境で攻撃の再現を確かめることができる
• 説明が論理的で丁寧、すごく頭のいい人な気がする

• 前提知識がない（自分）にとっては難しすぎる
  • そのため、早々に概要の把握に切り替えた
  • 必要になり次第、また思い出し次第、少し詳しくなったら再度取り組む

• どういう通信が危ないか
• どういう処理をしないと危険なコードが実行されるか
• などは通常のソフトウェア開発で大事なので意識する

機会があれば読んでみてください。僕は読み返します。

• Web ブラウザセキュリティ Web アプリケーションの安全性を支える仕組みを整理する
• LambdaNote/support-browsersecurity: 『Web ブラウザセキュリティ ― Web アプリケーションの安全性を支える仕組みを整理する』サンプルコード