XSSに強いウェブサイトを作る – テンプレートエンジンの選定基準とスニペットの生成手法

XSSに強いウェブサイトを作る
テンプレートエンジンの選定基準とスニペットの生成手法
Cybozu Labs, Inc.
Kazuho Oku

テンプレートエンジンの進化
2010年10月26日 XSSに強いウェブサイトを作る - テンプレートエンジンの選定基準とスニペットの生成手法 2

従来のテンプレートエンジン
従来のテンプレート＝手動エスケープ
<?php echo htmlspecialchars($var) ?>
XSSの温床（エスケープ漏れ）

従来のテンプレートエンジン (2)
代替手法＝常にエスケープ
Smarty の default:modifiers 等
問題：２重にエスケープしてしまう
結局流行らなかった

自動エスケープの登場
基本は常にエスケープ
ただし、エスケープ済かどうかを型で判定
$var = '>_<';
<?= $var ?> => >_<
型情報があるから２重エスケープしない
$var = escape('>_<'); # エンコードしてHTML型に
<?= $var ?> => >_<

自動エスケープの登場 (2)
最近のテンプレートエンジンでは主流に
Django (Python; 2007)
Text::MicroTemplate (Perl; 2008)
Ruby on Rails 3 (2010)
Text::Xslate (Perl; 2010)
Smarty 3 (PHP; planned 2010)

自動エスケープの登場 (3)
2010年代は自動エスケープの時代です
XSSの心配が、ほぼゼロ
２重エスケープも発生しない
新規プロジェクトでは、自動エスケープ機能つきのテ
ンプレートエンジンを使いましょう

これで、もう安心…?

残念ながら、違います

テンプレートエンジンが解決しない問題
テンプレートエンジンは、テンプレートに文
字列を埋め込むための装置
ユーザーの入力からHTMLを生成するため
には使えない
例: Wiki記法

Twitter の XSS 事件を覚えていますか?
@の直後にある”がエスケープされないから、
タグの属性を閉じることができた ⇒ XSS
http://x.xx/@"style="color:pink"onmouseover=ale
rt(1)//"

XSS の温床＝間違った設計
Twitter純正のHTML化アルゴリズム
html = linkify_usernames(
linkify_urls(
linkify_hashtags(tweet)
)
)
問題点
HTML への変換を多重に行っている
リンクがリンク化されるのを防ぐための工夫で誤摩化す
結果として処理が複雑になり、検証が困難

解決策：設計からやりなおし

でも…
正しいコードを書くのって難しいよね?

正常動作 > バグ >> 超えられない壁 >> XSS
正しい設計は重要
from プログラミングの観点
XSS が起きにくい設計も重要
from セキュアコーディングの観点
XSS は直さないとヤバい
バグってても XSS が起きなければ優先度調整可能

Tweet の HTML 化問題を分割して考える
Tweet の HTML 化とは何か
まず Tweet (=構造化テキスト) をパースして
次にその構造をHTMLエンコードする処理(=型変換)
パースとエンコードに分割する理由は?
パース結果が間違っていてもエンコード処理が正しけ
れば XSS は発生しない
構造化テキストとは？
ここでは、@user やリンクなどの構造をもつテキストのこと
他の例: Wiki や、はてなダイアリーのマークアップ

パース処理の具体例
@foo Hello http://example.com/
⇩
[
[ ’user’ => ’foo’ ],
[ ’text’ => ’ Hello ’ ],
[ ’link’ => ’http://example.com/’ ],
]

エンコード処理の実装例
for my $element (@tweet_elements) {
my ($type, $data) = @$element;
if ($type eq 'user') {
$html .= sprintf(
'@<a href=”http://twitter.com/%s">%s</a>',
encode_entities($data),
);
} elsif ($type eq 'link') {
$html .= sprintf(
'<a href="%s">%s</a>',
);
…

重要なことなので、もう１回
エンコード処理が正しければ XSS 起きない
エンコード処理は簡単だったでしょ?
あとは、パース処理をどう書くか
間違えてもセキュリティホールにならないから安心♡
DOM ライクなアプローチ (データ構造を作ってからま
とめてエンコード) と SAX ライクなアプローチ (コール
バック・イベントベースでのエンコード)
続きはブログで…
http://developer.cybozu.co.jp/kazuho/2010/09/tw
itter-xss-f73.html

まとめ
バグがあってもいいから、セキュアなプログ
ラムを書こう
文字列の「型」を意識しよう
自動エスケープ対応のテンプレートエンジンを使おう
エンコード処理は、できるだけ最後に、まと
めて行うべき
cf. 「サニタイズ言うな」キャンペーン
レビューとテストが簡単に

参考資料
http://labs.cybozu.co.jp/blog/kazuho/arc
hives/2008/12/textmicrotemplate.php
http://codezine.jp/article/detail/5472
http://togetter.com/li/52475
http://github.com/mzsanford/twitter-
text-rb/
http://d.hatena.ne.jp/gnarl/20100922/12
85165197

XSSに強いウェブサイトを作る – テンプレートエンジンの選定基準とスニペットの生成手法

More Related Content

XSSに強いウェブサイトを作る – テンプレートエンジンの選定基準とスニペットの生成手法