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
92
GraphQLの関連タイプを辿る脆弱性
GraphQLのedgeを辿ることで見えてはいけない情報が見えてしまう事象の説明資料
ham
October 04, 2021
Tweet
Share
More Decks by ham
See All by ham
MySQLのViewを活用した安全なマルチテナントの実現方法
ham0215
2
170
開発パフォーマンスを最大化するための開発体制
ham0215
7
1.4k
今こそ思い出すGraphQLの特徴
ham0215
0
110
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
380
CIは5分以内!素早い開発サイクルを支えるCI
ham0215
0
3.1k
現場主導で取り組む継続的な技術的負債の解消
ham0215
4
4.3k
可視化からはじめる開発生産性向上への道のり
ham0215
0
370
GraphQL データ取得高速化
ham0215
0
310
キーボードのすゝめ.pdf
ham0215
0
130
Other Decks in Technology
See All in Technology
初中級者用如何使用backlog -VALE TUDOEDITION-
in0u
0
140
開発と事業を繋ぐ!SREのオブザーバビリティ戦略 ~ Developers Summit 2024 Summer ~
leveragestech
0
620
データベース研修 分析向けSQL入門【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
110
ギークの理想が7つ集まるエムスリーで夢を叶えよう - エムスリー株式会社
m3_engineering
1
260
What if...? 처음부터 다시 LLM 어플리케이션을 개발한다면
huffon
0
1k
クラウド利用者の「責任」をどう果たす?AWSセキュリティ対策のススメ #AWSSummit
hiashisan
0
270
[I/O Extended Android 2024] What`s new in Android 2024
kyeongwan
0
220
AWSでRAGを作る法方
sonoda_mj
1
140
公共領域から学ぶ クラウド移行についてエンジニアが意識していること
kawakawa2222
0
140
AIアシスタントの活用で品質の向上と開発ワークフローのスピードアップ
nagix
1
190
Luupの開発組織におけるインシデントマネジメントの変遷 ver.RoadtoSRENEXT2024
grimoh
1
270
JBUG岡山 #6 WordCamp男木島の チームビルディング
takeshifurusato
0
150
Featured
See All Featured
Leading Effective Engineering Teams 2024
addyosmani
3
300
GitHub's CSS Performance
jonrohan
1026
450k
Scaling GitHub
holman
458
140k
Building Your Own Lightsaber
phodgson
101
5.9k
Learning to Love Humans: Emotional Interface Design
aarron
269
39k
Art, The Web, and Tiny UX
lynnandtonic
291
20k
5 minutes of I Can Smell Your CMS
philhawksworth
200
19k
Practical Orchestrator
shlominoach
185
10k
Music & Morning Musume
bryan
43
5.9k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.9k
Done Done
chrislema
179
15k
Web development in the modern age
philhawksworth
203
10k
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主 体のクエリーを実行する。