【ITニュース解説】Matomo token_auth placement decides where secrets leak

Matomoはウェブサイトのアクセス状況などを分析するためのツールであり、そのAPI（プログラムからMatomoの機能を利用するための仕組み）を利用する際に、認証のために「token_auth」という秘密の文字列を使う。このtoken_authは、ウェブサイトのデータ取得や追跡リクエスト、埋め込みウィジェットの表示などに利用される重要な情報である。Matomoの公式ドキュメントでは、このトークンをユーザーのパスワードと同等に扱うよう説明しており、その扱い方には細心の注意が必要だ。

APIにこのtoken_authを送信する方法は主に二つある。一つは「GETリクエスト」、もう一つは「POSTリクエスト」である。GETリクエストでは、token_authがURLの末尾にパラメータとして直接追加される。例えば、「https://example.com/api?token_auth=abcdefg」のように表示される。この方式の大きな問題点は、トークンがURLの一部として公開されてしまうことだ。具体的には、ウェブブラウザの閲覧履歴、ウェブサーバーのアクセスログ、インターネット上のプロキシサーバーのログ、そして問題発生時のサポート情報として生成されるバンドルファイルなどに、この秘密情報がそのまま記録されてしまう。もし悪意のある第三者がこれらの情報にアクセスできれば、あなたのMatomoアカウントに不正にアクセスされてしまう危険性がある。

一方、POSTリクエストでは、token_authはURLには含まれず、HTTPリクエストの本体（ボディ）に格納されて送信される。この方法だと、URLにトークンが残らないため、ブラウザ履歴やアクセスログなどにトークンが直接記録されるリスクが大幅に減少する。したがって、秘密情報を送信する際には、POSTリクエストを利用することが推奨される。

Matomo 6のドキュメントでは、トークンにアクセスレベルを設定する機能や、「セキュアなリクエストのみを許可する」というオプションが追加された。この「セキュアなリクエストのみを許可する」オプションを有効にすると、そのトークンはPOSTリクエストでのみ受け入れられ、URLパラメータとして送信されるGETリクエストでは拒否されるようになる。これは情報漏洩のリスクを減らす上で非常に有効な機能だが、一つ注意点がある。Matomoと連携しているシステムやツールが、この新しい設定に対応してPOSTリクエストを利用できる必要がある。もし、それらのシステムがGETリクエストしか利用できないように設計されている場合、この設定を強制すると連携が機能しなくなる可能性があるため、事前に十分なテストが必須となる。

MatomoのReporting API（レポート参照API）のドキュメントでは、Tracking API（追跡API）の処理を行う場合には、専用のユーザーとトークンを作成し、必要なウェブサイトに対する最小限の権限のみを付与することが推奨されている。これはレポート参照の作業においても同様だ。例えば、特定のサイトのレポートだけを参照するためのトークンが、他の全てのサイトの管理者権限を持つべきではない。もしMatomoのトークンモデルがより細かいアクセスレベルを提供しているならば、現在利用しているAPIメソッドに合わせて、その最小限の権限で動作するかを十分に検証すべきだ。古いバージョンのMatomoや特定のプラグインの組み合わせによっては、トークンが発行元のユーザーの全権限を継承してしまう可能性もあるため、自身のMatomoのバージョンや導入しているプラグインセットがどのような挙動をするのかを把握しておくことが重要となる。

まず、自社のアプリケーションコードやMatomoの設定ファイルを確認し、token_authがURLパラメータとして渡されていないかを徹底的に調査する。もし見つかった場合は、それをPOSTボディで送信する方法や、OAuthのようなより安全な認証フローが利用可能であればそちらに切り替えるべきだ。また、公開ダッシュボードのURLにトークンを含めたり、トークンが埋め込まれたレポートリンクをコピーして共有したりすることは絶対に避けるべきである。もしトークンをURLで利用した過去がある場合、その際のログファイル、HARファイル（HTTP通信の記録ファイル）、ブラウザの履歴などは、秘密情報を含む証拠として慎重に扱う必要がある。

さらに、Matomoとの通信は常にHTTPS（暗号化された安全な通信）を利用し、信頼できるリバースプロキシサーバーを導入することを推奨する。リバースプロキシでURLのクエリ文字列（URLパラメータ部分）を難読化（ redaction ）できる場合もあるが、これはあくまで補助的な対策として考え、これだけに頼るべきではない。なぜなら、アクセスログは複数のシステムで複製される可能性があるため、一部で難読化しても他の場所で漏れる可能性があるからだ。Matomoの管理画面へのアクセスは、内部ネットワークや、シングルサインオン（SSO）で保護されたゲートウェイを通じてのみ許可するなど、厳しく制限すべきである。また、管理ダッシュボードとデータ追跡用エンドポイントを異なるホスト名で運用することも、セキュリティポリシーをシンプルにする上で有効な場合がある。

万が一、token_authが外部に漏洩してしまった場合は、まずそのトークンをすぐに再生成することが最優先となる。その後、トークンが漏洩していた期間中に、Matomoのレポートや管理設定において不審な変更が行われていないかを詳細に確認する。他のウェブサイトのデータが漏洩する可能性のあるプラグインの設定変更や、不正に保存されたセグメント（特定の条件で絞り込んだ訪問者グループ）がないかもレビューする必要がある。Matomoのセキュリティガイダンスでは、二要素認証（MFA）の利用も推奨されているが、これはログインプロセスを保護するためのものであり、既にコピーされてしまったベアラートークン（漏洩したトークン）そのものを保護する効果はない点に留意すべきだ。

記事には、インターネット上の公開されたMatomoインスタンスの数を調査した結果が示されている。これは「ZoomEye」という検索エンジンでMatomoアプリケーションが検出された件数であり、これらのMatomoインスタンス全てが脆弱であるとか、トークンが漏洩しているという直接的な証拠ではない。しかし、この調査結果は、自社が運用しているMatomoのログインページ、APIエンドポイント、トークンの伝送方法、そして公開レポートの設定が適切に管理されているかを再確認する良い機会となる。最終的に最も重要な防御策は、各Matomo連携システムにおいて、秘密情報であるtoken_authの伝送方法（GETかPOSTか）と、そのトークンが持つ権限の範囲を明確に定義し、それぞれに最も安全で適切な設定を適用することである。