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
60
エンジニアリングで組織のアウトカムを最速で最大化する!
ham0215
1
360
アウトカムを最速で最大化できる開発組織にするために
ham0215
1
93
コード品質向上で得られる効果と実践的取り組み
ham0215
2
300
開発者体験を定量的に把握する手法と活用事例
ham0215
1
250
チームトポロジーの4つのチームタイプ
ham0215
2
45
生成AI活用でエンジニア組織はどう変わったのか?
ham0215
3
160
メンバーがオーナーシップを発揮しやすいチームづくり
ham0215
3
530
Platform Engineeringのエッセンスを小規模な開発組織に取り入れた事例紹介
ham0215
9
1.9k
Other Decks in Technology
See All in Technology
インフラ寄りSREの生存戦略
sansantech
PRO
5
1.7k
ビギナーであり続ける/beginning
ikuodanaka
3
780
PO初心者が考えた ”POらしさ”
nb_rady
0
220
React開発にStorybookとCopilotを導入して、爆速でUIを編集・確認する方法
yu_kod
1
290
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
3
22k
自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ / dev-productivity-con-2025
yoshikiiida
2
17k
20250705 Headlamp: 專注可擴展性的 Kubernetes 用戶界面
pichuang
0
280
高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
kawauso
3
9.6k
いつの間にか入れ替わってる!?新しいAWS Security Hubとは?
cmusudakeisuke
0
140
AI時代の開発生産性を加速させるアーキテクチャ設計
plaidtech
PRO
3
170
関数型プログラミングで 「脳がバグる」を乗り越える
manabeai
2
200
スタートアップに選択肢を 〜生成AIを活用したセカンダリー事業への挑戦〜
nstock
0
250
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
42
2.7k
Thoughts on Productivity
jonyablonski
69
4.7k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Unsuck your backbone
ammeep
671
58k
The Cult of Friendly URLs
andyhume
79
6.5k
Designing Experiences People Love
moore
142
24k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
A better future with KSS
kneath
238
17k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Git: the NoSQL Database
bkeepers
PRO
430
65k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
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主 体のクエリーを実行する。