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
CORSをちゃんと理解する atmaバックエンド勉強会#4
Search
Yamaguchi Takahiro
July 07, 2021
Technology
0
340
CORSをちゃんと理解する atmaバックエンド勉強会#4
atmaバックエンド勉強会#4の資料です。
Yamaguchi Takahiro
July 07, 2021
Tweet
Share
More Decks by Yamaguchi Takahiro
See All by Yamaguchi Takahiro
コンペを気楽に開催しよーぜ!@関西Kaggler会
nyk510
0
980
Django のセキュリティリリースを見る
nyk510
0
32
3分でMLアプリを作る 〜推論コードにちょっとのStreamlitを添えて〜
nyk510
1
990
硬派で真面目なグラフを描く
nyk510
0
440
pythonで気軽にパッケージを作るのは良いという話。
nyk510
14
9.4k
RestAPIのページネーション atma バックエンド勉強会 #3
nyk510
1
790
AWS CPU Credit を完全に理解する
nyk510
0
400
atmaCup#8 Opening
nyk510
0
200
オンサイトデータコンペの魅力: 関わる全員が楽しいコンペ設計のための取り組み
nyk510
3
5.2k
Other Decks in Technology
See All in Technology
Java x Spring Boot Warm up
kazu_kichi_67
2
490
ガチ勢によるPipeCD運用大全〜滑らかなCI/CDを添えて〜 / ai-pipecd-encyclopedia
cyberagentdevelopers
PRO
3
200
30万人が利用するチャットをFirebase Realtime DatabaseからActionCableへ移行する方法
ryosk7
5
330
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
9
120k
大規模データ基盤チームのオンプレTiDB運用への挑戦 / dpu-tidb
cyberagentdevelopers
PRO
1
110
APIテスト自動化の勘所
yokawasa
7
4.1k
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.6k
Nix入門パラダイム編
asa1984
2
200
Figma Dev Modeで進化するデザインとエンジニアリングの協働 / figma-with-engineering
cyberagentdevelopers
PRO
1
430
GitHub Universe: Evaluating RAG apps in GitHub Actions
pamelafox
0
170
CI/CDやテスト自動化の開発プロジェクトへの適用
megascus
3
740
サイロ化した金融システムを、packwerk を利用して無事故でリファクタリングした話
coincheck_recruit
3
3.7k
Featured
See All Featured
Measuring & Analyzing Core Web Vitals
bluesmoon
1
39
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
The Pragmatic Product Professional
lauravandoore
31
6.3k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
790
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Writing Fast Ruby
sferik
626
61k
RailsConf 2023
tenderlove
29
880
A Philosophy of Restraint
colly
203
16k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Faster Mobile Websites
deanohume
304
30k
Docker and Python
trallard
40
3.1k
Transcript
CORSをちゃんと理解する 2021/07/07 #4 atma勉強会 nyk510
質問です。
CORSって知ってますか?
CORS Cross-Origin Resource Sharing オリジン間リソース共有
名前ぐらいは聞いたことある? エラーで見たことはある? よくわかんない?けどなんかヘッダーに設定 したら直るやつ?
ちゃんと理解しましょう!
CORSの定義 追加の HTTP ヘッダーを使用して、あるオリジンで動作しているウェブ アプリケーションに、異なるオリジン にある選択されたリソースへのア クセス権を与えるようブラウザーに指示するための仕組みです。
CORSの定義 追加の HTTP ヘッダーを使用して、あるオリジンで動作しているウェブ アプリケーションに、異なるオリジン にある選択されたリソースへのア クセス権を与えるようブラウザーに指示するための仕組みです。
オリジンて何?
オリジン URLのプロトコルとホスト(ドメイン)、ポートで識別されるもの 全部が一緒だと同じオリジンとなる 例えば https://hoge.com に対して • 同じ: https://hoge.com/foo/bar.html /
https://hoge.com:443 • 違う: http://hoge.com / https://api.hoge.com
CORSの定義 追加の HTTP ヘッダーを使用して、 あるオリジンで動作しているウェブアプリケーション(ex: フロントエンド)に、 異なるオリジン にある選択されたリソース (ex: バックエンド)への
アクセス権を与えるようブラウザーに指示するための仕組みです。
CORSの定義からわかること • 特定のオリジンのアプリから、別のオリジンのデータ(リソース)を 取ってくる権限を定めたものである。 • ブラウザーの仕組みである ◦ 例えば terminal からのアクセスは関係ない
なんでこんなのがあるの? • セキュリティ的観点から同じオリジン以外の情報を取ってこれないようにしてい るから • 取ってこようとしている先のオリジンが許可した時だけデータのやり取り(リソー ス共有)ができるホワイトリスト方式になっている。 以下の説明では • ブラウザで表示されているオリジン:
Alice • 異なるオリジン: Blob として説明します。
ブラウザは、どうやって許可されているかを知るの? • ブラウザは一度普通にBobへとリクエストを送りBobはレスポンスを返す • ブラウザはレスポンス内の Access-Control-Allow-Origin ヘッダーをみる ◦ リクエスト元の Origin
がこの中に入っていれば許可されたとみなす。 ◦ ワイルドカード * 指定も出来る。この場合何でも許可されたとみなす。 ◦ それ以外は許可されていないリクエストとみなす。 • 許可されている時 ◦ レスポンスを展開して js からアクセス可能 • 許可されていない時 ◦ ブラウザが強制的に処理を止めてエラーになる. js からは「何かしらのエ ラーが起こった」しかわからない(これはセキュリティのため)
Bob から見ると… • 自分を呼び出してもオッケーなサイトを Access-Control-Allow-Origin に入れる • するとそれ以外のオリジンでは、ブラウザからBobの情報を参照できない • すくなくともブラウザでアクセスして悪さする外部サイトの脅威を減らせて良い
アクセス許可の方法 • 単純リクエスト • プリフライトリクエスト
単純リクエスト • 相手サーバ Bob に副作用を起こさないようなリクエスト • 先のフローと同様のやり方で許可を判定する • method: GET/HEAD/POST
• content-type: application/x-www-formurlencoded, multipart/form-data, text/plan
プリフライトリクエスト • 単純リクエストでないものが該当 ・ ex:) POSTで json を送りたい フロー •
許可を取るリクエスト (OPTION) を自動的にブラウザが Bob へ送信 ◦ 今からこういうことするのでオッケーですかというお伺い ◦ これがプリフライトリクエスト • Bobは要求に従って何を許可するかを返信 ◦ ex). POSTはOK / application/json はOK • ブラウザは許可内容をみる (Bobは何がOKって言っている?) ◦ やりたいリクエストが許可なら、Bobへ本体のリクエストを送信 ◦ 許可されていなければエラーにする(jsからは失敗内容はわからない)
ブラウザからのリクエストとレスポンス • 何故か method が単数形と複数形あるがこれはお伺い建てるのはひとつだけだから • リクエストだけ origin は origin
なのは謎 要求 リクエストヘッダー レスポンスヘッダー methodに対する許可 Access-Control-Request-Method Access-Control-Allow-Methods ヘッダーに対する許可 Access-Control-Requests-Header Access-Control-Allow-Headers オリジンに対する許可 Origin Access-Control-Allow-Origin
具体例を見ましょう。
例: ぐるぐる フロントエンド: https://guruguru.science バックエンド: https://api.guruguru.science これらは別 Origin なので Access-Control-Allow-Origin
をバックエンド 側に仕込んでいないとフロントをブラウザで開いた時バックエンドの情 報は表示できない。
例: ぐるぐる・単純リクエスト https://api.guruguru.science/competitions/17/ ブラウザからAPIへ送信して いるリクエストヘッダー APIからブラウザへ返信され たレスポンスヘッダー
例: ぐるぐる・単純リクエスト https://api.guruguru.science/competitions/17/ リクエストの method が GET なので 単純リクエストとしてブラウザで処理される。
例: ぐるぐる・単純リクエスト https://api.guruguru.science/competitions/17/ APIが allow-origin に www.guruguru.science を入 れている →
ブラウザで表示OK
例: ぐるぐる・プリフライトつきリクエスト ログインページ: https://api.guruguru.science/auth/login/ POSTでかつusername/passwordを送信するため単純ではない。 おさらい • はじめOPTIONによるプリフライトで確認 • 確認がとれれば本体のPOSTを送信
例: ぐるぐる・OPTIONによるプリフライトで確認 ブラウザはこれから何を送ろうとしているかをOPTION をつかってお伺い (プリフライトリクエスト) この場合だと 「MethodはPOST / ヘッダーには content-type
/ オリ ジンは https://www.guruguru.science ですがよろしい でしょうか」
例: ぐるぐる・OPTIONによるプリフライトで確認 APIはブラウザの各種 requests に対して何を許可 しているかを返す。 API「POSTはOK・ヘッダーも content-type は オッケーで、オリジンもOKだよ!」
例: ぐるぐる・確認がとれれば本体のPOSTを送信 今回の場合別オリジン(API)から許可がもらえたの で本体のPOST処理を送信。 もう許可はもらえているのでこのリクエストに Access-Control-Request 系のヘッダーはない。
まとめ • CORSはオリジンの違うサーバにたいしてブラウザからアクセスするときの制御に 関する仕組みである。 • リクエストの種類によってプロトコルが異なる。
参考資料 • https://developer.mozilla.org/ja/docs/Web/HTTP/CORS • 安全なウェブアプリケーションの作りかた・3.3章