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
71
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
290
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
OpenID Foundation updates
fujie
0
260
Taking Flight with Tailwind CSS
opdavies
0
4.3k
汎用ポリシー言語Rego + OPAと認可・検証事例の紹介 / Introduction Rego & OPA for authorization and validation
mizutani
1
200
5分で分かる(かもしれない) Vector engine for OpenSearch Serverless
tsukuboshi
1
440
Laboratories in Science and Technology: Deep Neural Networks
keio_smilab
PRO
3
180
MIXI の DevRel 活動は採用にどう影響を与えようとしているか? / Effective Developer Relations for hiring at MIXI, Inc.
mixi_engineers
PRO
1
100
テストコードを書きながらCompose Multiplatformを乗りこなす
subroh0508
0
150
ITエンジニアを取り巻く環境とキャリアパス / A career path for Japanese IT engineers
takatama
3
1.2k
Trade-offs all the way down
_aitor
1
120
回り回って効いてくる副次的効果としての技術広報/techpr
nishiuma
2
210
Password cracking: past, present, future
openwall
0
340
TypescriptでのContextualな構造化ロギングと社内全体への導入
leveragestech
3
650
Featured
See All Featured
What's new in Ruby 2.0
geeforr
338
31k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
22
1.6k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
358
22k
StorybookのUI Testing Handbookを読んだ
zakiyama
13
4.7k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
22
1.4k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
501
140k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
84
45k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Fontdeck: Realign not Redesign
paulrobertlloyd
76
4.9k
How GitHub (no longer) Works
holman
305
140k
Web Components: a chance to create the future
zenorocha
306
41k
Music & Morning Musume
bryan
42
5.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主 体のクエリーを実行する。