2008年9月27日(土曜日)
第02回まっちゃ445勉強会
第02回まっちゃ445勉強会 (sites.google.com)にひっそりと参加してきました。スライドはそのうち公開されると思いますので、話の内容は端折ってポイントや感想だけメモ。
ライトニングトーク1: CVE-2008-1447を踏まえたDNS
バスの乗り継ぎで残念な思いをしたために遅刻しており、最初のライトニングトークはちゃんと聞けませんでした。申し訳なし……。orz
最後の最後しか聞けていないのですが、「ヤバイよね」「無理だよね」という話と理解して良いのですかね……。フォームに「本当にHTTPSですか、確認してください」と書くなどして、ユーザにリテラシを身につけさせるしか無いのではないか、という話が出ていたようです。
ライトニングトーク2: PHP4.4.9の現状 誰もが知っているPHP4.4.9の脆弱性
大垣さんのライトニングトーク。PHP4.4.9はダメだよねという話と、最新のPHPの脆弱性の話。
mt_srandって名前からしてメルセンヌ・ツイスタっぽいですが、メルセンヌ・ツイスタは暗号論的疑似乱数ではないので、十分なサンプルが得られれば生成される乱数を予測できます。これをパスワードを生成するのに使って良いものかどうか疑問ですが……そういえば、そもそも PHP には暗号に使えるような乱数が標準では用意されていないという話を聞いたことがあるような。
※あと、スライドの文字が読みづらかったです。白文字で、背景は基本的に青っぽい写真なのですが、一部に白っぽい部分があり……。
ライトニングトーク3: 自己流リバースチャレンジ!
ゆまのさんがリバースエンジニアリングチャレンジ (www.netagent.co.jp)に挑戦したお話。Webと関係ない話なのですが、面白かったです。
私はアセンブラはさっぱりなので、手法の良し悪しは分からないのですが……早いほうなんじゃないか、ということらしい。
ライトニングトーク4: WAFをググった話
正式名称失念。まっちゃだいふくさんのお話。
英語圏では「ワフ」とか言わないらしい?
言われてみれば、IIS の URLScan も WAF の一種ですね。当時は WAF なんて言葉は聞いたこともありませんでしたが。
WAF入門～原理、効果、限界～
徳丸さんのお話。実際の WAF 製品を使用してのデモなどもありました。
デモに使用されたのは JP-Secure の SiteGuard (www.jp-secure.com) で、お値段は178万円くらい。実は某社Y氏からの特別提供だそうで、シグネチャも某社が調整したものだというお話でした。
- 「'or」は通すが「'or A=A」は通さない
- 「"onload="aa」は通すが「"onload="aaaaa」は通さない
- 「z' DECLARE」は通すが「z' DECLARE--」は通さない。「z' DECLARE#」は通す
- 「../../../../」は通すが「../../../../etc/passwd」は通さない
とか。あと、ログからの学習によるホワイトリストの生成などもできるようです。
現実的なWAFモジュールの実装とその運用 - wafful.org の今後の展開
竹迫さんのお話。基本的には mod_wafful.c の紹介。
ワッフルの正しい綴りは waffle ですが、あえて wafful にしているとのこと。waffle を検索すると、18歳未満の人は見ないでくださいというサイトが先頭に出てくるという。
手軽にブラックリスト・ホワイトリストの定義ができて使いやすいっぽい。
パネルDISカッション
園田さん、竹迫さん、徳丸さん、大垣さんによるディスカッション。
竹迫さんって Namazu に関わっていらっしゃったのですね。振り返ってみると、「Re: Namazu v2.0.7 にクロスサイトスクリプティング脆弱性 (www.namazu.org)」などは竹迫さんの投稿ですね。
「情報セキュリティ早期警戒パートナーシップ」という名前の認知度は、やっぱり低い模様。利用者にも知られていないとか。
森博嗣のサイトMORI LOG ACADEMY (blog.mf-davinci.com)は、打ち出しのイラストが漫画家の羽海野チカ (ハチクロ (www.amazon.co.jp)
……本筋の話って何だったのでしたっけ。結局のところ、大垣さんの言う「ホワイトリスト」という用語が、徳丸さんの用語とは全く違うもののようだ……ということが明らかになったという事で良いのでしょうか。
懇親会
大垣さん、徳丸さん、竹迫さん、佐名木さんらが同席する「濃い席」に居合わせることができ、しかも後半は園田さんまで合流して盛り上がりました。出た話題をいくつかメモ。
- ホワイトリスト話。「出力時にホワイトリストで処理する」と言われると、「原則として全ての文字を数値文字参照で出力し、安全であることが明確な一部の文字だけを素通しする」という処理をイメージしますよ……。
- PHPみたいな感じでもっと堅牢な感じの言語はないのだろうかという話が出て、私が「ASP.NETは固いイメージがある」と言うと、割と同意してもらえました。検査員も .aspx だと萎えたりするそうな。園田さんが「Microsoft .NET Web アプリケーションセキュリティ (www.amazon.co.jp)
」をオススメしてくださいました。
- 脆弱性を直す気がない人っていますよね、という話。IPAが公表することは難しいようなので、発見者が公表するしかないか?
- 「第02回まっちゃ445勉強会」にコメントを書く
関連する話題: WAF / PHP / セキュリティ / まっちゃ445勉強会
文字符号化方式判定の優先順位
唐突に、ブラウザが文字符号化方式を判定する場合の優先順位についてメモ。この順序については、HTML 4.01 5.2.2 で規定されています。
To sum up, conforming user agents must observe the following priorities when determining a document's character encoding (from highest priority to lowest):
1. An HTTP "charset" parameter in a "Content-Type" field.
2. A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset".
3. The charset attribute set on an element that designates an external resource.
これは明確でしょう。HTTP応答ヘッダでの指定が優先、それがなければmeta要素の指定が参照され、それらがない場合に初めてリンク元のcharset属性が参照されます。"must observe the following priorities..." とあるので、この順番は必須遵守事項です。おまけに、6.9 にはこういう記述もあります。
User agents must follow the steps set out in the section on specifying character encodings in order to determine the character encoding of an external resource.
こちらも must です。前述の優先順位が守られていない場合、そのブラウザは HTML4.01 の仕様に適合していないことになります。
ところで、5.2.2 の続きにはこうあって……。
In addition to this list of priorities, the user agent may use heuristics and user settings. For example, many user agents use a heuristic to distinguish the various encodings used for Japanese text.
"In addition to this list of priorities" と言われても、上に足すのか下に足すのかは書かれていないという微妙な罠があります。ブラウザによる自動判別の優先度は不明としか言いようがありません。直感的には前述の3つより優先度が低くなるべきだと思うのですが、それは明確には規定されていないように思います。
- 前(古い): 2008年9月26日(Friday)のえび日記
- 次(新しい): 2008年9月28日(Sunday)のえび日記
