Coders Conquer Security OWASP Top 10 API Series - Missing Function Level Access Control

2020年10月07日発行
マティアス・マドゥ博士著
ケーススタディ

Coders Conquer Security OWASP Top 10 API Series - Missing Function Level Access Control

2020年10月07日発行
マティアス・マドゥ博士著
リソースを見る
リソースを見る

このシリーズのブログでは、アプリケーション・プログラミング・インターフェース(API)に関連する最悪の脆弱性に焦点を当てます。これらの脆弱性は、Open Web Application Security Project(OWASP)のトップAPI脆弱性リストに掲載されるほどのものです。APIが現代のコンピューティングインフラにとっていかに重要であるかを考えると、これらはアプリケーションやプログラムから絶対に排除しなければならない重大な問題です。

関数レベルのアクセス制御ができない脆弱性は、制限すべき機能をユーザに実行させたり、保護すべきリソースにアクセスさせたりします。通常、機能やリソースは、コード内または構成設定によって直接保護されますが、正しく行うことは必ずしも容易ではありません。最近のアプリケーションには、多くの種類のロールやグループが含まれていることが多く、さらに複雑なユーザ階層があるため、適切なチェックを実施することは困難です。

しかしその前に、ゲーム化されたチャレンジをプレイして、このトリッキーなクラスのバグを乗り越えるための自分のレベルを確認してみませんか?

さらに詳しく見ていきましょう。

APIは高度に構造化されているため、特にこの欠陥の影響を受けやすい。コードを理解している攻撃者は、制限されるべきコマンドをどのように実装するかについて、経験に基づいた推測を行うことができます。これが、関数/リソースレベルのアクセス制御の脆弱性がOWASPのトップ10に入った主な理由の一つです。

機能レベルのアクセス制御の脆弱性を攻撃者はどのように利用するのでしょうか?

機能やリソースが適切に保護されていないことを疑う攻撃者は、まず攻撃したいシステムにアクセスする必要があります。この脆弱性を利用するためには、エンドポイントに正当なAPIコールを送信する許可を得なければなりません。おそらく、アプリケーションの機能の一部として、低レベルのゲストアクセス機能や、匿名で参加できる何らかの方法があるのでしょう。このようなアクセスが確立されると、正当なAPIコールの中のコマンドを変更することができます。例えば、GETをPUTに置き換えたり、URLのUSERSの文字列をADMINSに変更したりすることができる。繰り返しになるが、APIは構造化されているので、どのコマンドが許可されているか、文字列のどこに入れればいいかは簡単に推測することができる。

OWASP は、この脆弱性の例として、新規ユーザーがウェブサイトに参加できるように設定された登録プロセスを挙げています。おそらく、以下のような API の GET 呼び出しを使用することになるでしょう。

GET /api/invites/{invite_guid}を取得します。

悪意のあるユーザーは、ユーザーの役割や電子メールなど、招待に関する詳細が記載されたJSONを返します。その後、GETをPOSTに変更し、さらに以下のAPIコールを使用して、招待をユーザーから管理者に昇格させることができます。

POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}

POSTコマンドを送信できるのは管理者のみであるべきですが、適切に保護されていない場合、APIはそのコマンドを正当なものとして受け入れ、攻撃者が望むものを実行してしまいます。この場合、悪意のあるユーザーは、新しい管理者としてシステムに招待されることになります。その後、彼らは正当な管理者ができることを何でも見たりやったりできるようになりますが、これは良いことではありません。

機能レベルのアクセスコントロールの脆弱性の解消

このAPIの脆弱性を防ぐことは特に重要です。攻撃者にとって、構造化されたAPI内で保護されていない関数を見つけることは難しいことではありません。攻撃者は、APIにある程度アクセスすることができれば、コードの構造をマッピングして、最終的に追跡されるような呼び出しを作成し始めることができます。

そのため、すべてのビジネスレベルの機能は、ロールベースの認証方法を使用して保護する必要があります。ほとんどのフレームワークは、それを実現するための一元化されたルーチンを提供しています。もし、あなたが選んだフレームワークが提供していない場合や、提供されているルーチンを実装するのが難しい場合は、簡単に使用できるように特別に作られた多くの外部モジュールがあります。最終的にどのような方法を選択するにせよ、認証は必ずサーバ上で行うようにしてください。クライアント側で機能を保護しようとしないでください。

機能レベルやリソースレベルのパーミッションを作成する際には、ユーザーには必要なことを行うためのパーミッションのみを与え、それ以上は与えないようにすることを念頭に置いてください。APIのコーディングでも何でも、常にそうであるように、最小特権の方法論を実践してください。

この脆弱性に関する詳しい情報は、以下のブログをご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。

リソースを見る
リソースを見る

著者

マティアス・マドゥ博士

マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社(Sensei Security)などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング(courses )の講師も務めています。

Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。

もっと知りたい?

セキュアコーディングに関する最新の知見をブログでご紹介しています。

当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。

ブログを見る
もっと知りたい?

開発者主導のセキュリティに関する最新の研究成果を入手する

ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。

リソース・ハブ

Coders Conquer Security OWASP Top 10 API Series - Missing Function Level Access Control

2020年10月07日発行
マティアス・マドゥ博士著

このシリーズのブログでは、アプリケーション・プログラミング・インターフェース(API)に関連する最悪の脆弱性に焦点を当てます。これらの脆弱性は、Open Web Application Security Project(OWASP)のトップAPI脆弱性リストに掲載されるほどのものです。APIが現代のコンピューティングインフラにとっていかに重要であるかを考えると、これらはアプリケーションやプログラムから絶対に排除しなければならない重大な問題です。

関数レベルのアクセス制御ができない脆弱性は、制限すべき機能をユーザに実行させたり、保護すべきリソースにアクセスさせたりします。通常、機能やリソースは、コード内または構成設定によって直接保護されますが、正しく行うことは必ずしも容易ではありません。最近のアプリケーションには、多くの種類のロールやグループが含まれていることが多く、さらに複雑なユーザ階層があるため、適切なチェックを実施することは困難です。

しかしその前に、ゲーム化されたチャレンジをプレイして、このトリッキーなクラスのバグを乗り越えるための自分のレベルを確認してみませんか?

さらに詳しく見ていきましょう。

APIは高度に構造化されているため、特にこの欠陥の影響を受けやすい。コードを理解している攻撃者は、制限されるべきコマンドをどのように実装するかについて、経験に基づいた推測を行うことができます。これが、関数/リソースレベルのアクセス制御の脆弱性がOWASPのトップ10に入った主な理由の一つです。

機能レベルのアクセス制御の脆弱性を攻撃者はどのように利用するのでしょうか?

機能やリソースが適切に保護されていないことを疑う攻撃者は、まず攻撃したいシステムにアクセスする必要があります。この脆弱性を利用するためには、エンドポイントに正当なAPIコールを送信する許可を得なければなりません。おそらく、アプリケーションの機能の一部として、低レベルのゲストアクセス機能や、匿名で参加できる何らかの方法があるのでしょう。このようなアクセスが確立されると、正当なAPIコールの中のコマンドを変更することができます。例えば、GETをPUTに置き換えたり、URLのUSERSの文字列をADMINSに変更したりすることができる。繰り返しになるが、APIは構造化されているので、どのコマンドが許可されているか、文字列のどこに入れればいいかは簡単に推測することができる。

OWASP は、この脆弱性の例として、新規ユーザーがウェブサイトに参加できるように設定された登録プロセスを挙げています。おそらく、以下のような API の GET 呼び出しを使用することになるでしょう。

GET /api/invites/{invite_guid}を取得します。

悪意のあるユーザーは、ユーザーの役割や電子メールなど、招待に関する詳細が記載されたJSONを返します。その後、GETをPOSTに変更し、さらに以下のAPIコールを使用して、招待をユーザーから管理者に昇格させることができます。

POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}

POSTコマンドを送信できるのは管理者のみであるべきですが、適切に保護されていない場合、APIはそのコマンドを正当なものとして受け入れ、攻撃者が望むものを実行してしまいます。この場合、悪意のあるユーザーは、新しい管理者としてシステムに招待されることになります。その後、彼らは正当な管理者ができることを何でも見たりやったりできるようになりますが、これは良いことではありません。

機能レベルのアクセスコントロールの脆弱性の解消

このAPIの脆弱性を防ぐことは特に重要です。攻撃者にとって、構造化されたAPI内で保護されていない関数を見つけることは難しいことではありません。攻撃者は、APIにある程度アクセスすることができれば、コードの構造をマッピングして、最終的に追跡されるような呼び出しを作成し始めることができます。

そのため、すべてのビジネスレベルの機能は、ロールベースの認証方法を使用して保護する必要があります。ほとんどのフレームワークは、それを実現するための一元化されたルーチンを提供しています。もし、あなたが選んだフレームワークが提供していない場合や、提供されているルーチンを実装するのが難しい場合は、簡単に使用できるように特別に作られた多くの外部モジュールがあります。最終的にどのような方法を選択するにせよ、認証は必ずサーバ上で行うようにしてください。クライアント側で機能を保護しようとしないでください。

機能レベルやリソースレベルのパーミッションを作成する際には、ユーザーには必要なことを行うためのパーミッションのみを与え、それ以上は与えないようにすることを念頭に置いてください。APIのコーディングでも何でも、常にそうであるように、最小特権の方法論を実践してください。

この脆弱性に関する詳しい情報は、以下のブログをご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。

弊社製品や関連するセキュアコーディングのトピックに関する情報をお送りする許可をお願いします。当社は、お客様の個人情報を細心の注意を払って取り扱い、マーケティング目的で他社に販売することは決してありません。

送信
フォームを送信するには、「Analytics」のCookieを有効にしてください。完了したら、再度無効にしてください。