RailsのCookieStoreの脆弱性についていくつか報告記事が出ていたので、内容を検討してみました。

Ruby on Railsにcookie保存関連の脆弱性、2000サイトで放置状態
http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html

Rails SessionにCookieStore使った時の問題点
http://oauth.jp/blog/2013/09/26/rails-session-cookie/

読み合わせていくと、以下のような問題があるようです。

  • Cookieの情報が抜かれることによって、セッションをハイジャックされる可能性がある
    • Rails 2系にはXSS脆弱性からCookieの情報が抜かれる可能性がある
    • Rails 3/4系でもCookieが盗聴される場合は危険
  • セッションをサーバーサイドで管理していないことに問題がある

詳しく見ていきましょう。

このためクロスサイトスクリプティング(XSS)などの攻撃を仕掛けられて情報を盗まれた場合、ユーザーのログイン情報が悪用される恐れがあるという。

http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html


Rails 4より前のCookieStoreは署名を使った改ざん防止は入っていますが、Cookieそのものは平文で保存されています。

XSSでCookieの情報が抜かれる脆弱性は、CookieのHttpOnly属性が有効になっていなかったRails 2系にはあったように思います。(昔の話なので自信がありませんが。。。)
Rails 3系ではHttpOnly属性が有効になっているので、XSS脆弱性だけで抜かれる可能性は低いです。

Rails 4では暗号化されているので、こういった危険性はさらに低くなります。ただし・・・

しかしマクナマラ氏はThreatpostに対し、「バージョン4.0以降にも問題は存在する。攻撃者が暗号化されたcookieをサーバに送信すれば、cookieのコンテンツを解読しなくても被害者になりすましてログインできる」とコメントしている。

http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html


このように書かれている通り、Cookieを盗聴されると内容が暗号化されていてもセッションハイジャックされる可能性があります。

マクナマラ氏は解決策として、セッション情報がクライアントサイドではなくサーバサイドに保存されるcookie保存のメカニズム使用に切り替えるよう促している。

http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html


これは少し言葉足らずに思いました。

例えば、MemcacheStoreを使ったとしても、Session IDをクライアントに置く以上、同様の問題があるはずで、MemcacheStoreに切り替えたからはい安心という種類の問題ではありません。(いや、おそらく大元ではそういう認識で話していないでしょうが。)

本質的な問題点については、以下の記事が詳しいです。

Rails SessionにCookieStore使った時の問題点
http://oauth.jp/blog/2013/09/26/rails-session-cookie/

  • サーバーサイドでセッション管理していないと、セッションがユーザーやセキュリティ上の意図を超えて有効になってしまう恐れがある
    • (a) 例えば、パスワードが漏れて変更した場合など、そのアカウントに紐づく全てのセッションが削除されるべき(少なくともパスワード入力を要求すべき)状況で対処することができない
    • (b) ユーザーがログアウトしても、ログイン中のCookieを保持していることによって、ログアウトしたはずのセッションでログイン状態を保持することが可能になってしまう
  • SSLを使うことは盗聴防止には有効でも、Cookieが漏えいしてしまえば同じ問題が発生しうる

例えば、MemcacheStoreを使う場合、上記の(b)の問題はMemcachedからセッション情報を削除することで回避できます。(a)の問題は自動的には回避できません。ただ、サーバーサイドでセッション管理をするようになれば、回避するように実装することはできるでしょう。

CookieStoreだと難しいかもしれません。上記の記事でもふれられていますが、署名や署名の検証にアカウントや有効期限に紐づいた情報を含めることで対処する方法はあるかもしれません。

いずれにせよセキュリティとコストはトレードオフだと思うので、問題点を認識した上で運営しているサービスに応じた実装を進めていくのがいいかと思います。

不完全とはいえ、Railsのバージョンが進むごとにセキュリティ対策も進んでいくので、極力、最新に近づける努力はした方がいいですね。

■ 余談

マクナマラ氏はこの問題への対応状況を調べるため、9万サイトについて追跡調査を実施し、その結果を11月20日のブログで報告した。それによると、ユーザーの情報が暗号化されない古いバージョンのRuby on Railsをいまだに使っているサイトが1897件見つかったという。

http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html


90000サイトを調べて、古いバージョンが1897件というのは少ないように思います。
体感的にはもっと危険なサイトがありそうなのですが・・・。母数にはRailsじゃないサイトも含まれているのでしょうか。。。

Posted by あかさた
最近のエントリ
最近の読書メモ