Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
クロスオリジンの話 / Cross-Origin-202201
Search
unarist
January 28, 2022
Programming
0
180
クロスオリジンの話 / Cross-Origin-202201
どこかでゆるゆる話したやつです。CORSとか同一オリジンポリシーとかその辺。
unarist
January 28, 2022
Tweet
Share
More Decks by unarist
See All by unarist
MODいろいろ / tokaidolug-nagoya-201812
unarist
0
79
Mastodonの話 / osc18-kyoto-closing
unarist
2
740
自分自身を再インストール / osc18-nagoya-tokaidolug
unarist
1
210
UserScriptを直した話 / tokaidolug-nagoya-201803
unarist
0
180
Other Decks in Programming
See All in Programming
RailsでCQRS/ESをやってみたきづき
suzukimar
2
1.4k
20250326_生成AIによる_レビュー承認システムの実現.pdf
takahiromatsui
2
210
Kubernetesで実現できるPlatform Engineering の現在地
nwiizo
2
1k
WordPress Playground for Developers
iambherulal
0
110
Gunma.web #55
tinykitten
0
120
CTFのWebにおける⾼難易度問題について
hamayanhamayan
1
870
Go1.24で testing.B.Loopが爆誕
kuro_kurorrr
0
130
SLI/SLOの設定を進めるその前に アラート品質の改善に取り組んだ話
tanden
2
420
もう一人で悩まない! 個の知見をチームの知見にする3つの習慣と工夫 / Into team knowledge.
honyanya
3
500
爆速スッキリ! Rspack 移行の成果と道のり - Muddy Web #11
dora1998
0
130
もっと大きなデータを送りませんか? エラーがゴロゴロ出るようなデータです
sublimer
0
180
PHPによる"非"構造化プログラミング入門 -本当に熱いスパゲティコードを求めて- #phperkaigi
o0h
PRO
0
740
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.6k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
28
2k
How GitHub (no longer) Works
holman
314
140k
Side Projects
sachag
452
42k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
Producing Creativity
orderedlist
PRO
344
40k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
8
690
Rails Girls Zürich Keynote
gr2m
94
13k
Become a Pro
speakerdeck
PRO
26
5.2k
Why Our Code Smells
bkeepers
PRO
336
57k
Transcript
クロスオリジンの話 unarist
微妙にふわっとしたタイトルやな…
今日話すこと • オリジンとかクロスオリジンとかなんやねん • 同一オリジンポリシーやCORSの話 • 発展的トピック 以下には重点を置いていません。 • Webアプリの脆弱性の網羅的な説明
→ 徳丸本を読みましょう • 最近流行りの攻撃 → OWASPとか徳丸チャンネルを見ましょう
今日覚えて帰ってほしいこと • ありません!!! • バスツアーぐらいの感じでお楽しみください。
Q. 以下の言葉知ってますか? • オリジン • クロスオリジン • 同一オリジンポリシー / Same-Origin
Policy • CORS / Cross-Origin Resource Sharing
None
Origin = scheme + hostname + port の組 例: http://example.com:8080/~username/index.html
リクエスト元・先のOriginが等しい → Same-Origin / 同一オリジン
リクエスト元・先のOriginが等しい → Same-Origin / 同一オリジン さまざまな操作を同一オリジン間に制限する仕組み → Same-Origin Policy /
同一オリジンポリシー
リクエスト元・先のOriginが異なる → Cross-Origin / クロスオリジン
リクエスト元・先のOriginが異なる → Cross-Origin / クロスオリジン 同一オリジンポリシーの制限を緩和する仕組み → CORS (Cross-Origin Resouce
Sharing), etc.
同一オリジンポリシーとCORS • Webの世界は昔からオリジン境界で色々守ってきた • オリジンを越えて許されていたことの例: ◦ リンクなどによるページ遷移 ◦ フォーム送信 ◦
リソース埋め込み(img/script/video/etc.) ▪ よくできているので、埋め込まれたimgをcanvasに描画してそれを持ち出す、とかもで きない(taint=汚染)される
Web園児猫「もうちょっと色々したいんじゃ…!」
同一オリジンポリシーとCORS • (多分)JS芸とかが広がってきて、ブラウザ内でインタラクティブにやるの が流行ってきた ◦ (Ajaxとか)(GoogleMapとか話題になったよね) • 同一オリジンはXMLHttpRequestさえあれば簡単 • クロスオリジンは……は……
◦ 古のハック、JSONP…… ◦ scriptタグで埋め込んでJSONを受け取れる。 var script = document.createElement(“script”); script.src = “http://example.com/api/jsonp?callback=hoge document.body.appendChild(script); function hoge(resp) { console.log(resp); }
CORS「待たせたな!!」
CORS (Cross-Origin Request Sharing) • これまで同一オリジンポリシーで制限されていたリクエストを、サーバー側 の明示的な許可のもと制限を緩和する仕組み • サーバー側の明示的な許可 =
Access-Control-ほげほげ HTTP/1.1 200 OK Content-Length: 0 Connection: keep-alive Access-Control-Allow-Origin: https://foo.bar.org Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE Access-Control-Allow-Credentials: true Access-Control-Expose-Headers: X-Foo, X-Bar Access-Control-Max-Age: 86400
CORS (Cross-Origin Request Sharing) 肝心なのは「同一オリジンポリシーを緩和するもの」ということ。 いままでできたことは変わらずできる ◦ リンクでの遷移、フォーム送信、リソース埋め込み: できる ◦
これらと同等のリクエスト: できる (単純リクエスト) できなかったことは許可されればできる ◦ 単純リクエストのレスポンスをJSで読み取る: 読み取り前にCORSでの許可が必要 ▪ リクエストはできるが、レスポンスにCORSヘッダがないと読み取れない ◦ メソッドやヘッダーを自由に設定したリクエスト: リクエスト前にCORSでの許可が必要 ▪ リクエスト前にプリフライトリクエストが飛ぶ
プリフライトリクエスト 許可がないとリクエストしていいかもわからない時に、先にお伺いを立てる。 OPTIONS /doc HTTP/1.1 Host: bar.other Connection: keep-alive Origin:
https://foo.example Access-Control-Request-Method: POST Access-Control-Request-Headers: X-PINGOTHER, Content-Type HTTP/1.1 204 No Content Access-Control-Allow-Origin: https://foo.example Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: X-PINGOTHER, Content-Type Access-Control-Max-Age: 86400 Vary: Accept-Encoding, Origin 👦こういうリクエスト投げたいっす! 👨この条件ならええやで。
ところで Failed to fetch という 言葉に聞き覚えは?
忌しき Failed to fetch
忌しき Failed to fetch CORSで許可されていない場合、リクエスト結果はJSに対して開示できない ◦ 成功時のレスポンス、失敗時のレスポンス、リクエストに失敗した理由、etc. ◦ 全てをオブラートに包んだエラー「Failed to
fetch」 ◦ 開発者ツールでコンソールを確認するとかしないと、なんもわからん CORS設定しているはずなのに出るんだけど……🤔 ◦ 例えばエラーレスポンスにCORSヘッダがないと、やっぱり Failed to fetch 行き ◦ 忘れがちなケースとして、リバースプロキシやWAFが弾いているとか……
CORSとの付き合い方
レスポンスヘッダーにあれこれ詰める ◦ 最低限必要なのは Access-Control-Allow-Origin ◦ シンプルリクエストに該当しないメソッドやリクエストヘッダーを使う場合、 プリフライト リクエストに対応しつつ、Access-Control-Allow-Methods や Access-Control-Allow-Headers
も返す ◦ CookieやBASIC認証とかも送ってほしい場合は Access-Control-Allow-Credentials ▪ この場合 Access-Control-Allow-Origin 等でワイルドカードは使えない ◦ 追加でレスポンスヘッダを公開したい時は Access-Control-Expose-Headers リクエスト側はそんなにオプションいらない ◦ fetch() でいうと { mode: “cors” } というオプションがあるが、これがデフォルト ◦ 資格情報を送る場合は { credentials: “include” } 等が必要 CORSの設定
同一オリジンポリシーで防げないものは防げない 単純リクエストで副作用が起きるケース ◦ 「ぼくははまちちゃん! こんにちはこんにちは!!」 ◦ 📰https://www.itmedia.co.jp/enterprise/articles/0504/23/news005.html ◦ いわゆる CSRF/XSRF
(Cross-Site Request Forgeries) ▪ fetchでも { mode: "no-cors", credentials: "include" } とかでやれるぞ ◦ 対策: CSRFトークンをつける、単純リクエストにしない、後述の SameSite 属性、etc. ◦ もちろん、GETリクエストで副作用を起こしたりしてないですよね? 埋めこまれるのも困るケース ◦ 現実的な具体例が浮かばないが…… ◦ 対策としては Cross-Origin-Resource-Policy ヘッダとか……?
CORSで解決
なにこれ
ネットワーク通信以外のクロスオリジン ブラウザのタブ間・ウィンドウ間で通信できるもの ◦ postMessage API ▪ 送り手・受け手どちらもoriginをチェックしような! ◦ window.open /
window.parent / iframe.contentWindow / etc. ▪ windowオブジェクトが触れたり触れなかったりする ストレージ系 ◦ Cookie: サイト単位の管理 ▪ サブドメインがまとめられたり、オリジンとはまた違う単位… ◦ IndexedDB / WebStorage / etc.: オリジン単位の管理 ▪ 📰最近別オリジンのIndexedDBがチラ見えするバグがWebKitで話題でしたね? ▪ GoogleのユーザーIDとかが見えるので、特にプライバシー観点でまずい
ネットワーク通信以外のクロスオリジン この辺は既に緩めだったので、制限を厳しくするオプションが生えがち ◦ Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy / iframe sandbox ◦
Spectre👻騒動で一部APIにこれらが必須になったりした 場合によってはデフォルト・強制で制限を厳しくされたりもしている ◦ Cookie: SameSite属性, 3rd-party Cookie の制限, ITP ◦ 📰SameSite=Lax はChromeやFirefoxがデフォルトにして話題になっている ▪ SameSite=None をつけないとCORSが設定されていてもCookieが送られなくなる ◦ Cookieに関してはプライバシー観点の話題が絶えないのもある
おまけ: CSP (Content-Security-Policy) クロスオリジンに限らず、Webページで扱うリソースに制限をかける仕組み ◦ 主に XSS (Cross-Site Scripting) の被害を低減したり報告するのに使われる
◦ img / script / style / (i)frame など、様々なリソースの出所を制限することができる ◦ つまり、XSS で変なリソースを読み込まされそうになっても、ブロックできる! ◦ ベタ書きされた style や script もブロックできる! ◦ (ブラウザにもよるが、UserScript / UserStyle もブロックされたりする) # 現在のオリジンからの取得とインライン指定のみ許可。他所やevalは禁止。 Content-Security-Policy: default-src self ‘unsafe-inline’ # https スキームのみを許可 Content-Security-Policy: default-src https:
おしまい