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] (ここからスタート)
始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、Secure Code Warrior 共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士、そして専門家であるクリス・イングリス（Chris Inglis）氏（元米国サイバーディレクター、現パラディン・キャピタル・グループ戦略顧問）、デヴィン・リンチ（Devin Lynch）氏（パラディン・グローバル・インスティテュート・シニアディレクター）が、CISO、アプリケーション・セキュリティ担当副社長、ソフトウェア・セキュリティの専門家など、企業のセキュリティ・リーダー20人以上への詳細なインタビューから得られた主な知見を明らかにします。
セキュリティ スキルのベンチマーク: 企業におけるセキュアな設計の合理化
セキュアバイデザイン（SBD）構想の成功に関する有意義なデータを見つけることは、非常に困難である。CISO は、セキュリティプログラム活動の投資収益率（ROI）とビジネス価値を、従業員レベルと企業レベルの両方で証明しようとすると、しばしば困難に直面します。言うまでもなく、企業にとって、現在の業界標準に対して自社の組織がどのようにベンチマークされているかを把握することは特に困難です。大統領の国家サイバーセキュリティ戦略は、関係者に「デザインによるセキュリティとレジリエンスを受け入れる」ことを求めている。セキュアバイデザインの取り組みを成功させる鍵は、開発者にセキュアなコードを保証するスキルを与えるだけでなく、規制当局にそれらのスキルが整っていることを保証することである。本プレゼンテーションでは、25万人以上の開発者から収集した社内データ、データに基づく顧客の洞察、公的研究など、複数の一次ソースから得られた無数の定性的・定量的データを紹介します。こうしたデータ・ポイントの集積を活用することで、複数の業種におけるセキュア・バイ・デザイン・イニシアチブの現状をお伝えすることを目的としています。本レポートでは、この領域が現在十分に活用されていない理由、スキルアッププログラムの成功がサイバーセキュリティのリスク軽減に与える大きな影響、コードベースから脆弱性のカテゴリーを排除できる可能性について詳述しています。
始めるためのリソース
明らかになった：サイバー業界はセキュア・バイ・デザインをどのように定義しているか
最新のホワイトペーパーでは、当社の共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士が、CISO、AppSecリーダー、セキュリティ専門家を含む20人以上の企業セキュリティリーダーと対談し、このパズルの重要なピースを見つけ出し、Secure by Design運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
