Coders Conquer Security:Share & Learnシリーズ。安全でない直接目的参照
URLは、私たちがよく知っているウェブサイトやウェブアプリケーションをナビゲートするのに欠かせないものです。URLの基本的な機能は、リソースがどこにあり、どのようにしてそれを取得するかを特定することです。URL は、WWW が機能するために必要なものですが、適切に保護されていなければ、セキュリティ上のリスクとなります。
この記事では、学ぶことができます。
- IDORとは何か、攻撃者はどのようにIDORを使うのか
- IDORが危険な理由
- この脆弱性を修正するための技術
IDORを理解する
オブジェクトの直接参照とは、アプリケーション内で特定のレコード（「オブジェクト」）を参照することです。通常、一意の識別子の形をとり、URLで表示されることもあります。
たとえば、URLの末尾に「?id=12345」などと書かれていることがあります。この12345という数字は、特定のレコードへの参照です。個々のレコードに対してアクセス制御が行われていないと、セキュリティ上の脆弱性が生じます。これにより、ユーザーは見てはいけないレコードやデータにアクセスできるようになります。これは、比較的低いスキルレベルを必要とする攻撃です。
この例では、攻撃者が URL の ID を 12344 に変更したとします。IDORに脆弱なアプリケーションでは、攻撃者はそのレコードに関連するデータを見ることができます。
この種の脆弱性は、実際にどれほどの被害をもたらすのでしょうか。
IDORが危険な理由を知る
開発者が注意を怠ると、様々な場所にアプリケーションの記録が表示されたり、漏れたりするシステムを設計してしまうことがあります。このような規模の侵害は、特にセンシティブなデータやPIIが関与している場合、重大な問題となります。
オーストラリア税務局は、企業が新しい税金を徴収するためのウェブサイト を開設しました。しかし、このサイトには、IDORの脆弱性という、望ましくない機能がパッケージされていました。あるユーザーが、サイト内のURLに自分のオーストラリア企業番号（ABN）が含まれていることに気がつきました。この番号は、登録されている企業であれば簡単に見つけることができる番号です。このユーザーは、他の企業の番号をURLに入れることにしました。すると、その企業の銀行口座情報や個人情報が手に入ってしまったのです。
Appleは先日、IDOR脆弱性の被害に遭いました。iPadが発売された当初、11万4千人の顧客のメールアドレスが流出しました。公平に見て、これはむしろAT&T側のミスだった）。
AT&Tは、iPadの3G接続をサポートするサービスを構築していました。iPadは、SIMカードに保存されている識別子をAT&Tのサービスに送信する。AT&Tのサービスは、ユーザーのメールアドレスを返した。
残念ながら、これらの識別子は単なる連続した整数であり、容易に推測することができました。攻撃者は、これらの識別子を繰り返し入力し、メールアドレスを盗み出しました。
もうひとつの失敗は、AT&Tのサービスでは、リクエストのuser-agentヘッダーにiPadからの送信であることが示されている場合にのみ、メールアドレスを返そうとすることで、「安全性」を確保しようとしたことです。user-agentは、簡単に操作できる文字列の値でしかありません。
IDORの脆弱性は巧妙で卑劣なものです。ここでは、その対策について説明します。
IDORを倒す
アクセスコントロールは、IDORを解決するための鍵です。ユーザーが特定のレコードをリクエストした場合、リクエストされたレコードを閲覧する権限があるかどうかを確認します。
一元化された認証モジュールを使用することは、このための最良の方法です。Spring Securityのようなツールは、アプリケーションのための堅牢でカスタマイズ可能な認証と認可を提供します。
要するに、他のすべてのコードが認証チェックを行うために依存するモジュールが1つあればいいのです。
もう一つの一般的な緩和策は、サロゲート参照の使用です。実際のデータベースレコードの識別子をURLに使用する代わりに、実際のレコードに対応する乱数を作成することができます。
サロゲート参照を使用することで、攻撃者が次の有効な識別子を推測してレコードを入手することができないようにします。
そして最後に、ユーザーが操作できるものに依存して認証を行わないことです。AT&Tは、user-agentヘッダーを使って自分たちのサービスを認証しようとしました。HTTPヘッダー、クッキー、GETやPOSTのパラメータに頼ってはいけません。
これらの緩和策を導入することで、IDORは過去のものとなるでしょう。
リファレンスの確保
安全でない直接目的参照は、最も悪用されやすい脆弱性の一つです。予期せぬ時に忍び寄られないようにしましょう。常にユーザーの権限を確認してください。本物のデータベース識別子を使用しないでください。ユーザーが管理するデータに依存した認証を行わない。
ラーニングリソースをチェックして、マスターを目指しましょう。選択した言語でIDORの脆弱性を緩和する方法を練習することで、本番のコードベースでこの問題を発見し、修正することができるようになります。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策については、Secure Code Warrior ブログをご覧ください。
今すぐIDORの攻撃から身を守る準備はできていますか？プラットフォームに向かい、無料でチャレンジしてみてください。[Start Here] (ここからスタート)
Jaap Karan Singh
セキュアコーディングに関する最新の知見をブログでご紹介しています。
当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。
開発者主導のセキュリティに関する最新の研究成果を入手する
ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。
Coders Conquer Security:Share & Learnシリーズ。安全でない直接目的参照
URLは、私たちがよく知っているウェブサイトやウェブアプリケーションをナビゲートするのに欠かせないものです。URLの基本的な機能は、リソースがどこにあり、どのようにしてそれを取得するかを特定することです。URL は、WWW が機能するために必要なものですが、適切に保護されていなければ、セキュリティ上のリスクとなります。
この記事では、学ぶことができます。
- IDORとは何か、攻撃者はどのようにIDORを使うのか
- IDORが危険な理由
- この脆弱性を修正するための技術
IDORを理解する
オブジェクトの直接参照とは、アプリケーション内で特定のレコード（「オブジェクト」）を参照することです。通常、一意の識別子の形をとり、URLで表示されることもあります。
たとえば、URLの末尾に「?id=12345」などと書かれていることがあります。この12345という数字は、特定のレコードへの参照です。個々のレコードに対してアクセス制御が行われていないと、セキュリティ上の脆弱性が生じます。これにより、ユーザーは見てはいけないレコードやデータにアクセスできるようになります。これは、比較的低いスキルレベルを必要とする攻撃です。
この例では、攻撃者が URL の ID を 12344 に変更したとします。IDORに脆弱なアプリケーションでは、攻撃者はそのレコードに関連するデータを見ることができます。
この種の脆弱性は、実際にどれほどの被害をもたらすのでしょうか。
IDORが危険な理由を知る
開発者が注意を怠ると、様々な場所にアプリケーションの記録が表示されたり、漏れたりするシステムを設計してしまうことがあります。このような規模の侵害は、特にセンシティブなデータやPIIが関与している場合、重大な問題となります。
オーストラリア税務局は、企業が新しい税金を徴収するためのウェブサイト を開設しました。しかし、このサイトには、IDORの脆弱性という、望ましくない機能がパッケージされていました。あるユーザーが、サイト内のURLに自分のオーストラリア企業番号（ABN）が含まれていることに気がつきました。この番号は、登録されている企業であれば簡単に見つけることができる番号です。このユーザーは、他の企業の番号をURLに入れることにしました。すると、その企業の銀行口座情報や個人情報が手に入ってしまったのです。
Appleは先日、IDOR脆弱性の被害に遭いました。iPadが発売された当初、11万4千人の顧客のメールアドレスが流出しました。公平に見て、これはむしろAT&T側のミスだった）。
AT&Tは、iPadの3G接続をサポートするサービスを構築していました。iPadは、SIMカードに保存されている識別子をAT&Tのサービスに送信する。AT&Tのサービスは、ユーザーのメールアドレスを返した。
残念ながら、これらの識別子は単なる連続した整数であり、容易に推測することができました。攻撃者は、これらの識別子を繰り返し入力し、メールアドレスを盗み出しました。
もうひとつの失敗は、AT&Tのサービスでは、リクエストのuser-agentヘッダーにiPadからの送信であることが示されている場合にのみ、メールアドレスを返そうとすることで、「安全性」を確保しようとしたことです。user-agentは、簡単に操作できる文字列の値でしかありません。
IDORの脆弱性は巧妙で卑劣なものです。ここでは、その対策について説明します。
IDORを倒す
アクセスコントロールは、IDORを解決するための鍵です。ユーザーが特定のレコードをリクエストした場合、リクエストされたレコードを閲覧する権限があるかどうかを確認します。
一元化された認証モジュールを使用することは、このための最良の方法です。Spring Securityのようなツールは、アプリケーションのための堅牢でカスタマイズ可能な認証と認可を提供します。
要するに、他のすべてのコードが認証チェックを行うために依存するモジュールが1つあればいいのです。
もう一つの一般的な緩和策は、サロゲート参照の使用です。実際のデータベースレコードの識別子をURLに使用する代わりに、実際のレコードに対応する乱数を作成することができます。
サロゲート参照を使用することで、攻撃者が次の有効な識別子を推測してレコードを入手することができないようにします。
そして最後に、ユーザーが操作できるものに依存して認証を行わないことです。AT&Tは、user-agentヘッダーを使って自分たちのサービスを認証しようとしました。HTTPヘッダー、クッキー、GETやPOSTのパラメータに頼ってはいけません。
これらの緩和策を導入することで、IDORは過去のものとなるでしょう。
リファレンスの確保
安全でない直接目的参照は、最も悪用されやすい脆弱性の一つです。予期せぬ時に忍び寄られないようにしましょう。常にユーザーの権限を確認してください。本物のデータベース識別子を使用しないでください。ユーザーが管理するデータに依存した認証を行わない。
ラーニングリソースをチェックして、マスターを目指しましょう。選択した言語でIDORの脆弱性を緩和する方法を練習することで、本番のコードベースでこの問題を発見し、修正することができるようになります。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策については、Secure Code Warrior ブログをご覧ください。
今すぐIDORの攻撃から身を守る準備はできていますか？プラットフォームに向かい、無料でチャレンジしてみてください。[Start Here] (ここからスタート)
