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は、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
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] (ここからスタート)
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] (ここからスタート)
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
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] (ここからスタート)
始めるためのリソース
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
.png)
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.