ちいさな Web ブラウザを作ってみよう
Part 01: 防御者視点で考える Web ブラウザのセキュリティ
Part 01: 防御者視点で考える Web ブラウザのセキュリティ
演習 01-01
Fetch Standard について考える前に、まずは頭の体操から始めることにします。 いま、以下の HTML からなる この Web ページ を開くと、HTTP リクエストが 1 つ発行されるはずです:
<script> fetch("https://shift-js.info", { mode: "no-cors" });</script>
この HTML ファイルを参考に、開くとできるだけ沢山の方法で https://shift-js.info
に対してリクエストを送るような HTML ファイルを作ってみてください。
演習 01-02
Fetch Standard を読み、セキュリティのために大切そうに見える項目をできる限り列挙してみてください。また、可能な限り、それらの項目がない場合にどのようなリスクが発生しうるかを考えてみてください。
演習 01-03
Web Platform Tests の CORB 関連のテストの一覧は web-platform-tests dashboard の ここ から閲覧できます。
そのうち img-html-correctly-labeled.sub.html
というテストの各ブラウザでの実行結果は ここ から閲覧できます。このページの "Run in your browser on wpt.live" というリンクをクリックすると、実際にそのテストケースを自分の Web ブラウザ上で開いてみることもできます。
- 実際に
img-html-correctly-labeled.sub.html
というテストを自分の Web ブラウザ上で開き、CORB があなたの Web ブラウザ上でどのように動作しているかを確認してみてください。 - (余力があれば)確認できた動作が HTML Standard や Fetch Standard と整合しているかを可能な範囲で確認してみてください。
- ヒント: "update the image data" のステップの中で生成される "request" の "mode" は何でしょうか?
- ヒント: "CORB check" は "main fetch" の中に登場しますが、"CORB check" が行われるのはどのようなときでしょうか?
演習 01-04
web-platform-tests dashboard の Fetch 関連のテスト の項目から、Port Blocking に関する Web Platform Test 関するテスト項目を探してみましょう(ヒント: "bad port")。
演習 01-05
Fetch Standard の "Should response to request be blocked due to its MIME type?" はなぜ必要なのでしょうか?調査して みましょう。
- ヒント: Fetch Standard のマスターは ここ にあります。このファイルの各行の変更履歴を blame などを駆使して調査してみましょう。
- ヒント: Fetch Standard の GitHub リポジトリ にアクセスし、"MIME type block" のようなワードで Issue を検索してみるとどうでしょうか。何かめぼしい Issue や Pull Request は見つかりませんか?