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
88
GraphQLの関連タイプを辿る脆弱性
GraphQLのedgeを辿ることで見えてはいけない情報が見えてしまう事象の説明資料
ham
October 04, 2021
Tweet
Share
More Decks by ham
See All by ham
開発パフォーマンスを最大化するための開発体制
ham0215
7
1.4k
今こそ思い出すGraphQLの特徴
ham0215
0
83
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
330
CIは5分以内!素早い開発サイクルを支えるCI
ham0215
0
2.9k
現場主導で取り組む継続的な技術的負債の解消
ham0215
4
4.2k
可視化からはじめる開発生産性向上への道のり
ham0215
0
350
GraphQL データ取得高速化
ham0215
0
290
キーボードのすゝめ.pdf
ham0215
0
120
イージーからシンプルへ 〜プロダクトの成長に合わせたアーキテクチャの変更〜
ham0215
0
3.5k
Other Decks in Technology
See All in Technology
JVM言語でもできる、競技プログラミング
dhirabayashi
0
120
生成AI向け機械学習クラスタ 構築のレシピ 北海道石狩編
pfn
PRO
3
560
オブザーバビリティ勉強会で模擬障害対応をやってみた
leveragestech
1
360
OpenFeatureと自動生成を活用したフィーチャーフラグの宣言的集約管理
biwashi
10
1k
Goでテストをしやすくするためにやったこと
kazukihayase
1
530
Extending kotlin-inject for fun & profit
vrallev
2
200
週刊AWSキャッチアップ 生成AI編(2024/5/27週)
minorun365
PRO
4
150
株式会社EventHub・エンジニア採用資料
eventhub
0
2.3k
AWS Storage Gatewayで始めるセキュアなデータ連携 / Secure data linkage with AWS Storage Gateway
yuj1osm
2
180
Cleanup handling in Go / Go Conference 2024
k1low
6
2.1k
情報の世界 2024年度 第10回「データとセンシングの概要」 #情報の世界 / Data and Sensing 2024
yumulab
0
160
大規模 SaaS の技術的意思決定を支える三要素 / Three elements that support technical decision-making for large-scale SaaS
_atsushisakai
0
110
Featured
See All Featured
KATA
mclloyd
18
12k
For a Future-Friendly Web
brad_frost
172
9.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
247
20k
Building Effective Engineering Teams - LeadDev
addyosmani
40
2k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
24
1.7k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
140
43k
[RailsConf 2023] Rails as a piece of cake
palkan
31
4.2k
Rebuilding a faster, lazier Slack
samanthasiow
75
8.3k
Atom: Resistance is Futile
akmur
260
25k
Done Done
chrislema
178
15k
How GitHub Uses GitHub to Build GitHub
holman
471
290k
Docker and Python
trallard
36
2.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主 体のクエリーを実行する。