＜目次＞

権限昇格とは

権限昇格はアクセス制御の不備（OWASP Top10 2017,2021）の一つで、ユーザが本来アクセス権を持たない機能やデータの閲覧、操作ができてしまう問題である。

ユーザがシステムを利用する際、アカウントの種別やユーザの属性によりアクセス可能な機能やデータが設定されている。
例えば、「ログインしたユーザのみ閲覧可能な情報」「本人だけが参照できる注文履歴」「管理者だけが変更できるサイト設定」などが挙げられる。
このとき、システムに脆弱性があると本来そのユーザができないはずの閲覧や操作が可能となる。

アカウント種別の例

• 管理者ユーザ
• 一般ユーザ
• 未ログインユーザ

ユーザ属性の例

• 本人
• チーム
• 企業

二種類の権限昇格

権限昇格は「垂直権限昇格」と「水平権限昇格」の大きく二種類に分けられる。

垂直権限昇格

異なるアカウントの種別間で発生する権限昇格を垂直権限昇格と呼ぶ。
アカウント種別を、管理者、一般、未ログインで権限が上下関係にあると捉え、上位権限のみに許可された操作を下位権限が行えることを指す。
近年ではアカウント種別は必ずしも上下関係ではない為、本来許可されていない「機能」を使用できてしまう場合に用いられる場合が多い。

水平権限昇格

同一のアカウント種別で異なるユーザ属性間で発生する権限昇格を水平権限昇格と呼ぶ。
システムではアカウント種別が同一でも、ユーザ属性に応じてアクセス権が設定されることが多いが、他人の「データ」を自分のもののように扱えてしまうことを指す。

権限昇格の例

アクセス権の制限を画面表示にしか行っていない

第7回で解説した「強制ブラウジング」に類似している。
アクセス権を持たないユーザがメニューを表示した際、アクセス権を持たない画面へのボタンやリンクが表示されないのは一般的な仕様である。
だが、このとき遷移先の機能の中で権限確認を行っていない場合、URLを直接入力することで処理を実行できてしまう。

対策

権限確認は画面表示時だけでなく、機能の実行前に確実に実施すること。
加えて、権限確認を行う関数やモジュールをライブラリ化して、全画面をデフォルトで呼び出す設定とすると良い。

パラメータの検証を行っていない

処理を行うデータのIDや、処理内容を指示するキー（view, edit, delete等）をパラメータで送信しているシステムは多い。
パラメータの形式確認（バリデーション）は一般的だが、パラメータが指す対象にアクセス権があるかを確認していない場合がある。
その際、ユーザが改ざんした値を送信していた場合は、アクセス権のないデータを処理してしまう。

対策

データに対して処理を行う場合は、パラメータの形式確認だけでなくアクセス権の確認も行う。
特に形式確認はロジックのみで可能だが、アクセス権の確認はデータベースに問い合わせが必要な場合が多い。
データベース問い合わせでのアクセス権の確認は、Where句の条件にはユーザが入力したパラメータだけではなく、セッション等から取得した検証済みの値を使用すると良い。

権限昇格の診断方法

クロスサイト・スクリプティングやSQLインジェクションのような脆弱性は、機能要件に依存せず、発生した際に脆弱性であると判断することができる。
一方、どのユーザがどの機能、どのデータを処理できるかといったアクセス権の設定については、システムの機能要件に依存してしまったり、プロジェクトによっては定義されていなかったりすることすらある。
そのため、一般的に権限昇格について動的診断/静的診断のいずれも全自動で検出するのは難しく、人による目視と判断が必要となる。
（自動化も可能ではあるが、アクセス権の設定をマシンリーダビリティな形式で定義するのは手間がかかる。）

権限昇格のテストが必要な箇所

垂直権限昇格のテストが必要な箇所

特定のアカウントのみ実行できる機能（暗黙的な仕様に注意）

• 診断方法
  制限されているアカウントからURL・パラメータ等を改ざんし、直接機能を実行する。
• 判定基準
  本来の権限では実行できない処理を実行することができた場合は脆弱性がある

水平権限昇格のテストが必要な箇所

• パラメータ、ヘッダー、URLにてユーザ固有の情報（ユーザーID、オーダー番号）を送信している画面
  例）http://example.com/order.php?orderid=000033 （架空URL）
• 診断方法
  ユーザ固有の情報を、別ユーザの情報に書き換えて送信する。
  例）http://example.com/order.php?orderid=000034
• 判定基準
  別ユーザのデータが閲覧できた、または変更できた場合は脆弱性がある。

まとめ

今回は権限昇格の問題を解説した。
権限昇格はログイン機能があるシステムでは意図して予防しない限り、作りこんでしまう可能性のある脆弱性だ。
権限設定については設計時点で定義し、開発時点では権限確認方法を確立しておくことが望ましい。

過去の脆弱性コラムについてはこちらからご確認ください。