Broken Function Level Authorization

‍Broken Function Level Authorizationとは？

概要から、この脆弱性が非常に複雑かつ多様なケースで存在することがお分かりかもしれません。現在、OWASP Top 10のランキングでどこに位置するか確認してください。人は本質的に予測可能で、エンドポイントの配置にも一定のパターンがあります。例えば、特権の高いエンドポイントが同じ相対パス上に配置されると、利用者が推測しやすくなります。しかし、それだけでは脆弱性になりません。低い権限のユーザとしてもエンドポイントにアクセスできる必要があります。このアクセスは、指定されたHTTPメソッド（例：POST）を実行することで生じる場合もあれば、開発者が意図的または非意図的に有効にした他のメソッド（例：DELETE）で生じる場合もあります。さらに、エンドポイントが予測しやすい場合（例：/books?id=0 から /books/all が推測され、アクセスすべきでない書籍が表示される可能性がある）に、問題が深刻化することがあります。

攻撃シナリオの例

最初の例では、フランチャイズ保有者とフランチャイズを悪用しようとする企業という2種類のアカウントが存在する対象を取り上げます。どちらも同じURLでログインしますが、フランチャイズ保有者のアカウントははるかに高価です。しかし、アカウント設定画面で保存を行うと、隠されたパラメータ「Account type」が存在し、「exploitant」から「franchise_holder」に変更できることに気付きます。これにより、低価格のアカウントを取得した後、後から自分で高価格のアカウントに切り替えることが可能となります。

例:

POST /api/saveSettings.php
[
    {
        "Name": "677",
        "...": "AAAAA...AAAA",
        "AccountType":"exploitant"
    }
]

このリクエストボディを以下のように変更します。

POST /api/saveSettings.php

[
    {
        "Name": "677",
        "...": "AAAAA...AAAA",
        "AccountType":"franchise_holder"
    }
]

このリクエストを送信することで、利用者自身がアカウントをより高価なプランへアップグレードできるようになります。

2つ目の例として、利用者がドキュメントを閲覧しようとするケースがありますが、通常は自分のドキュメントのみが表示されます。しかし、自分のドキュメントをエクスポートすると、URL /api/documents/export が返されます。このURLは正しく自分のドキュメントのみを返しますが、単純に推測することで、全ドキュメントを返す /api/documents/export/all というURLが存在することが分かります。

GET /api/documents

上記は以下の応答を返します。

[
    {
        "id": "1",
        "content": "AAAAA...AAAA",
        "creationDate":"10-10-10"
    },
    {
        "id": "4",
        "content": "AAAAA...AAAA",
        "creationDate":"10-10-10"
    }
]

通常、利用者は自分のドキュメントしか閲覧できませんが、エクスポート時にパスを変更することで、全ドキュメントを取得できることに気付くのです。

GET /api/documents/export

は先述の結果と同じ内容を返しますが、以下のリクエストでは：

GET /api/documents/export/all

全てのドキュメントがエクスポートされます。

過剰なデータ露出に対する予防策

認証と認可のモジュールを本体コードから分離し、必要な場所で容易に実装できるようにするのが望ましいです。初期状態では全てのアクセスを拒否することで安全性を高めることができ、不要なトラフィックをブロックする方法もありますが、その代わりに攻撃経路の一部を見逃すリスクが生じます。

また、アプリのロジックや各ユーザレベルを考慮しながら、認可モジュールの定期的かつ徹底したテストと分析を実施する必要があります。

さらに、より安全性を高めるため、前述の認可モジュールを実装したマスター管理者クラスを導入する方法もあります。このモジュールを他の管理機能が継承することで、低権限の利用者による管理機能の実行を防ぐことができます。

最後に、以下の2点を常に念頭に置く必要があります:

• 利用者のグループ
• 利用者の認可レベル

これらの条件を確認し、管理機能へは管理者のみがアクセスできることを確実にしなければなりません。

検証のため、APIの予測可能な構造を活かしてテスト自動化を部分的に導入するのが賢明です。例えば、全てのAPIエンドポイントにOPTIONSメソッドを実行し、不正なメソッドが使えないかを確認するテストが考えられます。また、利用者の役割やグループのチェックを自動化することも可能ですが、そのためには各役割とグループのアクセスレベルを明確に定義する必要があります。

APIが返す全パラメータを定期的にインデックスしてテストし、利用者が編集してはならないプロパティに変更が加えられないことを確認する必要があります。

‍

‍

結論

この脆弱性の悪用方法は大きく3種類に分類できます。URLや特定のパラメータ、さらにはHTTPメソッドの操作によるものです。この脆弱性の結果はほぼ必ず深刻で、APIレベルでの垂直方向の権限昇格に繋がります。これらの要素を踏まえ、一つ一つの問題を見落とさず、本番環境に影響が出ないよう十分注意する必要があります。

部分的な自動化による検出は有用ですが、ロボットが全てのURLを推測するのは難しいため、手動テストも組み合わせることが大切です。テスト自動化は、管理機能へのアクセスを許すAPIエンドポイントが抜け落ちていないか、ディレクトリのブルートフォースを行う際に大いに役立ちます。ウェブAPIを守る最善の方法 - Wallarm。