OpenIDに仕掛けられやすい5つの攻撃
セキュリティーから見たOpenIDの危険性
第1回は、OpenIDが注目される背景や理由、そして基本的な認証の流れについてみていきました。では、OpenIDをセキュリティーという観点で見た場合のポイントはどこにあるでしょうか。
通常、Webの開発を行う場合、ある程度セキュリティーを考慮しながらプログラミングします。しかし、開発の状況によってはセキュリティーのチェックがついつい後回しになったり、抜けモレなどが発生することがあるのではないでしょうか。
今回は、少しでもセキュリティーを意識しながら開発することができるように、なるべく平たい言葉でセキュリティーの課題について説明します。ここで、OpenIDの認証の流れを再確認するために、第1回での例えを使ってもう一度見てみましょう。
スモークガラスの車が、駐車場の入り口に入ってくる。車の中から係員に話しかける。
「駐車場を利用したいんだけど」
「通行証を見せて」
「Aの通行証でも大丈夫だよね」
「大丈夫だよ。じゃあ、Aのゲートがあるからそこで許可とってきて。案内するから」
「わかった」
係員は、Aゲートに電話してから、Aゲートの場所まで車を誘導し、車はそのままAゲートに入っていく。
Aゲートの中はよく見ないが、Aゲートの中にも係員がいて、通行証の確認をしているのだろう。そのAゲートの中から程なく車が出てきて、また元の入り口にいる係員のところに戻ってきた。車の中からまた係員に話しかける。
「AゲートでOKもらったよ。証拠もあるよ」
「それならオッケーだ。中に入っていいよ」
「じゃあ、遠慮なく」
スモークガラスの車、駐車場、係員の例えを使った説明はここまでです。
上記のたとえでは、まずスモークガラスの車が駐車場に入ってきて、入り口の係員に話しかけますが、もし大量の車が一気に何度も来たらどうでしょうか。入り口は満杯になり、ほかの車が入ってこられない状態になることは容易に想像がつきます。また、Aゲートに大量に車が押し寄せたらどうでしょうか。
これは、いわゆる「サービス拒否攻撃」と呼ばれます。
言葉は悪いですが、よってたかってサービスを利用することによって、ほかの人の利用をできないようにするという嫌がらせに近い攻撃です。実際には、この攻撃にはあまり対処の方法がありませんが、入り口やAゲートに入る車の数を減らしたり、間隔を設けるといった対処が必要となります。
しかし悪意のない善良なユーザーを拒否してしまっては、元も子もありませんから、あやしい車を識別して対処しなければなりません。具体的には、ログからあやしい挙動をしているIPを調べ、そのIPのアクセスを制限します。
入り口の係員が別のゲートに誘導する：フィッシング
次に考えられるのは、入り口の係員が悪人の場合です。これは3つの攻撃方法が考えられます。
まず1つ目は、係員はやさしい顔をして、Aのゲートまで連れて行くように見せかけて、Aゲートと見た目がそっくりのA'ゲートに案内する方法です。ユーザーは、それがAゲートだと信じて疑わないので、A'ゲートで認証を行います。つまり、自分のIDやパスワードを入力してしまうのです。ひどい場合には、もっといろいろな情報を要求されて、入力してしまうかもしれません。大事なIDとパスワードを取られるだけでなく、身ぐるみはがされてしまう危険性があるのです。
これが、いわゆる「フィッシング（phishing）」と呼ばれる攻撃です。
OpenIDの利用サービスは、OP（OpenID発行サイト）に認証をゆだねるため、必ず自分のサイトからOPへのリダイレクトを行います。ユーザーは、基本的に「見た目」でそのリダイレクト先を信用するので、ロゴや画面デザインが見慣れていればOpenIDを取得したサイトだと認識してしまう可能性があるのです。
ブラウザからソースを自由に表示できるので、ロゴやデザインをまねたそっくりのサイトを作るのは簡単です。つまり「見た目」はすぐにまねできてしまうのです。
ユーザーの立場からすると、そうしたフィッシングにひっかからないためには、信用できる利用サービスを使うことや、リダイレクト先のURLを見て判断することが挙げられるでしょう。
OP側も基本的にどこからリダイレクトされてきたのか、これからどこにリダイレクトするのかといった情報をきちんと開示していますので、そうした情報をチェックすることも必要です。yahoo.co.jpでは、認証する際にそれがフィッシングページではないことを証明するログインシールをつけることを推奨しています。
OpenIDのセキュリティーが語られる場合は、大抵このフィッシングが最初に取り上げられます。それは認証のためにOPにリダイレクトするというその仕様が、OpenIDの本質と切っては切り離せないためです。
続いて、ほかの攻撃についてみてみましょう。
弱みに付け込む：クロスサイトリクエストフォージェリ
次に、入り口の係員が他人の弱みに付け込むような悪人だった場合です。入り口に入ってきた車をだまして、Aゲートではなく、別のところに連れて行くだけでなく、ユーザーに意識させずに何かを実行させてしまうのです。
これが「クロスサイトリクエストフォージェリ（Cross-Site Request Forgery）」です。
Forgeryというのは、聞きなれない英語ですが、偽造／捏造（ねつぞう）を意味します。よって、直訳すると、サイトをまたいだリクエスト偽造、といった意味になります。サイトをまたいでリクエストを偽造するというのは、一体どういうことなのでしょうか。
サイト上に、データの書き込み、修正、削除などの機能を持たせる場合がありますが、基本的にこの処理はそのサイト上で行われることを意図していますし、通常は認証して身元を確認した上で行います。しかし、それを別のサイトからリクエストを行うように仕向けることが、サイトをまたいだリクエストの偽造、つまりクロスサイトリクエストフォージェリ（CSRF）です。
例えば、あるユーザーが知らず知らずにどこかのサイトの送信ボタンを押したら、そのターゲットがそのサイトではなく、どこか別のサイトの新規登録機能のプログラムを呼び、新規登録機能を実行させてしまうというようなことが意外に簡単です。
通常、その機能を利用する前に認証が要求されますが、もしユーザーが、そのサイトへのログイン状態を保持するように設定していたら、そのまま実行されてしまいます。こうした方法で、ユーザーが意図せずに、別のサイトに、コメントを書き込んだり、データを削除してしまうことがありうるのです。
この攻撃は、そのユーザーとサイト双方に被害があるので、なんとか防御したいところです。対処方法の1つとして、ログイン状態を保持しない、つまり、都度ログインを要求することが考えられますが、ユーザーの利便性が悪くなります。
ほかによく使われる方法として、当該サイトでコメント書き込みをする場合などにフォームの隠しフィールドの中に目印を埋め込んでおくことが挙げられます。ワンタイムトークンと呼ばれますが、認証情報やセッションIDなどから生成したユニークでまねの難しい文字列を生成して埋め込んでおくことによって、それが内部から来た正しいリクエストとそうでないリクエストを識別することができます。
また、別の方法としては、CAPCHAという読みにくい英数字を入力するようなステップを設けることも1つの方法です。ブログのコメントを入力する際などに見たことがあるかと思います。
さらに弱みに付け込む：クロスサイトスクリプティング
もう1つ他人の弱みに付け込む方法として有名なのが、「クロスサイトスクリプティング（Cross Site Scripting）」です。クロスサイトリクエストフォージェリーと同じようにクロスサイトという名前がついていますが、クロスサイトスクリプティング（XSS）は、サイトをまたいだ悪意あるスクリプティングのことを意味します。
スクリプティングですから、サーバーにアクセスするような機能を実行させるのではなく、Cookieを盗んだり、悪意あるページにリダイレクトするといった悪さを行います。すでに説明したようにCookieにはセッション情報が含まれる場合がありますし、サイトによっては、より機密性の高い情報を含んでいる場合があるため、防御が必要です。
具体的な攻撃の手法としては、アプリケーションの不備を突きます。つまりそのアプリケーションが入力されたjavascriptを、そのまま出力するようにしていると、その出力結果とともに悪意のあるjavascriptが実行されてしまいます。そして、javascriptによってCookieを読むことができるので、画像のリクエストにCookieを付加するなどしてそれを別のサーバーに送信します。簡単に書くと以下のような流れになります。
リンクをクリック → アプリケーションにjavascriptが渡される → そのまま出力される → avascriptが実行されCookieを取得する → 別サーバーに送信する
Cookieの値を取得することで、セッションの乗っ取りをしたり、ページ全体を置き換えることによりて偽のページを作り出してフィッシングをしたり、といったさらなる攻撃の機会を与えてしまうことになります。
対処するためには、アプリケーションの出力時にjavascriptを無効化すること（サニタイズ）が考えられます。
では、最後にもう1つの攻撃を見てみましょう。
同じ車で戻ってくる：リプレイ攻撃
さて次は、OPで認証された後を見ていきましょう。
もし、車が正しくAゲートから出てきて戻ってきたとしても、利用サービスから見ると、それがさっきのユーザーと同じかどうかがはっきりとはわかりません。
見た目が同じ車が出てきたとしても、そこに乗っているのは、本当にさっき乗っていたユーザーなのか、どこか途中で入れ変わって、悪人が車に乗り込んでいるのではないか、という問題が残るのです。スモークになっているので、よく顔が見ませんが、車は同じで、ナンバーも同じで、Aゲートの通行証も持っていれば、それが実際は、悪人が乗っているということがわかりません。もし利用サービス側がそういった悪人を識別できない場合は、悪人がもともとのユーザーのフリをして、サービスにログインしてしまうことになります。
では、悪人がどうやってその同じ車を調達するのでしょうか。1つの方法としては、Aゲートからできてきた車のナンバーや種類を見ていて、その車と同じ車で入り口に何食わぬ顔をして戻るというものです。
この攻撃は、いわゆる「リプレイ攻撃」と言います。
リプレイ攻撃というのは、あるユーザーのログイン時の通信を傍受して、取得したパスワードを使ってそのユーザーになりすまし、認証を試みることを言います。
こうした場合の対処方法として、はじめに入り口にやってきたときに、見ないようにひそかに車の陰に暗号シールを張っておいて、Aゲートから戻ってきたときにその暗号シールを確認するというものです。攻撃者は別の車に乗ってくるはずなので、そこで識別することができます。
技術的には、セッショントークンを発行して、Cookieなどに持たせるとともに、データベースにも保存しておきます。リダイレクト先から戻ってきたときにそのトークンが存在しているかどうかを確認するとともに、制限時間を設けることで、もし15分以内であれば、許可する、といった方法が考えられます。
次回は認証にかかわるセキュリティー
第2回では、OpenIDの認証プロセスに沿った形で「サービス拒否攻撃」「フィッシング」「クロスサイトリクエストフォージェリ」「クロスサイトスクリプティング」「リプレイ攻撃」の5つについて概念的に説明しました。具体的、技術的な解説はWeb上や本で数多く出ていますのでそちらを参考にしてみてください。
第3回は、そのほかの認証にかかわるセキュリティー関連のテーマについて概観したいと思います。
Think ITメルマガ会員登録受付中
他にもこの記事が読まれています
全文検索エンジンによるおすすめ記事
- これならわかる！OpenIDの仕組み
- セキュアなWebアプリケーションについて
- 診断の現場からの提言！Webサイトの脆弱性が潜む場所を知る
- 悪意のある攻撃から身を守るには？
- JPCERT/CC、バッファローのネットワーク機器に存在する脆弱性に関する注意喚起
- 日本トータルシステムが提供するグループウェア「GroupSession」に脆弱性、JPCERTが注意喚起
- 平成31年度 春期試験 午後Ⅰ問題対策① ―問1
- JPCERT/CC、NTT東日本および西日本の「ひかり電話ルータ」に存在する脆弱性について発表
- APIセキュリティのハードニング
- 注目のWebAuthnと公式より早いKeycloak最新動向を紹介！OSSセキュリティ技術の会 第5回勉強会