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
110
GraphQLの関連タイプを辿る脆弱性
GraphQLのedgeを辿ることで見えてはいけない情報が見えてしまう事象の説明資料
ham
October 04, 2021
Tweet
Share
More Decks by ham
See All by ham
開発者体験を定量的に把握する手法と活用事例
ham0215
0
130
チームトポロジーの4つのチームタイプ
ham0215
1
18
生成AI活用でエンジニア組織はどう変わったのか?
ham0215
2
79
メンバーがオーナーシップを発揮しやすいチームづくり
ham0215
2
440
Platform Engineeringのエッセンスを小規模な開発組織に取り入れた事例紹介
ham0215
9
1.7k
開発者の定量・定性データを組み合わせて開発者体験を把握するための取り組み
ham0215
5
2.2k
アジャイルを始めるための基礎を固める
ham0215
1
100
開発者体験を意識した開発チームの生産性向上の取り組み
ham0215
3
960
MySQLのViewを活用した安全なマルチテナントの実現方法
ham0215
2
1.2k
Other Decks in Technology
See All in Technology
DeepSeekとは?何がいいの? - Databricksと学ぶDeepSeek! 〜これからのLLMに備えよ!〜
taka_aki
1
180
大規模アジャイルフレームワークから学ぶエンジニアマネジメントの本質
staka121
PRO
3
1.6k
AIエージェント入門
minorun365
PRO
33
19k
AI自体のOps 〜LLMアプリの運用、AWSサービスとOSSの使い分け〜
minorun365
PRO
9
930
Ruby on Railsで持続可能な開発を行うために取り組んでいること
am1157154
3
160
LINEギフトにおけるバックエンド開発
lycorptech_jp
PRO
0
420
サバイバルモード下でのエンジニアリングマネジメント
konifar
21
6.9k
AIエージェント元年@日本生成AIユーザ会
shukob
1
260
マルチアカウント環境における組織ポリシーについて まとめてみる
nrinetcom
PRO
2
100
開発者のための FinOps/FinOps for Engineers
oracle4engineer
PRO
2
250
2025/3/1 公共交通オープンデータデイ2025
morohoshi
0
110
LINE NEWSにおけるバックエンド開発
lycorptech_jp
PRO
0
360
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Being A Developer After 40
akosma
89
590k
GraphQLとの向き合い方2022年版
quramy
44
14k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
13
1k
Code Reviewing Like a Champion
maltzj
521
39k
Visualization
eitanlees
146
15k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Documentation Writing (for coders)
carmenintech
68
4.6k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
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主 体のクエリーを実行する。