
【書評】Webブラウザセキュリティ、を読んだ
2022-08-28
2022-08-28
はじめに
こんにちは、こふです。

Web ブラウザセキュリティ Web アプリケーションの安全性を支える仕組みを整理するを読みました。
カンタン評価
お忙しい方のためのカンタン評価です。あくまで個人的感想です。
Yes/No で
- もう一度読みたいか
- Yes
- 理解を後回しにした部分が大きいため
- 定価の価値があったか
- Yes
- 誤字脱字・編集ミスを見つけたか
- No
5 点満点の評価で
- 他人にオススメするなら
- ★★★☆☆
- 少なくともハズレ本という人はいないと思う
- 文章の読みやすさ
- ★★★★☆
- 論理的に説明してくれているため比較的スムーズ
- 当然、知識レベルにもよる
- わかりやすさ
- ★★★☆☆
- 前提知識によるため、個人差あり
本を読んだ目的
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
にコードが公開されている- 仮想的な環境で攻撃の再現を確かめることができる
- 説明が論理的で丁寧、すごく頭のいい人な気がする
本の微妙な点
- 前提知識がない(自分)にとっては難しすぎる
- そのため、早々に概要の把握に切り替えた
- 必要になり次第、また思い出し次第、少し詳しくなったら再度取り組む
今後、意識する点
- どういう通信が危ないか
- どういう処理をしないと危険なコードが実行されるか
- などは通常のソフトウェア開発で大事なので意識する
おわりに
機会があれば読んでみてください。僕は読み返します。