第1回神泉セキュリティ勉強会 : ATND
ほんとは普通にリスナーとして参加予定だったのですが、ひょんなことからLTすることになりました(^^;
そのあたりの経緯はスライドをみていただくとして、発表資料を晒します。
【2011/01/18 追記】
SoftBankのSSL仕様変更の件、当初2011年2月とアナウンスされていましたが、2011年6月に延期されました。
詳しくは下記SoftBankのページを参照下さい。
http://mb.softbank.jp/mb/information/details/101015.html
5分間のLTなのに、スライド60枚という無謀なボリュームｗ
脳内リハーサルでは5分ギリギリだったんですが、やはりちょっとオーバー（しかも一部端折ったのに）してしまい。。。
まぁでもある意味一番LTらしかったかと（爆）
で、とにかくですね、他のスピーカーの方々は、こういった発表の猛者たちばかりで、実際前半の発表を見ていてかなりプレッシャーあったんですね。
僕のスライドは見てくれもあまり整える余裕なかったので・・・
でも、そこはもう居直って（笑）
勝てないところは勝てない。
なので、ネタの鮮度と笑いを取ることで勝負だ、と思ってましたｗ
反応を見た感じでは、とりあえず、その狙いは一定達成はできたかなと。
LTとか発表自体、すごい久しぶりで、たぶん1年以上やってなかったんでかなり緊張しました。
handsoutの昔のLTスライドみたら、なんかめっちゃ恥ずかしくなってしまったｗ
内容について、時間が無くて端折ってしまった部分、ちょっと補足を。
SoftBankのSSL仕様変更で、注意ポイントのところで、「文字コード変換」というのがあります。
実はSoftBankの中間サーバでは、特定のケースで文字コード変換をすることがあります。
それは、出力するHTMLの文字コードが「EUC」または「ISO-2022-JP」の時で
かつ、そのHTMLから送出されるGET/POSTパラメータが、中間ゲートウェイでSJISに変換される、という仕様があり、これが2011年2月の仕様変更で動作が変わります。
中間ゲートウェイを経由しないので、それぞれの文字コード「EUC」「ISO-2022-JP」でGET/POSTパラメータがサーバ側に渡ることになります。
SJISが来ると思ってたところにEUC、またはISO-2022-JPが来てしまう・・・というあたりで、何かXSS的なことが出来てしまわないか？と考えたのですが
文字コード表とにらめっこして、結果、たぶんそれはないかな・・・と。
ただいかんせんあまり時間取れなくて、ここはちょっと確証が持てないところなので、こうすればXSSできる、というのがあれば教えていただけると嬉しいです。
まあ、XSSの可能性が仮になかったとしても、この場合まず間違いなく文字化けするので（笑）どっちにしろ対策は必要ですけどね。
あと、これもセキュリティには関係ないですが、SoftBankの昔の形式の絵文字指定が（SSL保護下では）使えなくなります。
古い携帯サイトではこれが結構痛いかもですね。
もっとも、SSL以下のコンテンツで、そんなにガツガツ絵文字使うケースは無い気がしますが。
あ・・・でも、確か昔の絵文字指定文字列の中に、<とか>でてこなかったっけ？
・・・もしかしたらなんかやばいケースがあり得るかも。
わかったらまたこのブログで書きますね。
あと、最後におまけで付け足した、かんたんログインの件。
原則としては、徳丸さん、高木さんの言の通り、「いい加減Cookieでやれや」の一言で終わりだと思います。
ただ、「障壁」のところでも書いていますが、特にDoCoMoのCookie非対応機種が、シェア的にまだ無視できない、というのが辛いところです。
かといって、GETパラメータでセッションID引き回すのは、それはそれで嫌ですよね・・・個体識別IDよりはましでしょうけど・・・
懇親会の席で、半分冗談で、いっそIPAが「かんたんログイン」と「DoCoMoのCookie非対応端末」を脆弱性として認定してくれないか、とか言ったんですが・・・そのくらい強制力ほしいですよね。実際。
もっと過激に、法律で縛れ、みたいな話もありましたけど。IT業界にも「建築基準法」的な物がいるんじゃないかと。
問題は、国会議員の方々にこのあたりの事情を理解できる方がほとんどいないのでは？というところですねぇ。。。
それから、他の素晴らしいスピーカーの方々の発表について
きっとどなたかが既にまとめブログを書いてくれるものと期待して、僕は感想を少しだけ。
■HASHコンサルティング 徳丸浩さん
「文字コードに起因する脆弱性とその対策」
自分はPHPカンファレンスも行ったので、概ね内容は知っていたのですが
ほんとに文字コード周りはいろいろやっかいですよね。。。
最後の方の推奨実装として、入力・スクリプトのエンコード・DBのエンコード・出力全てをUTF-8に統一、とあって、それは僕も大賛成なのですが
ここでもやはり携帯はネックなんですよね。。。
Auが公式にはUTF-8をサポートしてない*1のと
DoCoMoで一部の記号が出力できないという問題があるのです。
なので、自分がやっているプロジェクトでは
入り口(GET/POSTパラメータなど)と出力のみ、DoCoMoとAuではSJISに変換しています（SoftBankはUTF-8でOK）*2
このあたりの事情も含め、携帯向けの php.iniの「比較的ましな」設定もあるといいなと思いました*3
■サイボウズラボ 竹迫良範さん
プログラムを騙す10の方法 – シグネチャマッチを回避する攻撃と防御
これは・・・すごい・・・
いや、gif画像へのスクリプト埋め込みはなんとなく知ってはいたんですが、実際にこういう形で見せられると、ちょっと衝撃的でした。
後半の記号プログラミングとか・・・神業としか思えませんｗ
確かに、自分の職を守るにはいいかもｗｗｗ
■サイボウズラボ 奥一穂さん
XSSに強いウェブサイトを作る – テンプレートエンジンの選定基準とスニペットの生成手法
いきなり冒頭で「Smartyのdefault modifierはあんま使われてない」ってありましたが、うちでは使ってます（笑）
Smartyを使いたいって要求はいまだに多いんですよ。特にデザイナーからの要望で。
でも、デザイナーにちゃんとエスケープの修飾子書け、って言っても、絶対どこか抜けるんですよ。
なので、致し方無しで使ってます。
こうすると、foreachのところでもいちいち smarty:nodefaults しないといけないので面倒なんですが、セキュリティには変えられないので。
しかし、Smarty3では自動エスケープ採用されてるとのことなので
今後はもう少しこの辺改善されるのかな。
■ECナビ春山さん
パスワード保存の常識(？)
正直ちょっと難しかった。。。
stretchも知りませんでした。いや、なんとなくそんなことやってるみたいな話は聞いたことはあったんですが、ちゃんとは知らなかった。
世間的には、この勉強会の直後にちょいとトレンドがきちゃいましたねｗ
もっと低次元な話ですが。。。
でも、(もちろん誰も公然とは言いませんが)パスワードをmd5()ソルト無しで保存とか、平文保存もいまだにあると思うので
このあたり、「本来こうすべき」という指針があるべきかな、と思ってます。
あと、春山さんの発表とは関係ないですが、「かんたんログイン」周りの話題で、PCサイトにある「次回から自動的にログイン」も意外と実装の仕方のセオリーってあまり知られてないんじゃないかなぁ、と思ったり。
■LT ikeda.yurikoさん
Wordpressのセキュリティ周りの話
PHPのセッション実装を一切使っていない、というのが衝撃でした。
そのあたり、どうしてそうしたのか？という理由が知りたいですね。
■LT ikepyonさん
脆弱性診断ツールの話
まぁ早い話「銀の弾丸は無い」ってことですよね。
そんなのちょっと考えればわかるだろ、と、変な期待してる輩には小一時間説教したいところですが。。。
ただ、ビジネス的に担保がほしくて、こういうツール使う、ってのはあるんだろうなぁ・・・
そして（意外にこれがあると思うんですが）万一脆弱性が発覚したときに、責任転嫁の矛先にしたいがために。
だからこそ、こういうツール導入の時は、「何が出来ないか」を始めにきちんと説明する必要がありますよね。
LASDECのWeb健康診断は知りませんでした。
こんどちょっと調べてみたいと思います。
最後に、会場提供のECナビ様、主催者の春山さん、ありがとうございました。
