コーダーのためのセキュリティ攻略：共有＆学習シリーズ：安全でない直接オブジェクト参照

URLは、私たちが日常的に利用するあらゆるWebサイトやWebアプリケーションを操作するために不可欠なものです。その基本的な機能は、リソースの場所を特定し、それを取得する方法を示すことです。URLはワールドワイドウェブの動作に欠かせないものですが、適切に保護されていない場合、セキュリティリスクを引き起こす可能性もあります。

本記事では、以下の内容を学びます。

• IDORとは何か、そして攻撃者はどのようにIDORを利用するのか
• IDORがなぜ危険なのか
• この脆弱性を修正するための技術

IDORを理解する

直接オブジェクト参照とは、アプリケーション内で特定のレコード（「オブジェクト」）が参照されることを指します。通常は一意の識別子の形式を取り、URL内に表示されることがあります。

例えば、URLの末尾に「?id=12345」のような文字列があることに気づくかもしれません。この数字「12345」は、特定のレコードへの参照です。個々のレコードに対するアクセス制御が欠如していると、セキュリティ上の脆弱性が入り込みます。これにより、ユーザーは本来閲覧すべきではないレコードやデータにアクセスできてしまいます。これは、比較的低いスキルレベルで実行可能な攻撃です。

この例で、攻撃者がURL内のIDを「12344」に変更したとします。IDORに対して脆弱なアプリケーションであれば、攻撃者はそのレコードに関連するデータを閲覧できてしまいます。

この種の脆弱性は、実際にはどれほどの被害をもたらすのでしょうか？

IDORがなぜ危険なのかを知る

開発者が注意を怠ると、アプリケーションのレコードをさまざまな場所で表示・漏洩させてしまうシステムを設計してしまう可能性があります。これほど大規模な侵害は、特に機密データや個人情報（PII）が関与している場合、非常に深刻な事態となります。

オーストラリア税務局は、新しい税金の徴収を支援するためのWebサイトを開設しました。残念なことに、そのサイトにはIDOR脆弱性という望ましくない機能が組み込まれていました。ある好奇心旺盛なユーザーが、サイト内のURLに自身のオーストラリア事業番号（ABN）が含まれていることに気づきました。この番号は、登録済みの企業であれば誰でも簡単に調べられるものです。このユーザーが他の企業の番号をURLに入力してみたところ、なんと他社の銀行口座情報や個人情報が表示されてしまったのです！

Appleも最近、IDOR脆弱性の被害に遭いました。iPadが最初に発売された際、11万4,000人分の顧客メールアドレスが流出したのです。（公平を期すために言えば、これはAT&T側のミスによる側面が強いものです）。

当時、AT&TはiPadの3G接続をサポートするサービスを構築していました。iPadはSIMカードに保存された識別子をAT&Tのサービスに送信し、サービス側がそのユーザーのメールアドレスを返すという仕組みでした。

残念ながら、これらの識別子は単純な連番であったため、容易に推測可能でした。攻撃者は識別子を順次試すことで、メールアドレスを盗み出しました。

もう一つのミスは、AT&Tのサービスが、リクエストのユーザーエージェントヘッダーがiPadからのものであると示されている場合にのみメールアドレスを返すことで、サービスを「保護」しようとした点です。ユーザーエージェントは単なる文字列であり、簡単に操作できてしまいます。

IDORの脆弱性は、巧妙で気づきにくいものです。これらを防ぐ方法について議論していきましょう。

IDORの克服

IDORを解決する鍵はアクセス制御です。ユーザーが特定のレコードを要求した際は、そのユーザーに当該レコードを閲覧する権限があるか必ず確認してください。

これには、一元化された認可モジュールの使用が最適です。Spring Securityのようなツールは、アプリケーションに対して堅牢かつカスタマイズ可能な認証・認可機能を提供します。

要するに、他のすべてのコードが認可チェックを行う際に依存するモジュールを一つ用意しておくことが重要です。

もう一つの一般的な緩和策は、サロゲート参照の使用です。URLに実際のデータベースレコード識別子を使用する代わりに、実際のレコードと紐付けられたランダムな数値を生成します。

サロゲート参照を使用すれば、攻撃者が次の有効な識別子を推測するだけでレコードにアクセスすることは不可能になります。

最後に、ユーザーが操作可能な情報を認可の根拠にしないでください。AT&TはUser-Agentヘッダーを使用してサービスを認可しようとしましたが、HTTPヘッダー、Cookie、GET/POSTパラメータを認可の判断材料にしてはいけません。

これらの対策を講じることで、IDORは過去のものとなるでしょう。

参照の安全性を確保する

安全でない直接オブジェクト参照（IDOR）は、最も悪用されやすい脆弱性の一つです。不意を突かれないよう注意しましょう。常にユーザーの認可を確認し、実際のデータベース識別子を使用せず、ユーザーが制御可能なデータを認可の根拠にしないでください。

習熟度を高めるために、当社の学習リソースをご覧ください。Secure Code Warriorブログ

今すぐIDOR攻撃への防御を始めませんか？プラットフォームにアクセスして、無料のチャレンジに挑戦してください： [こちらから開始]