A guide to the OWASP API top ten
2021/10/19 SecurityBoulevard — OWASP Top-10 や、Web Application 脆弱性 Top-10 について聞いたことがあると思う。OWASP は、API を脅かす脆弱性の Top-10 も定期的に選出しており、それは OWASP API Top-10 と呼ばれている。
現在の API Top-10 は、Broken Object Level Authorization／Broken User Authentication／Excessive Data Exposure／Lack of Resources & Rate Limiting／Broken Function Level Authorization／Mass Assignment／Security Misconfiguration／Injection／Improper Assets Management／Insufficient Logging & Monitoring の順になっている。
この記事では、それらの脆弱性が発生する状況および、特定する方法、そして防ぐための方法を理解するために、個々の脆弱性について掘り下げていく。まずは、API#1 のBroken Object Level Authorization から見ていこう。
API #1: Broken Object-Level Authorization (オブジェクト・レベル認証の失敗)
API では、リソースへのアクセスを実現するための、オブジェクト識別子が公開されることが多い。オブジェクト・レベル認証の失敗は、個々のエンドポイントに対するアクセス制御が、適切に実装されていない場合に起こる。それにより、攻撃者は、アクセスできないはずのリソースを閲覧／操作することが可能となる。
https://api.example.com/v1.1/users/payment_methods/show?user_id=1237962
オブジェクト・レベル認証の失敗の脆弱性を攻撃者が利用すると、データ・オブジェクトの読取／更新／削除／作成を、許可なく行うことが可能になるかもしれない。ユーザーの PII や認証情報などの、重要なオブジェクトが公開され、このバグが存在する場合には、データ侵害や、アプリケーションの危殆化が生じる恐れがある。たとえば、オンライン・ショッピング・サイトのユーザー情報が漏洩した場合、何百万もの銀行口座／クレジットカード番号／住所などを、攻撃者が入手する可能性が生じる。もし、この脆弱性が銀行のサイトで見つかった場合には、顧客の信用情報や納税申告書などを、攻撃者が流出させる可能性が生じる。この脆弱性に関する事例／影響と、それらを防ぐ方法については、ShiftLeft の記事で紹介されている。
API #2: Broken User Authentication (壊れたユーザー認証)
OWASP が次に選んだ脆弱性は、Broken User Authentication である。この脆弱性は、API における認証メカニズムが、誤って設定されている場合に発生する。この問題は、たった一つのミスで、攻撃者によりユーザー・アカウントが乗っ取られ、制限されたデータや機能へのアクセスを許してしまうため、壊滅的な被害がもたらされる。しかし、なぜこの問題は、特に API の実装において多く見られるのだろうか？
APIにとって認証は難しい。多くの場合、ユーザー認証情報の入力を促すことや、多要素認証を要求することなどは、API コール中には実行できない。そのため、API システムにおける認証は、アクセス・トークンを使って実装されることが多い。アクセス・トークンとは、ユーザーを認証するために、個々の API コールに埋め込まれるトークンのことだ。
アクセス・トークンには様々な問題がある。具体的には、トークンの不適切な生成や、トークンの無効化、そして、別の脆弱性を経由したトークンの漏洩などが起こり得る。これらの問題が発生した場合、攻撃者は設定ミスを悪用し、他人に成りすますことが可能となる。壊れたユーザー認証の具体的な事例と、対処するための適切な方法については、ShiftLeft の記事を参照してほしい。
API #3: Excessive Data Exposure (過剰なデータ露出)
過剰なデータ露出とは、アプリケーションが API レスポンスを介して、必要以上の情報をユーザーに対して公開することだ。アプリケーション開発者の中には、機密情報を Web ページに表示しなければ、ユーザーには見えないと思い込んでいる人がいる。そのため、機密情報を最初にフィルタリングせずに、API レスポンスでユーザーのブラウザに送信し、クライアント側のコードに頼って機密情報をフィルタリングするケースが生じる。この場合には、誰もが API レスポンスを傍受して、機密情報を取り出せてしまう。
これは、実際のアプリケーションや API の実装において、最も見つけやすい脆弱性の一つである。この、ShftLeft の記事では、過剰なデータ露出をハントする方法と、それを防ぐための方法を述べている。
API #4: Lack of Resources & Rate Limiting (リソースの不足とレートの制限)
リソース不足とレート制限とは、特定の API クライアントからの、リクエストの数や頻度を制限しないことである。つまり、ある API クライアントが、１秒間に数千回以上の API コールを行う場合や、一度に数百／数千のデータ・レコードをリクエストする場合であっても、それらの要求をサーバーは満たそうとしてしまう。
レート制限を設けないと、API サーバーのパフォーマンスに影響を与える DoS 攻撃を、攻撃者が仕掛けることが可能となる。複数のクライアントが、一度に多くのリクエストを行うと、それらのリクエストがサーバーの処理能力を超えてしまい、サービスのが遅延／ダウンに至ることになる。
また、レート制限がないと、認証エンド・ポイントへの、ブルートフォース攻撃につながるという問題も生じる。たとえば、ユーザーがログイン・リクエストを制限なく送信できる場合には、悪意の攻撃者は、成功するまで異なるパスワードでログインを試みる、パスワード総当りで解読することが可能となる。このような問題を防ぐためには、リソースに対するアクセス制限を行う必要がある。
API #5: Broken Function-Level Authorization (関数レベルの認証の失敗)
機能レベル認証の失敗とは、アプリケーションの機密性の高い機能において、限定されたユーザーだけにアクセスを制限できないことである。オブジェクト・レベルの認証の不備とは異なり、この欠陥は、アクセスすべきではない機密機能や制限された機能に、権限のないユーザーがアクセスできてしまう状況を指す。
たとえば、ユーザーによる別のユーザーのアカウント変更や、一般的なユーザーによる管理者機能へのアクセスなどが、このケースに当てはまる。このような問題は、アクセス・コントロールの欠落や誤設定により引き起こされる。この記事では、ペネトレーション・テストで見つかった事例と、機能レベルの認証の不備により攻撃者に許される行為を紹介している。
API #6: Mass Assignment (マス・アサインメント)
マス・アサインメントとは、複数の変数やオブジェクトのプロパティに対して、一度に値を代入することである。しかし、この機能は、プログラムの変数やオブジェクトのプロパティに対する、上書／変更／作成などを、攻撃者に許してしまう場合がある。したがって、この欠陥を利用した、アクセスできないはずのデータの上書きや、アプリケーション・ロジックの変更などが可能になる場合がある。これらの攻撃が、どのように行われるかについては、こちらを参照してほしい。
API #7: Security Misconfiguration (セキュリティの設定ミス)
セキュリティ上の誤設定とは、冗長なエラーメッセージ／HTTP ヘッダの設定ミス／不要なサービスや HTTP メソッド／安全ではないデフォルト設定などの、さまざまな設定上の問題を総称したものである。これらは、API と非 API アプリケーションの両方に対して、常にセキュリティ上の脅威となっている。この記事では、API やアプリケーションを脅かす可能性のある、最も一般的なセキュリティ上の誤設定のリストと、それらを排除する方法を紹介する。
API #8: Injection (インジェクション)
インジェクションには、SQL インジェクション／OSコマンド・インジェクション／XMLインジェクションなどがあり、数多くの脆弱性における根本的な問題である。また、インジェクションは、実際のアプリケーションや API で発見される脆弱性の中で、大きな割合を占めている。
この脆弱性は、信頼できないユーザーのデータとコードを、アプリケーションが適切に区別できない場合に発生する。アプリケーションにおいて、信頼できないユーザー・データが、コマンドやクエリに挿入される前に、適切に処理できないケースが生じると、プログラムのインタプリタが、ユーザーの入力をコマンドやクエリの一部と混同してしまう。
このような状況になると、アプリケーションのコマンドの意味を変えるような方法で、攻撃者はアプリケーションにデータを送信することが可能となる。
たとえば、SQL インジェクション攻撃では、攻撃者は SQL コマンドを操作するためにデータを注入しする。また、コマンド・インジェクション攻撃では、攻撃者はホスティングサーバー上の、OS コマンドのロジックを操作するためデータを注入する。入力検証／パラメータ化／エスケープを実装することで、インジェクションの問題は防げる。
API #9: Improper Assets Management (不適切な資産管理)
不適切な資産管理というと複雑に聞こえるが、本質的には「API のエンドポイントを把握していない」ということである。このような状況には、AP Iドキュメントが不完全な場合と、API ドキュメントが完全に欠如している場合がある。
一般的な API においては、バージョン情報／機能／エンドポイントに加えて、対象となるエンドポイントの動作に影響を与える多くのパラメータが含まれている。そして、これらの機能をすべて把握していないと、未知のエンドポイントに隠れているセキュリティ脆弱性に気づかないことになる。そして、知らないものを守ることはできない。
ドキュメントの不完全性や欠落に加えて、不正確なドキュメントもセキュリティ上の問題である。API エンドポイントの詳細を記したドキュメントが存在するとしても、それは各エンドポイントが何をしているかを示しているだろうか？ たとえば、別の HTTP メソッドを受け入れるなど、ドキュメントに記載されていないエンドポイントの動作があるだろうか？ また、エンドポイントの機能に影響を与える、文書化されていないパラメータはあるだろうか？ つまり、不正確なドキュメントは、安全なはずのエンドポイントが、想定外の機能を実行するという可能性を持っている。
優れたドキュメントを持たないことが脆弱性につながるケースと、API を安全にするための、いくつかの例を紹介する。
API #10: Insufficient Logging & Monitoring (不十分なロギングとモニタリング)
多くの組織では、ネットワーク・イベントやサーバ・ログインのログを取るような、インフラに対するロギングは行わてれているが、API やアプリケーションに特化したモニタリング・インフラが不足している。したがって、API で行われている悪意のアクティビティを把握できていないことになる。
APIの異常な使用を監視するための、API ロギング・システムが必要である。入力検証の失敗／認証・認可の成功と失敗／アプリケーション・エラーの記録に加えて、支払いやアカウント設定などの、機密性の高い機能を扱う API イベントなども記録できる。時間の経過とともに、API の通常の使用方法に対する理解が深まり、攻撃の可能性がある不審な活動を検出できるようになる。
ロギングとモニタリングを設定した後に、セキュリティ・インシデントが発生した場合に備えて、効果的なアラート・システムを用意すべきだ。結局のところ、監視システムにおいては、その結果が時間通りに、適切な人に届けられてこそ意味がある。このようにして、チームによる迅速なインシデント解決へと至り、システムへのダメージを抑えることが可能となる。
ーーーーー
以上、OWASP API Top-10 の概要について説明してきた。OWASP API Top-10 のうち、最もよく目にするものはどれでだろうか？ また、他にどのようなセキュリティ・コンセプトについて学びたいと思うだろうか？それを、ぜひ知りたい。お気軽に Twitter @vickieli7 でご連絡ください。
アプリケーション・セキュリティについて詳細を知りたいなら、OWASP Top-10 コースを無料で受講できる。https://www.shiftleft.io/learn/
７月末に「API 攻撃のトラフィックが６ヶ月で 300+% も増大している」という記事をポストしましたが、この OWASP API Top-10 を眺めてみると、API を守るということが、なかなか難しいことであることが理解できます。他にも、以下のような記事がありますので、よろしければ ご参照ください。
API セキュリティのためのベスト・プラクティスを策定する
ゼロトラストを API セキュリティに適用するには
API と セキュリティ：新たな頭痛のタネと処方箋
IoT OT Security News 