悪意のある攻撃から身を守るには？

nonce：リプレイ攻撃に対する対処方法

　第2回の最後で少し紹介しましたが、セキュリティーの大事な考え方の1つにnonce（ノンス）というものがあります。nonceとは、number used onceの略で、1回だけ使われる番号という意味です。ワンタイムトークンと呼ばれることもあります。

　トークンというのは、文字の並びという意味で、セッションIDを使ったセッショントークンなどは、一般的な認証やフォームを使ったやりとりに幅広く利用されています。

　ご存じのとおり、サーバーのリクエストは常にブラウザを使って人間が行うとは限りません。telnetを使ったり、プログラムを使うことによって、POSTやGETなどのHTTPリクエストができます。それは、悪意あるユーザーにとってみれば、強力な武器になり、例えば3秒ごとに認証を試みるといったことも、もちろん可能になります。

　よって、セッションをベースとしたトークを使うことで、そのリクエストが同じセッションからのものであれば、リクエストを一定時間は受け付けない、という回避策をとることができます。

　一方、nonceは1回だけ使われるワンタイムトークンですから、基本的には、同じリクエストが続けて来たら怪しいということになります。つまり、リプレイ攻撃のように正しいユーザーになりすましして訪問してきた悪意あるユーザーを見破るためにあるのです。

　いずれにせよ、問題は悪意あるユーザーと正しいユーザーのリクエストが混在していることです。いかに正しいユーザーのリクエストにはきちんと応答し、そうでないユーザーのリクエストをはねつけるかということがポイントです。

　OpenIDの場合には、第三者であるOP（OpenID発行サイト）に行って、また戻ってくるわけですから、1回だけ使えるトークンを発行して、同じトークンを持ったユーザーが次に来たらはねる、というnonceの考え方は、本当にそれが正しいユーザーかを確認するために有効です。

　具体的な処理を説明しましょう。まず、OPから認証を受けてPR（ユーザーが利用したいサービス）に戻ってきた際に、DBに保存しているこれまで受け取ったnonceの中に同じものがないかどうかを確認します。この時、同じnonceが存在していれば怪しいユーザー、また存在していない場合でも、nonceの発行時刻が現在時刻と比べてかい離していれば怪しいユーザーとして拒否します。nonceにこうした問題がなければ、OPにおいて正しく認証されて戻ってきたユーザーと判断できますので、次のステップに進ませます。

　なお、OpenID 2.0の仕様に、nonceだけでなくOPから受け取った値をどういう視点でチェックするのが正しいのかが書かれていますので、参考にしてみてください。

・openid.return_to（もともとPRが指定していたOPから戻ってきた場合のURL）の値がリクエストされたURLと一致するかどうか
・ディスカバリー時に得たOPの情報と一致するか
・同じ値のnonceを受け取っていないか
・署名が正しく十分なものであるかどうか

アソシエーションとセキュリティー

　これまで説明した内容は、仕様上はユーザーエージェントを介したPRとOPでの間接的なコミュニケーションの部類に入ります。実は、この処理のほかにPRとOPの間に間接的ではない直接的なコミュニケーションもあります。

　第1回、第2回の中で、OpenIDの処理を駐車場の入り口の係員と車の例えを使って説明しました。その中で、係員が車を誘導する前にAゲートに対して電話をかけるという手順がありました。つまり、これはユーザーをOPにリダイレクトする前に、PRとOPが直接通信することでOPとPRの間で信頼関係を築いているのです。

　これが、「アソシエーション（association）」と呼ばれている処理で、日本語ではよく「関連付け」と訳されています。

　このアソシエーションという概念は、Web上で見つけられる用語説明や技術的な説明だけを読んでもよくわかりにくいので、なるべく平たい言葉で説明してみましょう。

　アソシエーションというのは「PRとOPだけが知っている秘密の呪文（じゅもん）を持つ」ということと言ってよいでしょう。メッセージのやりとりをする場合に、この秘密の呪文をかけて作ったコードを署名としてつけておくことによって、お互いに正しい相手をやりとりをしているということがわかるのです。

　そして、この秘密の呪文をかけて作った署名のことを、MAC（Message Authentication Code）キーと言います。では、このMACキーはどのように作られるでしょうか。次ページで紹介しましょう。