Coders Conquer Security OWASP Top 10 API-Serie — Fehlende Zugriffskontrolle auf Funktionsebene

このシリーズのブログでは、アプリケーション・プログラミング・インターフェース（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 トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。