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
GraphQLの関連タイプを辿る脆弱性
Search
ham
October 04, 2021
Technology
0
83
GraphQLの関連タイプを辿る脆弱性
GraphQLのedgeを辿ることで見えてはいけない情報が見えてしまう事象の説明資料
ham
October 04, 2021
Tweet
Share
More Decks by ham
See All by ham
開発パフォーマンスを最大化するための開発体制
ham0215
7
1.3k
今こそ思い出すGraphQLの特徴
ham0215
0
70
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
280
CIは5分以内!素早い開発サイクルを支えるCI
ham0215
0
2.7k
現場主導で取り組む継続的な技術的負債の解消
ham0215
4
4.1k
可視化からはじめる開発生産性向上への道のり
ham0215
0
330
GraphQL データ取得高速化
ham0215
0
270
キーボードのすゝめ.pdf
ham0215
0
110
イージーからシンプルへ 〜プロダクトの成長に合わせたアーキテクチャの変更〜
ham0215
0
3.4k
Other Decks in Technology
See All in Technology
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
38k
Observabilityジャーニーを実現するためのAWSサービス:CloudWatch編
o11yfes2023
0
140
開発スピードの維持向上を支える、テスト設計の 漸進的進化への取り組み / Continuous Test Design Development for Speed of Product Development
ropqa
0
180
多言語化対応における TypeScript の型定義を通して開発のしやすさについて考えた / TSKaigi TypeScript Multilingualization
nabeliwo
2
380
#phpconkagawa レガシーコードにもオブザーバビリティを 〜少しずつ始めるサービス監視〜
yamato_sorariku
0
540
本当のガバクラ基礎
toru_kubota
0
310
TypescriptでのContextualな構造化ロギングと社内全体への導入
leveragestech
3
570
データ分析力を高めるSQL研修サービス『SQL Everyone』
hikarut
1
380
試作とデモンストレーション / Prototyping and Demonstrations
ks91
PRO
0
160
本番環境で Cloudflareを 使ってみた話
miu_crescent
2
120
サービス開発におけるVue3とTypeScriptの親和性について
tsukuha
10
1.8k
使われないものを作るな!出口から作るデータ分析基盤 / Data Platform Development Starting from the User Needs
amaotone
16
4.5k
Featured
See All Featured
What the flash - Photography Introduction
edds
64
11k
In The Pink: A Labor of Love
frogandcode
138
21k
Building Better People: How to give real-time feedback that sticks.
wjessup
356
18k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Code Reviewing Like a Champion
maltzj
515
39k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
41
4.5k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
GraphQLの誤解/rethinking-graphql
sonatard
56
9.3k
The Illustrated Children's Guide to Kubernetes
chrisshort
32
47k
Visualization
eitanlees
137
14k
Reflections from 52 weeks, 52 projects
jeffersonlam
345
19k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
21
1.6k
Transcript
GraphQLのedgeを辿ることで 見えてはいけない情報が 見える脆弱性 2021/10/4 LT ham
前提条件 下記のようなUserとTeamというTypeがあるとします。 Userは複数のチームに所属しており、Teamには複数のユーザーが所属しているとします。 type User { id: ID! name: String!
teams(afterなど): TeamConnection } type Team { id: ID! name: String! users(afterなど): UserConnection }
前提条件 Teamを取得するQueryを定義します。 type Query { team(teamId: ID!): Team! } このクエリーはアクセス制御されており、teamIdで指定したチームを閲覧許可された利用者のみが閲覧できるように制御
しています。
クエリー実行 例えば下記のクエリーでTeamと所属Userを取得することができます。 利用者がteamIdで指定したチームの閲覧権限がなければ取得できないのでアクセス制御も良さそうに見えます。 query Team($teamId: ID!) { team(teamId, $teamId) {
id name users { edges { node { id name } } } } }
次のクエリーではどうでしょうか? query Team($teamId: ID!) { team(teamId, $teamId) { users {
edges { node { teams { edges { node { name users {...略} } } } } } } } } teamIdには閲覧できるチームを指定 →アクセスOK 指定したチームに他チームに所属しているユーザーが含まれている場合、 そのユーザー経由で別チームの情報まで取得することができる。 →トップ階層のアクセス制御だけでなく、関連 Typeのアクセス制御も考慮が 必要
今後の方針(まだ迷っている...) • DBカラム≒typeのように汎用的にtypeを作った場合、この脆弱性を埋め込 んでしまう可能性が高い。 • クエリーごとにtypeを分ければ発生しないが似たtypeが乱立してしまう。 • Typeを何階層もまとめて取得したいケースはあまりないのではないか?とい う仮説のもと、次ページの方針でしばらく様子を見る。
今後の方針(まだ迷っている...) • 親子関係の場合、親から子を参照するfieldのみ許可する。 • 親子関係以外の場合、fieldに指定するtypeはスカラー型だけのtypeとす る。さらに先のtypeを取得したい場合は別途クエリーを実行する。 type Team { id:
ID! name: String! users(afterなど): UserConnection } UserConnectionには別typeのfieldは定義しない。 もしUserに紐づくtypeを取得したい場合は、別途 User主 体のクエリーを実行する。