神泉セキュリティ勉強会第1回　に行ってきた

@tranqdogに誘われたので全力で行った。
以下、殴り書き。まとめてない上に間違ってる可能性もあるのでご注意を。

タイムテーブル
18:30 開場
19:00 挨拶
19:05 HASHコンサルティング徳丸浩様文字コードに起因する脆弱性とその対策
20:05 休憩
20:10 サイボウズラボ竹迫良範様プログラムを騙す10の方法 – シグネチャマッチを回避する攻撃と防御
20:40 サイボウズラボ奥一穂様 XSSに強いウェブサイトを作る – テンプレートエンジンの選定基準とスニペットの生成手法
20:50 ECナビ春山パスワード保存の常識(?)
21:00 休憩
21:05 LT @ikepyon さん, ikeda.yurikoさん, @m_noriiさん
21:20ごろ勉強会終了. 懇親会開始

こんな感じで約3時間。

文字コード 脆弱性

文字コード超入門
文字コード　＝　文字集合＋文字エンコーディング
符号化文字集合とは、集めた文字に符号(番号）を付けたもの
文字エンコーディング：文字集合を使ってコンピュータ処理するために、文字をバイト列として表現する方法。文字集合は複数でも良い。

どちらが原因か区別する必要がある

セキュリティにおいては重箱の隅が重要
文字集合を変更すると、一対一対応でない箇所で文字化けなどの原因になる
Unicodeのバックスラッシュや\がマイクロソフト標準キャラクタセットだと同じ\として扱われる

・文字エンコーディングの話
Shift_JISでは、1バイト文字と後続バイト文字の領域が重なっているので、いわゆる「5C問題」が発生する
エスケープに関係するから注意
EUC-JPでは、5C問題は発生しないが、文字表現をまたがってマッチングする場合はある（蛍問題）
UTF-8では、1バイト文字、先行バイト、後続バイトの領域は全く重ならないので、5C問題や蛍問題は発生しない
しかし、非最短形式問題には注意
UTF-8の非最短形式とは、Nバイトで表現できる文字は、N+1バイト以上の形式でも表現できる。現在は非最短形式は禁止されてる。
PHPのmbstringは〜ぐええええ、通り過ぎるスライド。

デモ！！！
脆弱性サンプルの三原則
・何かしら役に立つ機能を備えること
・現場で「やってしまいそうな」想定であること（現場で納得させるために大事）
・ターゲット以外の脆弱性を含まないこと

＠半端な先行バイトの脆弱性
htmlspeci〜の第三引数があっても、バージョンが古いとだめです。
shift_jis %F0でダブルクォーテーションを殺す。連続入力フォームの際に危険
対策：PHP最新版ならおｋ。htmlspecialcharsの第三引数を指定する

＠utf-8非最短形式によるパストラバーサル
 javaだよ！
%C0%AF　だってお。%C0%AFは/の冗長表現
その後、UTF-8でエンコードするとばぐる。　とか。Javaの最新版でおｋ

＠5C問題によるSQLインジェクション
 Shift_JISの2バイト目に5Cがくる問題
mb_check_encodingご、//query("SET NAMES sjis")
カタカナのソ、mysqlうわあああああああああん、通り過ぎるスライド。

＠UTF-7によるXSS
charset=EUCJPの状態、htmlspecialcharsでエスケープしてるつもり、え、まじで。
EUC-JP　じゃないとだめ、ブラウザが認識しない。IEはコンテンツの中身で判定するからUTF-7文字列を見ると、
UTF-7でデコードする、まじIEくそ。

＠U+00A5によるSQLインジェクション
"SELECT * FROM books where author=?"
con.prepareStatement(sq1) , stmt,setString(1,key)
\'or 1=1#
'がエスケープされて、次にShift_JISに変換した文字列だと、バックスラッシュと￥が同じ扱いなので、
\\になってあばばばばばば
脆弱性が発生する条件
JDBCとしてMySQLConnectionなんたら〜
MySQLとの接続にShift_JISあるいはEUC-JPを使用

＠U+00A5によるXSS
え、最新バージョンだとcp932だと…うん？
Javascriptのエスケープ回避とか、らしい。
preg_replace後、htmlspecialchars後、onload="foo('')のように動的生成
脆弱性が発生する条件
php5.3.3以降、さっきと同じ原理。
入力の経路でU+00A5が入る、内部UTF-8、出力がcp932あるいはcp51932のとき

＠
ASP.NET + MS SQL Server + JSON
1行掲示板
evalあやしいいいいいいいｗ
MS SQL Serverのvarcharはshift_jisらしい（CP932)
unicodeの列はnvarcharで宣言すること
evalとJSONPはヤメロ

分類すると、
文字エンコーディングとして不正なデータに依る攻撃
・・通り過ぎるスライド。

やや安全なphp.iniの設定、ブログ参照
マルチバイト文字対応を十分にするには、全ての文字列処理でマルチバイト対応の関数を使用
htmlspe〜の第3引数は必須

strposじゃなくてmb_strposを使おうぜ（PHP
文字集合に関しては文字集合を変更しないことが重要
U = UTF-8
J = Shift_JIS
UUが一番いい、JJ,JU　　（内部、外部）
でも、JUのときは〜（通り過ぎるスライド）
テストする時は、尾てい骨の「てい」の漢字がおすすめ。化けるとやばいかも。

まとめ
ぐえーぐえー、通り過ぎるスライド。

ここで、PCの電源が切れる。絶望。

プログラムを騙す10の方法、シグネチャを回避する攻撃と防御

ひどいデモの連発ｗ
ブラウザの特定はHTMLパーサのバグを利用してるとか云々。
memoKEYWORD: Same Origin Policy, HTML5 Security Cheetsheet,
PHPのregister_globalsの問題、RFI攻撃
Polymorphicシェルコード
Polyglotプログラミング、たぶんこれ　http://developer.cybozu.co.jp/takesako/2009/07/polyglotrejectk.html
cp037.html, 0x457.html
EBCDIC encoding

バイナリアンはもう古い