セキュリティ · Web 診断

API と GraphQL の診断

REST と GraphQL の API を診断します。認可の欠陥が最も出る層です。

実習

localhost で実習

環境構築

★★★重さ 2 / 3

前提

sec-authz 修了。npm install graphql が使えること

倫理

第0章の法と倫理ゲートへの同意が必須です。

続きから

章の一覧

1. 未完了第0章はじめに — 1つの窓口に、すべてが集まるGraphQLがRESTと違い単一エンドポイントに全機能を集める設計であることを理解し、だからこそ認可チェックがフィールド単位で要ると気づきます。環境の準備とethicsゲートを確認します。約6分次はここ
2. 未完了第1章Introspection — 地図そのものが、漏れる自作GraphQLサーバに__schemaクエリを送り、全フィールド・全ミューテーションが丸見えになる様子を確認します。introspectionがなぜ攻撃の下見に使われるかを理解します。約10分次はここ
3. 未完了第2章BOLA — リゾルバの、所有者チェック漏れnoteフィールドに他人のIDを渡し、所有者チェックなしで非公開メモを読み出します。sec-authzのIDORとの対応を確認し、二アカウント法でGraphQLでも同じ手順が使えると理解します。約9分次はここ
4. 未完了第3章BFLA と mass assignment権限チェックなしのdeleteUserミューテーション(BFLA)と、入力オブジェクトを丸ごとマージするupdateProfile(mass assignment)で、roleフィールドをadminに昇格させます。両方を実際に起こします。約12分次はここ
5. 未完了第4章直す — フィールド単位の認可と、入力の許可リストBOLA・BFLA・mass assignmentの3つを、リゾルバごとの所有者/ロール確認と、入力フィールドの許可リストで直します。同じ攻撃で再検証し、introspectionを無効化する方法にも触れます。約12分次はここ
6. 未完了第5章まとめ — 窓口が1つでも、原則は同じintrospection・BOLA・BFLA・mass assignmentを畳みます。GraphQL特有の見た目の違いの下に、これまでの原則が貫いていたことを確認し、次のビジネスロジックのコースへ進みます。約3分次はここ

詰まったときはお助けページへ。章ごとのファイル一式をダウンロードして、途中から再開できます。