# Webブラウザセキュリティ（ラムダノート社のやつ）

## 理解

- FetchやXHRにより発行されるCross-Originなリクエストには、原則としてCookieが付与されない。付与したい場合は`fetch(url, {credentials:'include'})`や、`xhr.withCredentials = true`が必要
- OPTIONSによるプリフライトが全て条件を満たしている場合はもともと発行したかったリクエストを発行する
- Access-Control-Allow-Origin
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- プリフライトリクエストのレスポンスは Access-Control-Max-Age: ** でブラウザに指定秒数キャッシュできる
- JSONPは `Content-Type: application/javascript` で事前に定義されたコールバック関数を `callback('hoge')`のような形で呼び出すスクリプトをレスポンスとして返す
- Window間のメッセージやり取り時には `e.origin` を参照して信頼できるオリジンからのメッセージであることを自分で検証する必要がある
- `document.domain` を設定し、複数のWebページが同じ値を持つ場合、Cross-OriginなDOMアクセスが許可される
- `Content-Security-Policy: xxxxxxxx; yyyyyyy; zzzzzzz;`
- script-src https: http://example.com 'self'
- script-src 'nonce-randomhogehoge'
- script-src 'sha386-abclasdjflkasjdlkasjdf'
- unsafe-eval; unsafe-inline; unsafe-hashed;
- `<iframe sandbox="allow-hoge">`でiframe内での操作に制限をかけられる
- 別のページに埋め込まれないようにするには、 `X-Frame-Options:SAMEORIGINまたはDENY`が使われていたが、iframeがネストしたときの動作がブラウザによってまちまちなのでCSPの `frame-ancestors 'none'または'self'` を利用するとうまくいく
- Site Isolation
- CORB(Read Blocking)
- CORP(Resource Policy)
- COEP(Embedder Policy)
- COOP(Opener Policy)
- Cookieの属性
- Expires
- Max-Age - ※優先
- Domain - クッキーのスコープをホストからドメインに広げる
- 例えば foo.example.com から example.com に広げる
- Path - クッキーのスコープをパスで限定する
- Secure - Https Only
- HttpOnly - JavaScriptから参照・設定不可
- SameSite - CookieをあるSiteから同じSiteに対してリクエストを投げた場合のみ送信するCSRF対策
- フィンガープリント
- ブラウザから取得できるバージョンやフォントの設定やOSの情報はそれだけではユーザーは識別できないが、それらの組み合わせはユーザーの識別に足りうる
- CNAME Cloaking
- サイト運営者と広告会社が協力すれば、CNAMEを利用することで広告会社の1st party cookieとしてクッキーを送信できる
- CookieはSOPとは別の境界(ホスト・パス・スキーム)を持っている
- たとえばポートがないからポート違いは同じCookieを共有する
- HTTPS
- サーバーは公開鍵（S）を含む署名文書を用意する
- 署名文書には何が書いてある？
- サーバーは署名文書を認証局に送る
- 認証局は署名文書をハッシュ化し、さらに秘密鍵（CA）で暗号化したものを電子署名とする
- 認証局は電子署名をサーバーに送る
- サーバーは署名文書+電子署名を電子証明書とする
- クライアントにはペイロードとこの電子証明書を一緒に送る
- クライアントは署名文書をハッシュ化する - A
- クライアントは電子証明書をブラウザにインストールされた公開鍵（CA）で復号化する - B
- クライアントはAとBが同じなら改ざんされていないと判断し、署名文書に含まれる公開鍵（S）を安心して利用できる
- クライアントは共通鍵(SSL)を公開鍵(S)で暗号化し、サーバーに送る
- サーバーは秘密鍵（S）で復号化し、共通鍵（SSL）を得る
- サーバーとクライアントは共通鍵（SSL）を持つため暗号通信ができる
- Strict-Transport-Security 次からはHTTPSを強制する
- HSTS Preloadというサービスに登録することで初回アクセスもHTTPSにできる
- SRI (Sub Resource Integrity)
- ファイル全体をハッシュ化してBase64化した文字列をintegrity属性に設定すると、実行前に検証される `<script src="******" integrity="sha256-lasdjfawlkejfasdklfj=" />`

Googleが推奨するStrictCSP

Content-Security-Policy:
object-src 'none';
script-src 'nonce-{random}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https:
􏰀→ http:;
base-uri 'none';
report-uri https://your-report-collector.example.com/

## まだわかっていないこと

- SPAでCSRF脆弱性を防ぐには
- SameSite属性だけでいいのでは