ソース：
訳：
私たちはアプリケーションを強化するために API にますます依存しています。
この API セキュリティ 101 シリーズでは、API に影響を与えるセキュリティの脆弱性、これらの脆弱性の原因、および独自のアプリケーションで脆弱性を防ぐ方法について説明します。
おそらく、OWASP のトップ 10 または Web アプリケーションを脅かすトップ 10 の脆弱性について聞いたことがあるでしょう。
OWASP はまた、OWASP API トップ 10 と呼ばれる、API を脅かす脆弱性トップ 10 のリストを定期的に選択します。
現在の API のトップ 10 は 、オブジェクト レベルの認可の破損 、 ユーザー認証の破損 、 過剰なデータ漏洩 、 リソース不足とレート制限、機能レベルの認可の 割り当て 一括 破損、 、 セキュリティ の設定ミス 、 インジェクション 、 不適切な資産管理 、および 不十分なログとモニタリング です。
今日は、OWASP API #5、壊れた関数レベルの認証について話しましょう。
今日の脆弱性について詳しく説明する前に、 オブジェクト レベルの認証の破損 に関する私の投稿を確認しておくと役立つでしょう。
要約すると、API はリソースへのアクセスに使用されるオブジェクト識別子を公開することがよくあります。
オブジェクト レベルの認証の破損は、アクセス制御がこれらのエンドポイントに適切に実装されていない場合に発生し、攻撃者がアクセスすべきではないリソースを表示または操作できる可能性があります。
機能レベルの認証の破損も同様の問題です。 機能レベルの認証の失敗とは、アプリケーションが機密機能を認証されたユーザーに制限できない場合に発生し。
壊れたオブジェクトレベルの認証とは異なり、この欠陥は特に、権限のないユーザーがアクセスすべきではない機密機能や制限された機能にアクセスできる場合を指し。
たとえば、あるユーザーが別のユーザーのアカウントを変更できる場合や、通常のユーザーがサイトの管理機能にアクセスできる場合などで。
これらの問題は、アクセス制御が欠落しているか、設定が間違っていることが原因で発生し。
例 #1: 他の人の投稿を削除する
API により、次のようなエンドポイントに GET リクエストを送信することで、ユーザーがブログ投稿を取得できるとし。
GET /api/v1.1/user/12358/posts?id=32
このリクエストにより、API はユーザー 12358 からの投稿 32 を返し。
このプラットフォーム上のすべての投稿は公開されているため、どのユーザーもこのリクエストを送信して他の人の投稿にアクセスでき。
ただし、ブログ投稿を変更できるのはユーザー自身だけであるため、ユーザー 12358 だけが投稿を変更または編集する POST リクエストを送信でき。
API が PUT および DELETE HTTP メソッドで送信されるリクエストに同じ制限を課さない場合はどうなるでしょうか?
その場合、悪意のあるユーザーが別の HTTP メソッドを使用して他のユーザーの投稿を変更または削除する可能性があります。
このリクエストは別のユーザーの投稿を削除します。
DELETE /api/v1.1/user/12358/posts?id=32
例 #2: 管理者のふりをする
このサイトでは、プラットフォームの管理者が誰の投稿も変更または削除することもできます。 したがって、管理者のアカウントから送信された場合、これらのリクエストはすべて成功します。
DELETE /api/v1.1/user/12358/posts?id=32
POST /api/v1.1/user/12358/posts?id=32
PUT /api/v1.1/user/12358/posts?id=32
ただし、サイトはリクエスト内の特別なヘッダーを使用して誰が管理者であるかを決定し。
Admin: 1
この場合、悪意のあるユーザーはこのヘッダーをリクエストに追加するだけで、この特別な管理機能にアクセスできるようになり。
機能レベルの認可の破損は、アクセス制御の欠如とアクセス制御の不適切な実装の両方によって発生する可能性があり。
例 #3: ドアに鍵がかかっていない
最後に、このサイトでは、管理者が特別な API エンドポイントを介してサイトの統計を表示できるようになります。
GET /api/v1.1/site/stats/hd216zla
この管理エンドポイントは、ユーザーベースの制限を実装しません。
このサイトは、URL エンドポイントの末尾にランダムな文字列が含まれていることを利用して、権限のないユーザーによるアクセスを防ぎます。
この慣行は「隠蔽によるセキュリティ」と呼ばれ、部外者に知識を提供しないことでセキュリティを強化することを意味し。
しかし、隠蔽によるセキュリティは、唯一のセキュリティ メカニズムとしては信頼できず。 攻撃者が情報漏洩によって不明瞭な URL を見つけることができた場合、攻撃者はエンドポイントの背後に隠された機密機能にアクセスでき。
攻撃者は何ができるのでしょうか?
壊れた機能レベルの認証の脆弱性を利用して、攻撃者は何ができるでしょうか?
それは、攻撃者がバグを通じてアクセスできる機能によって異なります。
攻撃者は、他のユーザーになりすまして、制限されたデータにアクセスしたり、他人のアカウントを変更したり、サイトの管理者になったりする可能性があります。
機能レベルの認可の破損を防ぐ鍵は、ユーザーのセッションに基づいてきめ細かく厳密なアクセス制御を実装し、リクエストのメソッド、ヘッダー、および URL パラメーターに関係なく、このアクセス制御が一貫して実装されるようにすることです。
ほなほな。
