Tsumiki

コース目次 / 第5章

まとめ — 窓口が1つでも、原則は同じ

introspection・BOLA・BFLA・mass assignmentを畳みます。GraphQL特有の見た目の違いの下に、これまでの原則が貫いていたことを確認し、次のビジネスロジックのコースへ進みます。

第5章 / 全6章目安 約3分この章のゴール: GraphQL診断の要点を畳み、次のコースへの道筋を持つ

Introspection、BOLA、BFLA、mass assignment。GraphQL という、見た目の違う世界でも、これまで積み上げてきた原則がそのまま通用することを確かめました。

GraphQL診断・早見表

穴 原因 直し
Introspection の開放 __schema が本番でも問い合わせ可能 本番環境では無効化(偵察を難しくする一枚)
BOLA リゾルバが所有者を確認しない 資源を返す直前に所有者チェック(=IDORと同じ)
BFLA リゾルバがロールを確認しない 呼び出し元のロールを確認(=垂直権限昇格と同じ)
mass assignment 入力オブジェクトを丸ごとマージ 更新してよいフィールドだけ許可リストで適用

GraphQL は「1つの窓口に、すべての機能が集まる」という特性ゆえに、認可の抜けが起きやすく、また広がりやすい領域でした。でも直しの中身は、sec-authz・sec-securecoding で身につけた原則——事実はサーバが持つ、許可リストで明示する——のままでした。新しい言葉(BOLA・BFLA)に驚かず、「これは知っている形だ」と気づけることが、初めて見る技術に立ち向かう力です。

次の道 — ビジネスロジックと競合状態

次は「ビジネスロジックと競合状態」です。GraphQL のミューテーションでも、価格の改ざんやTOCTOU(確認と実行の隙間)は、これまでと同じ形で起こりえます。エンドポイントの形が変わっても、疑うべき問いは変わりません。

このコースの実習相手も、すべて自分の 127.0.0.1 の自作サーバでした(法と倫理)。GraphQL は実務でも急速に広がっている技術です。ここで身につけた視点は、そのまま実務の診断に持っていけます。

お疲れさまでした。窓口の形が変わっても、あなたの目はもう惑わされません。

こうなっていればOK

この章で卒業です。

この章はまだ完了していません。