Webアプリの入力はバリデーションできない、という誤解 »

RailsのJavaScript文字列エスケープ

RailsはJavaScript文字列エスケープメソッドをサポートしています。JavaScript文字列エスケープのエントリで様々な議論があったようです。弊社ではRailsアプリのソースコードも検査しているので、参考としてRailsのソースコードを確認したことを追記をしたました。Rails開発者に直して頂きたいので独立したエントリにしました。

参考：

結論から言うとRailsのJavaScript文字列エスケープメソッドには問題があります。問題点の指摘の前にどのようなコードになっているかを見てみます。


module ActionView
  module Helpers
    module JavaScriptHelper
      JS_ESCAPE_MAP = {
        '\\'    => '\\\\',
        '</'    => '<\/',
        "\r\n"  => '\n',
        "\n"    => '\n',
        "\r"    => '\n',
        '"'     => '\\"',
        "'"     => "\\'"
      }

      JS_ESCAPE_MAP["\342\200\250".force_encoding(Encoding::UTF_8).encode!] = '
'
      JS_ESCAPE_MAP["\342\200\251".force_encoding(Encoding::UTF_8).encode!] = '
'

      # Escapes carriage returns and single and double quotes for JavaScript segments.
      #
      # Also available through the alias j(). This is particularly helpful in JavaScript
      # responses, like:
      #
      #   $('some_element').replaceWith('<%=j render 'some/element_template' %>');
      def escape_javascript(javascript)
        if javascript
          result = javascript.gsub(/(\\|<\/|\r\n|\342\200\250|\342\200\251|[\n\r"'])/u) {|match| JS_ESCAPE_MAP[match] }
          javascript.html_safe? ? result.html_safe : result
        else
          ''
        end
      end

      alias_method :j, :escape_javascript

参考：GitHubのソース

処理している事は難しい事ではありませんが、私のブログを読んでいる方はRubyに慣れてない方も多いと思うので簡単に解説します。


      def escape_javascript(javascript)
        if javascript
          result = javascript.gsub(/(\\|<\/|\r\n|\342\200\250|\342\200\251|[\n\r"'])/u) {|match| JS_ESCAPE_MAP[match] }
          javascript.html_safe? ? result.html_safe : result
        else
          ''
        end
      end

がJavaScript文字列をエスケープするメソッドで


          result = javascript.gsub(/(\\|<\/|\r\n|\342\200\250|\342\200\251|[\n\r"'])/u) {|match| JS_ESCAPE_MAP[match] }

正規表現にマッチした文字をJS_ESCAPE_MAPで定義したマップに変換しています。つまり、以下のマップ定義に従って文字が置換されます。


      JS_ESCAPE_MAP = {
        '\\'    => '\\\\',
        '</'    => '<\/',
        "\r\n"  => '\n',
        "\n"    => '\n',
        "\r"    => '\n',
        '"'     => '\\"',
        "'"     => "\\'"
      }

      JS_ESCAPE_MAP["\342\200\250".force_encoding(Encoding::UTF_8).encode!] = '
'
      JS_ESCAPE_MAP["\342\200\251".force_encoding(Encoding::UTF_8).encode!] = '
'

ECMAScriptの仕様書にある\エスケープ（JavaScript仕様通りのエスケープ）によって特殊文字をエスケープし、Unicodeのページセパレータ文字の2文字をHTML文字参照に変換しています。（&#x2028; と &#x2029;）

このJavaScript文字列エスケープメソッドには問題が幾つかあります。

  • '</' => '<\/',と変換しているがECMAScript仕様には / -> \/ のエスケープは未定義
  • Unicodeページセパレータ文字を '
' '
' に変換しているが、これはHTMLのエスケープ仕様
  • '</' => '<\/',変換で<script>タグから抜け出る事を防止
  • HTMLタグが文字列中に現れる事に未対応
  • " や ' が誤ってHTML属性としてマッチしてしまう事に未対応
  • 古いブラウザに存在したサニタイズを利用する攻撃に未対応
  • HEXエスケープでなく、\エスケープを利用している

順番に解説します。

まず現在のJavaScriptが対応しているECMAScriptの仕様書にない'</' => '<\/',エスケープですが、実際には動作します。

V8のd8コマンドの実行例


[yohgaki@dev ~]$ d8
V8 version 3.14.5.10 [console: readline]
d8> write("<\/\n");
</
d8>

ECMAScriptの仕様書にはこのエスケープは記載されていません。しかし、JavaScriptの歴史はECMAScriptの仕様から始まったのではなくNetScapeのLiveScriptとして90年代なかばに開発された歴史があります。恐らくこのエスケープ動作は歴史的な理由から現在もサポートされていると思われます。恐らくECMAScript 5.1をサポートする実装のほとんどがこのエスケープをサポートしているので今は問題ないだろう、と考えられます。

しかし、JavaScriptは \ エスケープのみでなくHEXとUnicodeエスケープもサポートしています。HEXまたはUnicodeエスケープを行えば仕様書通りのエスケープが行えます。非標準のエスケープ方法を用いる意味はありません。

次にHTML文字参照に変換している点です。HTML中に記載されたJavaScriptのコードはまずHTMLパーサーによってパースされ、パースされたコンテンツはHTMLエスケープをデコード後に次の処理系に渡されます。つまり、JavaScriptに渡された時にはHTML文字参照はUnicodeに変換されています。JavaScript文字列エスケープ関数でHTML文字参照に変換する意味がありません。

また、JavaScript文字列の中にHTML文字参照があってもJavaScriptはデコードしません。つまり、Railsのjavascriptメソッドでエスケープしてしまうと、JavaScriptパーサーだけでパースされる場合には不正な文字列を生成する可能性があります。Unicodeをエスケープしたい場合はJavaScriptのUnicodeエスケープ記法（\uXXXX）を利用すべきです。

'</' => '<\/',変換する事で<script>タグから抜け出れないようにしている点です。ブラウザやHTMLコードにバグ（次の” ’の取り扱い参照）などが無ければ、非標準の'/' => '</',がデコードされる仕様によって一応の安全性は保たれています。しかし、堅牢なコードと評価する事は難しいです。

このエスケープメソッドではHTMLタグが出現する事を防止していません。HTMLタグがHTMLパーサーによって解釈されないようにする為、HTMLコンテンツ中ではタグとなる文字列は現れるべきではありません。これを防ぐ為には少なくとも < と > はHEXエスケープします。

" や ' が誤ってHTML属性値としてマッチしてしまう事に未対応である点です。こんな事をやる方がそもそも悪い！という意見があると思いますが、HTMLタグの属性値をクオートで囲まないユーザも居ます。分ってはいてもクオートを忘れてしまった場合やHTMLパーサーのバグの場合もあるでしょう。その様な場合、” や ’ がHTMLタグの属性値としてマッチしてしまう可能性があります。マッチしてしまった場合、< > をエスケープしていないRailsのメソッドでは、JavaScriptインジェクションが可能になります。

古いブラウザには特殊文字やアスキーコードの上位バイトをサニタイズ（オクテットのMSBが1の場合に削除）する仕様がありました。現在のブラウザではこのような仕様は無いとは思いますが、ブラウザの実装はWeb開発者には制御できません。新しいブラウザでこのような実装をしてしまう物が出てこないとも限りません。リスク低減の為に特殊文字など、誤解釈される可能性のある文字は全てHEXエスケープする方がより安全です。

最後にHEXエスケープでなく\エスケープを利用している点です。ここまでで\エスケープでなくHEXエスケープを用いた方が良いことは何度か解説したので既に理解されてると思います。HEXエスケープを用いればJavaScriptの特殊文字（n r v bなど）だけでなく、HTMLの特殊文字（< > ' " &など） がHTMLパーサーに誤解釈されないようにエスケープできます。JavaScript仕様では非標準のエスケープを行う必要もありません。

まとめると

  • 取り敢えずは危険ではないのでjavascriptメソッドは使っても大丈夫
  • 大丈夫であってもjavascriptメソッドは堅牢でなく、標準準拠でもない
  • javascriptメソッドはJavaScriptだけのコード用に使うと不正な文字列を生成する場合がある（あまり無いですが）
  • JavaScript文字列のエスケープの様なエスケープの方が堅牢

と言うことになります。ブラウザに対して間違いないHTMLを出力してる場合には、大問題だと慌てる必要はありません。しかし、ブラウザのバグの場合、JavaScriptインジェクションできたのはブラウザの責任と言えます。しかし、「セキュリティ専門家が推奨するHTML/JavaScript標準に準拠したエスケープ方法を用いなかったのでJavaScriptインジェクションできましたが、これはブラウザのバグです」ではクライアントやユーザーは納得しないと思います。これは直した方が良いと思います。

Rails開発に近い方、直して頂けると有難いです。

追記：
HTML文字参照にエスケープしてしまうバグは 出力先のシステムが同じでも、出力先が異なる、を意識する を実践していれば防げたバグだと思います。

浸透しているので直ぐにJavaScriptがサポートを無くす事はないと思いますが、もし<\/が使えなくなってもECMAScript 5.1非標準なので厳しい言い訳に。ところでECMAScript 3の頃は\123で8進数エスケープが出来たのですが5.1には無いです。HEXがあるから要らないということでしょうか。

V8 implements ECMAScript as specified in ECMA-262, 5th edition, and runs on Windows (XP or newer), Mac OS X (10.5 or newer), and Linux systems that use IA-32, x64, or ARM processors.

https://code.google.com/p/v8/

ということですが、一応手元のd8ではこのエスケープ方法も動作します。

このエントリがポストされているのは 11月 7th, 2013 09:15:00 and is filed under 雑文, Security, Ruby, PHP Security  永続的リンク

このエントリーをはてなブックマークに追加