ninjinkun's diary

ninjinkunの日記

mozaic bootcampに参加して気づいた、自分に欠けていたWeb技術の知識メモ

mozaic bootcampとは？

mozaic.fmリスナー向けの勉強会。mozaic.fmはJxck氏が主催するPodcastで、Web標準やブラウザ、プロトコルなどWeb技術をターゲットにしており、自分も愛聴している。

今回行われたbootcampはゴールデンウィークの4日間を使い、「Webを正しく理解し、正しく使う」ことを目的として行われた。

参加者はざっくり言うとそこそこ経験のあるWebエンジニアが6名、主催のJxck氏、mozaic.fmでお馴染みの矢倉氏の計8名。参加にあたってはビデオ通話による選考もあった。

会場は自分が所属する一休のリフレッシュスペースを利用した。

当日どんな感じだったかは、以下のエントリで紹介されている。

主催のJxck氏のエントリ

参加者のisyumi_net氏のエントリ

自分に欠けていたWeb技術の知識

自分はWebに関わるエンジニアとして一応10年間働いてきたが、このbootcampに参加して自分がWebの基本的なことを全然理解していなかったことに気づいて愕然とした。なんとなく知っているつもりでも、人に説明できるほど理解していないことが多かった。

しかし今回のbootcamp参加で自分の穴に気づくことができ、ある程度知識を埋めることができたので、特に自分が理解してなかったトピックについて当日のメモを書き出し、まとめてみようと思う。あくまで自分のメモで、何か新しい発見があるわけではないことはお断りしておく。

  1. Cookie
  2. Cross Origin Resource Sharing (CORS)
  3. TLS

1. Cookie

  • サーバがSet-Cookieヘッダを付与すると、ブラウザは次回のアクセス時もその値を返す
    • クレデンシャルとして広く使われている
  • 有効期限について、Expire はローカルで時計を弄られる可能性があるので、今は Max-Ageを使う
  • Max-Ageがないと自動的にSession Cookieになる
    • SessionはUA依存だが、だいたいはブラウザのタブを閉じるまで
  • Max-Ageが設定されていても、Cookieはブラウザの都合で消されたりするので、必ず保存される保証はない
  • 最近はMax-Ageを長めにする傾向にある
  • Domain属性はあまり使わない方が良い

  • Pathはだいたい/だけ指定する
    • Pathを指定しないと、そのcookieを発行したpath以下でしか値が読み出せない
      • 例えば/loginで付与すると /login/hogehogeなどでしか読み出せず、/では読めなくなってしまう
  • Secure, HttpOnly は設定しておくこと
    • Secure HTTPSでのみ送信
    • HttpOnly JSから弄れなくなる
  • Clear-Site-Data ｀Clear-site-Data: "*"｀ とか指定するとログアウト時に全部消してくれる
    • Edge, Safariはまだ未対応
    • 今までは明示的に消す仕組みがなかった
  • クレデンシャルとして使われているのに、セキュアに使うのが難しいデザインになってしまっているのがCookieの問題点
  • SameSite属性
    • CookieはSame Origin Policyの範疇外の困った子なので、これをまともにする
    • 既存の挙動を変えるとサイトが壊れるので、新しいattributeで対応する
    • SameSite: Strict;
    • SameSite: Lax;
      • トップレベルナビゲーションとサイト内だけでcookieが送られる
      • 使いやすい
    • CookieをRead cookieとWrite cookieに分けるのが望ましい
      • そしてWrite cookieにStrictを付けるのが一番いい
  • Secが付いているヘッダーはJSから付与できない
  • 話はこの後Intelligent Tracking Prevention (ITP) に展開したが、割愛

2. Cross Origin Resource Sharing (CORS)

  • xhrで他サイトにリクエスト送信が可能になったが、他サイトにリクエストする際にCookieやヘッダも一緒に送られてしまう
    • 他サイトの情報を無制限に読み取り可能
  • xhrでリクエスト可能な範囲をOriginという概念で制限する
    • scheme、host、portが一致しないと別originとして扱われ、リクエストが制限される
  • Access-Contol-Allow-Origin
    • 指定したOriginからのリクエストを許可する
    • 同一組織内の別サービスからの読み出しなどで使う
    • POST/PUT/DELETEなど副作用があるメソッドを投げる場合は、OPTIONSでpreflightリクエストを投げる
  • Formは遷移するので他のサイトにCORSもできる。originヘッダでどこから来たかわかる
    • Formが自分のサイトから来たものかを検証しないとCSRFになる

3. TLS

このトピックは最終日に時間が余っていたので、自分がリクエストした。いきなりJxck氏がXORについて話し始めて面食らったが、どんどん話が展開し、「この人TLSの仕様が頭に入ってるんだ…」とみんな唖然としていた。後から聞いたら自分で実装したことがあるとのこと。

  • XORは2回かけると元に戻る性質がある
    • A ^BB=A`
    • 共通鍵暗号の基本はこれ
    • 暗号化、復号化コストが低い
    • このBを共通鍵としてクライアントとサーバー間で共有して暗号化された通信をするのがTLSのざっくりした説明
  • TLS 1.2のハンドシェイク
    • 公開鍵暗号を使って共通鍵暗号の鍵を交換する
    • ClientHello
      • クライアントから必要な情報を渡す
      • 対応している暗号化方式を送信
    • ServerHello
      • 暗号化方式を決定して送信
    • ServerCertificate
    • ServerKeyExchange
      • サーバーの公開鍵を送信
    • CertificateRequest, ClientCertificate, CertificateVerify
      • クライアント証明書関係、略
    • ClientKeyExchange
      • サーバーの公開鍵でクライアントが生成した共通鍵を暗号化して送信
    • ChangeCipherSpec
      • ここから共通鍵を使った暗号化通信に移行する
  • なぜ認証局が必要か？
    • サーバーが送信してくる公開鍵がサーバーの運営者のものであることを保証するため
      • 中間者攻撃により通信経路が乗っ取られて、偽の公開鍵が送られていても署名で検証できる
      • 所謂オレオレ証明書をクライアントが許可して運用していると、中間者攻撃で証明書をすり替えられても本物かどうかを検証できなくなる
  • 認証局はさらに上位のルート認証局に認証されており、ルート認証局のルート証明書はOSやブラウザにインストールされている
    • これにより、ルートを辿っていって最後はローカルにインストールされている証明書で検証することで、CAの正当性を保証できる

終わりに、お気持ちの表明

bootcampではもっと膨大なトピックが扱われていたが、特に自分に欠けていたと感じたものを抜粋して書き出した。

自分は、bootcampのテーマである「Webを正しく理解し、正しく使う」とは、技術の様々な文脈や経緯を知った上でベストプラクティスを選択できることであり、その選択理由を明確に説明できることだと解釈した。

だが、bootcampを通して、Webを正しく使うことは本当に難しいし、Web開発者の全員にこれを求めるのは無理だろうと感じた。昨今ではフレームワークやPaaSがベストプラクティスを実装して、我々利用者は難しいことを意識しなくても、ある程度のセキュリティやアクセシビリティを担保しながら開発できるようになってきているという現状もある。

しかしそれでも、ある程度人数が居る開発組織ならば、少なくとも一人はWebを正しく使えるエキスパートが居るべきだと思う。自分が知っている「技術力がある」と見なされている会社には、そういったエキスパートが数人、もしくはもっと多く在籍している。

今回こういった機会を得たことで、一介のWebアプリケーション屋である自分も、「Webを正しく使えるWebアプリケーション屋」と名のれるようになりたいと強く思った。

Jxckさん、矢倉さん、参加者の皆さんありがとうございました。今後もmozaic.fm聞き続けます。

mozaic.fm