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
75
GraphQLの関連タイプを辿る脆弱性
GraphQLのedgeを辿ることで見えてはいけない情報が見えてしまう事象の説明資料
ham
October 04, 2021
Tweet
Share
More Decks by ham
See All by ham
CIは5分以内!素早い開発サイクルを支えるCI
ham0215
0
2.3k
現場主導で取り組む継続的な技術的負債の解消
ham0215
4
3.9k
可視化からはじめる開発生産性向上への道のり
ham0215
0
280
GraphQL データ取得高速化
ham0215
0
240
キーボードのすゝめ.pdf
ham0215
0
100
イージーからシンプルへ 〜プロダクトの成長に合わせたアーキテクチャの変更〜
ham0215
0
3.3k
[After RubyKaigi]クリスマスを待たずに Rust版YJITの実力を検証
ham0215
0
170
RDB脳からFirestore脳へ
ham0215
0
140
JWTを保存する場所について
ham0215
0
500
Other Decks in Technology
See All in Technology
検証からプロダクトへ: シームレスなLLM開発の ためのしくみ作り
nunukim
1
210
Introducing Pkl
enomotok
0
190
技術広報として2023年度に頑張ったこと / What we did well in FY2023 as a DevRel
pauli
5
490
エバンジェリスト活動を7年やってきて見えてきた、コミュニティとエバンジェリストの関係
soracom
PRO
1
200
Why do you get AWS certificates
hirosys
0
120
匠MethodとRDRAとICONIXとDDDで実現する一気通貫オブジェクト指向開発
haru860
4
2.1k
中学生でもわかる深層学習
e869120
10
2.4k
オブジェクトのおしゃべり大失敗 メッセージングアンチパターン集 / messaging anti-pattern collection
ytake
0
340
Kubeflow Pipelines v2 で変わる機械学習パイプライン開発
asei
4
340
#51 “Empowering Azure Storage with RDMA”
cafenero_777
3
210
複数の LLM モデルを扱う上で直面した辛みまとめ
kazuyaseki
1
250
GraphQLに入門してみた
chiroruxx
2
130
Featured
See All Featured
Building an army of robots
kneath
300
41k
From Idea to $5000 a Month in 5 Months
shpigford
376
45k
A designer walks into a library…
pauljervisheath
199
23k
Why Our Code Smells
bkeepers
PRO
330
56k
How GitHub (no longer) Works
holman
301
140k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
185
15k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
24
2.2k
Pencils Down: Stop Designing & Start Developing
hursman
115
11k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
14
1.3k
Visualization
eitanlees
135
14k
Debugging Ruby Performance
tmm1
68
11k
What’s in a name? Adding method to the madness
productmarketing
PRO
14
2.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主 体のクエリーを実行する。