セキュリティについて考慮すべき事柄

あなたの Web サイトに Persona のサポートを追加する場合、Persona ができるだけセキュリティの重荷を負います。しかしながら、セキュリティのある面においては、あなたの Web サイトでしか対処できないことがあります。以下は、そのリストです。

ベストプラクティス

あなたのサーバ上でアサーションを検証する

Persona を使う時は、ID アサーションが navigator.id.watch() の onlogin 関数に渡されます。アサーションは、常にあなたの検証サーバに渡してください。その検証結果を基に、あなたのサーバがユーザに追加の許可を与えるかどうかを決定してください:

// navigator.id.watch({ ... 内
onlogin: function(assertion) {
  // ユーザがログインしようとしています！ ここで必要なことは:
  // 1. アサーションを検証のためにバックエンドに送信し、セッションを作成する。
  // 2. UI を更新する。
},

ユーザのブラウザで実行される JavaScript を使用してアサーションを検証しようとすると、悪意のあるユーザがローカルのインジェクションコードであなたのサイトのユーザに偽装し、JavaScript コードを覆すことができてしまいます。これは、コードが実行されるユーザのブラウザをあなたが完全に制御できないため、可能となります。

繰り返しますが、アサーションは、常にあなたの検証サーバに渡してください。リモート検証 API を使用する場合でも同じです。

`audience` 引数を明記する

アサーションを検証するには、POST リクエストを https://verifier.login.persona.org/verify に送信します。このリクエストには audience と呼ばれる引数が含まれます:

assertion=<ASSERTION>&audience=https://mysite.com:443"

audience 引数は必須です。常に、あなたのコード内かコードの設定内に audience を明記してください。特に次のことに注意してください:

ユーザのブラウザが送信した Host ヘッダを信頼してはいけません。
ユーザのブラウザが送信した明示的な引数を信頼してはいけません。ただし、document.location など、あなたの JavaScript で生成されたものを除きます。

ユーザのブラウザから伝えられた audience を信頼してしまうと、悪意のある Web サイトが 自身の Web サイトのアサーションを再利用して あなたの Web サイトにログインすることが可能になります。

SSL 証明書を検証する

アサーションを検証するには、POST リクエストを https://verifier.login.persona.org/verify に送信します。この HTTPS リクエストで、サーバから送られた証明書を信頼されたルート証明書に照らし合わせて確実に検証しなければなりません。これをしない場合、攻撃者が verifier.login.persona.org になりすまして偽の検証結果を返すことができます。

使用しているライブラリが証明書の検証リクエストを正しく行い、適切なルート証明書でそれを初期化しているか確認してください。

例えば、Python 2.7 の標準の urllib2 モジュールは、サーバ証明書を検証しません。代わりに、Python 2.x の "requests" モジュールや "urllib3" モジュール、または Python 3.x の標準の http.client.HTTPSConnection クラスの使用を推奨します。Perl の場合は、libwww-perl のバージョン 6.0 以降を使用してください。使用している言語やライブラリ、オペレーティングシステムによりますが、信頼された CA ルートと verifier.login.persona.org で使用されている単独の CA のどちらかのリストを提供する必要があるかもしれません。

CSRF プロテクションを実装する

CSRF (Cross-Site Request Forgery) ログイン攻撃では、攻撃者がクロスサイトリクエストフォージェリを利用して、ユーザを攻撃者の資格情報を使った Web サイトにログインさせます。

例えば: ユーザが form 要素を含む悪意のある Web サイトを訪れたとします。この form の action 属性には、攻撃者のユーザ名とパスワードを含む https://www.google.com/login への HTTP POST リクエストがセットされています。ユーザが form を送信すると、リクエストが Google に送信され、Google サーバがユーザのブラウザに Cookie をセットします。これで、ユーザが知らないうちに、攻撃者の Google アカウントへのログインが成功してしまいます。

この攻撃は、ユーザの個人情報を集めるために使われます。例えば、Google の Web History 機能は、ユーザによるすべての Google 検索の検索語を記録します。ユーザが攻撃者の Google アカウントにログインし、攻撃者が Web History 機能を有効にすると、ユーザはこれらすべての情報を攻撃者に与えることになります。

CSRF ログイン攻撃とその防御手段は、Robust Defenses for Cross-Site Request Forgery (PDF) に詳しく解説されています。これらは Persona に限ったことではありません。ほとんどのログイン機構は、このような攻撃への潜在的な脆弱性を持っています。

CSRF ログイン攻撃からサイトを護るために使える手段には、様々なテクニックがあります。上記のドキュメントを参照してください。

取り得るアプローチ方法の一つは、サーバ内に秘密の ID を作成してブラウザと共有し、ログインリクエストを行う時にそれをブラウザから提供してもらうことです。例えば:

ユーザがサイトを訪れたらすぐに (ログインする前に) ユーザのセッションをサーバ上に作成し、セッション ID をブラウザの Cookie に格納します。
サーバ上で 10 文字以上のランダムな英数字の文字列を生成します。UUID をランダムに生成するとよいでしょう。これは CSRF トークンです。このトークンをセッションに格納します。
CSRF トークンを JavaScript や HTML 内の隠し form 変数に埋め込むことによってブラウザに渡します。
AJAX サブミッションや form の POST に CSRF トークンに含めてください。
サーバ側では、アサーションを受け取る前に、送信された CSRF トークンがセッションに格納された CSRF トークンと一致するか確認します。

さらなる向上

コンテントセキュリティポリシー (CSP)

コンテントセキュリティポリシー (CSP) は、クロスサイトスクリプティング (XSS) やデータインジェクション攻撃を含む、特定の攻撃の検出と軽減を助けるセキュリティの追加レイヤーです。これらの攻撃は、データの盗難からサイトの破壊、マルウェアの拡散まで、すべての攻撃に使われます。

あなたのサイトで CSP を使う場合は、サイトポリシーで Persona を有効にする必要があるでしょう。あなたのポリシーに依存しますが、次のことが必要です:

インラインの javascript: URI を削除し、追加のスクリプトファイルから読み込んだコードに置き換えてください。このスクリプトファイルでは、対象の要素をその ID を基に見つけ、onclick を設定するか、addEventListener() を呼び出すことにより、要素にスクリプトを結び付けます。
https://login.persona.org に script-src と frame-src の両方を許可し、あなたのサイトがリモートの include.js ファイルを読み込んでフォールバックの Persona 実装と通信できるようにしてください。

Apache コンフィギュレーションには、次の行を含めることになるでしょう:

Header set X-Content-Security-Policy: "default-src 'self'; frame-src 'self' https://login.persona.org ; script-src 'self' https://login.persona.org"