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
120
GraphQLの関連タイプを辿る脆弱性
GraphQLのedgeを辿ることで見えてはいけない情報が見えてしまう事象の説明資料
ham
October 04, 2021
Tweet
Share
More Decks by ham
See All by ham
開発組織における意思決定の実例〜開発優先度・組織構成・ツール導入〜
ham0215
0
59
エンジニアリングで組織のアウトカムを最速で最大化する!
ham0215
1
350
アウトカムを最速で最大化できる開発組織にするために
ham0215
1
88
コード品質向上で得られる効果と実践的取り組み
ham0215
2
300
開発者体験を定量的に把握する手法と活用事例
ham0215
1
240
チームトポロジーの4つのチームタイプ
ham0215
2
40
生成AI活用でエンジニア組織はどう変わったのか?
ham0215
3
150
メンバーがオーナーシップを発揮しやすいチームづくり
ham0215
3
520
Platform Engineeringのエッセンスを小規模な開発組織に取り入れた事例紹介
ham0215
9
1.9k
Other Decks in Technology
See All in Technology
Microsoft Build 2025 技術/製品動向 for Microsoft Startup Tech Community
torumakabe
2
270
Delegating the chores of authenticating users to Keycloak
ahus1
0
120
A2Aのクライアントを自作する
rynsuke
1
170
生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction
nwiizo
4
1.7k
25分で解説する「最小権限の原則」を実現するための AWS「ポリシー」大全 / 20250625-aws-summit-aws-policy
opelab
9
1.1k
BrainPadプログラミングコンテスト記念LT会2025_社内イベント&問題解説
brainpadpr
1
160
BigQuery Remote FunctionでLooker Studioをインタラクティブ化
cuebic9bic
3
300
エンジニア向け技術スタック情報
kauche
1
260
生成AIでwebアプリケーションを作ってみた
tajimon
2
150
Uniadex__公開版_20250617-AIxIoTビジネス共創ラボ_ツナガルチカラ_.pdf
iotcomjpadmin
0
160
Github Copilot エージェントモードで試してみた
ochtum
0
100
より良いプロダクトの開発を目指して - 情報を中心としたプロダクト開発 #phpcon #phpcon2025
bengo4com
1
3.1k
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The World Runs on Bad Software
bkeepers
PRO
69
11k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Raft: Consensus for Rubyists
vanstee
140
7k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
A Tale of Four Properties
chriscoyier
160
23k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Side Projects
sachag
455
42k
Six Lessons from altMBA
skipperchong
28
3.8k
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主 体のクエリーを実行する。