
2025.02.18
AIが「嘘のデータ」を返してしまう アルペンが生成AI導入で味わった失敗と、その教訓
攻撃者の視点から見たGraphQLのセキュリティ(全1記事)
リンクをコピー
記事をブックマーク
kuzushiki氏:それでは、発表を始めていきたいと思います。
まず簡単に自己紹介をさせてください。私は、kuzushikiと申します。現在、とあるセキュリティベンダーで診断員をやっていて、主にWebアプリケーションの脆弱性診断をしています。最近、バグバウンティに興味を持って、そういうものをちょっとやってみています。
今回は「GraphQL」について話しますが、その前に、もうGraphQLを知っているよという方は、どのぐらいいるでしょうか?
(会場挙手)
ありがとうございます。けっこうな方が知っているということでですね、それではざっくりと説明したいなと思います。
GraphQLは簡単に一言で言うと、Facebook(現「Meta」)が開発したAPIのためのクエリ言語というところで、その特徴は、なんといってもデベロッパーフレンドリーというところで、こういった機能があります。
この画像はGraphQLの構造を示していて、GraphQLの「Graph」という名前から、ノードとエッジといった構造を取っています。
この例は、Shopノードに関連するProductノードを列挙するという操作で、特定のショップで取り扱っている商品を列挙することができます。こんな感じのクエリを送ります。
実際に、GraphQLのやりとりを見ていきましょう。こちらが、GraphQLのクエリとなっていて、users、id、usernameといったフィールドがあります。
usersには、このidという引数を渡していて、これは、idが1となるユーザーのIDとユーザー名を取得するという操作です。(スライドを示して)実際にこのようにレスポンスにもidとusernameが入っています。
これでGraphQLの基本は以上にして、GraphQLには、デベロッパーフレンドリーな機能が本当にたくさんあります。その機能と悪用方法をセットで紹介していきたいなと思います。
まず、Introspectionですね。これはクエリに_schemaというようなフィールドを入れることによって、GraphQLサーバーで、どんなフィールドが有効かを取得できるものです。
実際にこういったクエリを送ると、このようにフィールドとしてpastesやpasteが得られます。
これはGraphQLのクライアントで、ドキュメントを表示するといったことに使えます。非常に便利な機能ではありますが、これは攻撃者にも実行できて、情報収集に使われてしまいます。
仮にフィールドを列挙した際に、systemUpdateのように明らかに管理用の操作がバレると、それを実行されてしまうおそれもあります。
この対策ですが、そもそもAPIの仕様を公開したくない場合は、この機能を無効にしておきましょう。一部、この機能を無効化できないサービスもあるので、そういった場合は、先ほどの特徴的なフィールド名である_schemaを、ブロックするのがよいのかなと思います。
では次にいきます。次は、Aliasですね。先ほどのusersというフィールドを複数実行したい時に、Aliasをつけないと、このように「Fields "users" conflict」というエラーが出てきます。
このエラーを防ぐために、user1、user2というAliasをここでつけています。これをすることでuser1とuser2のユーザー名を、1回のクエリで取得できます。
ではこれをどう悪用するのでしょうか。これは、認証回避やDoSに悪用されるケースがあります。
ここではGraphQLにログインの処理があるのを想定しています。そうすると、Aliasを使うことでパスワードのリスト攻撃みたいなことができてしまう。そのまま、攻撃者はすべてのフィールドに対する応答を取得できるので、(スライドを示して)このsuccessがtrueとなっているところが正しいパスワードであることがわかります。
それ以外にも、何回も実行することによるサービス停止も考えられます。
この対策ですが、1回にクエリに使えるAliasの数に制限を設けましょう。あと、GraphQLにはコストを計算する機能があるので、それで制限を設けましょう。これは、APIの回数制限では防げないので注意が必要です。
次にいきます。次はFragmentですね。クエリ内で繰り返し使う部分を定義して使い回せるという機能で、この例でも、userInfoというFragmentを作っていて、それをスプレッド構文みたいな形式で使っています。これを実行することで、user1とuser2、それぞれのユーザー名とEメールを取得できます。
これをどうやって悪用するのかというと、こんな感じですね。Fragmentの中でFragmentが使えるケースがあります。
この例では、クエリ内でまず、AというFragmentを参照しているのですが、Fragment A内ではFragment Bを参照していて、BではまたAを参照しているので、ここで、無限ループに陥ってしまいます。これをCircular fragmentsと言います。
これは実は、すでに大半のGraphQLサーバーでは対策済みになっています。というのも、GraphQLの仕様でFragmentはサイクルを形成してはいけないと明記されているので、仕様どおりに実装できていればまったく問題ありません。
ただ、やはり一部脆弱な実装は存在していて、RubyのHTTPサーバーである「Agoo」でこの問題が発見されて、報告されています。現在は修正済みです。
続いて、Field Suggestionですね。これは、このようなクエリを送信した時に、エラーメッセージとして「Cannot query field "products" on type "Query". Did you mean "product"?」が出ます。
productsじゃなくてproductじゃないですかと、正しいフィールド名を提案してくれる非常にすばらしい機能なんですが、情報収集に使われてしまうよといったところで(お話しします)。
(スライドを示して)このように、攻撃者はそれっぽいフィールド名を……articles、documents、postsといったものを送信することで、エラーメッセージとして「Cannot query field "posts"」「Did you mean "pastes" or "paste"?」と返ってくるので「あぁ、じゃあ、これ使えるんだな」というのがわかってしまいます。
これは、Blind Introspectionと言うのですが、これを使った「Clairvoyance」というツールがあって、GraphQLサーバー側でIntrospectionが無効になっていても、このBlind Introspectionを使うことで、Introspectionと同様の情報を得ることができます。
この対策ですが、Introspectionをそもそも無効にするのであれば、Field Suggestionも、同様に無効化しておきましょう。
GraphQLのデベロッパーである、Lee Byron氏も「introspectionを無効にしたスキーマは、didYouMeanも無効になることを期待します。introspectionを無効にして、didYouMeanを有効にしたい理由やその逆は思いつかない」とコメントしています。自分もそのとおりだなと思います。
これまでに、たくさん悪用方法を紹介してきました。けっこういろいろな対策が必要だと思われた方もいると思います。ただ、1ついい方法があって、究極の対策と言われている、Persisted Queriesというものがあります。
本来攻撃者は、GraphQLサーバーにそのままそのクエリを送信できるのですが、このPersisted Queriesを使うと、攻撃者はそのクエリに対応するIDを送信することになります。その後GraphQLサーバー側のミドルウェアで、IDに対応するクエリを参照して、それを実行するということになるので、攻撃者が、自由にクエリを作ることができなくなります。
なので、これまでに紹介した攻撃をすべて防げます。これはもともとはネットワークの帯域節約のために考えられた技術なのですが、セキュリティにも有効ということで今回紹介しました。
「おわりに」ということで、GraphQL特有の機能における悪用方法を紹介しました。GraphQLはデベロッパーにとって、とてもフレンドリーなのですが、それは裏を返すと、ハッカーにとってもフレンドリーということです。不要な機能は無効化しておくことを推奨します。
というところで、参考文献を紹介しておきます。『Black Hat GraphQL』という本から今回紹介しました。約7,000円と、少しお高めですが、GraphQLの攻撃手法を体系的に学ぶことができるので、非常におすすめです。自分も学んだ結果、300ドルの賞金をもらうことができたので、実質プラスとなりました。
(会場笑)
その他の学習リソースもここで紹介しておきます。以上で発表を終了します。ありがとうございました。
(会場拍手)
関連タグ:
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
限られた時間で成果を上げるドイツ式仕事術
2025.01.21 - 2025.01.21
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29