寺子屋未満

2014年11月29日に開催された、第20回北海道情報セキュリティ勉強会に参加しました。
# もう2015年なんですけどね。参加した勉強会について記録を残しておかないとむずむずするため、積み残しを無くします。

今回の講師は徳丸浩さん。徳丸さんは、私がイメージしていたよりずっと温厚な方でした。
こちらの「徳丸本」が有名です。（”徳丸本”でAmazon検索したら1発で出てきて驚きました。）

体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践

posted with amazlet at 15.01.17

徳丸 浩
ソフトバンククリエイティブ
売り上げランキング: 9,600

Amazon.co.jpで詳細を見る

“予習必須”だったのですが予習間に合わず。
（案の定、後半の話は予習なしでは難しかった…）

今回は「文字コードに起因する脆弱性」についてのお話でした。
以下、私が噛み砕けた範囲でのセッションメモです。

Web脆弱性入門

ここはほぼ大丈夫だった。

• CSRF（FORMタグのaction属性の悪用、はまちちゃん、iframeを使ったフォーム送信、PW盗める）
  対策：token(セッションとhiddenの値をチェック)
• XSS（利用者のブラウザ上で攻撃者がJavaScriptを実行、増殖機能付きワームのようなことができる）
  対策：エスケープ、属性値はダブルクォートで囲む、レスポンスヘッダでの文字エンコーディング指定、Javascriptの動的生成を避ける（あー…やった記憶ある）
• SQLインジェクション（攻撃対象サーバーのDBに攻撃者が自由にアクセス、情報漏洩、データ改ざん）
  対策：プレースホルダーの使用
• ディレクトリトラバーサル（相対パスを指定を悪用し、任意のディレクトリにアクセス、ファイル読み出し、書き込み）
  対策：プレースホルダーの使用

文字コード超入門

ここは覚えておくべき

• 文字コード = 文字集合 + 文字エンコーディング
• 文字集合（ASCII, ISO-8859-1, JIS X 0201, JIS X 0208, Unicode）
• 文字集合の変更は1対1対応でない箇所で文字化け等の原因になる（5C と A5、事故の元）
• 文字エンコーディング（Shift_JIS, EUC-JP, UTF-8）
• Shift_JISの5C問題、EUC-JPの「蛍」問題
• UTF-8は領域がかぶることによって発生する問題はない
• 「非最短形式問題」は注意 – 1バイト形式で表現できる文字を2バイト・3バイト形式でも表現できる（現在は廃止）

文字コードの脆弱性

* 何かしら役に立つ機能を備えること
* 現場で「やってしまいそうな」想定であること
* ターゲット以外の脆弱性を含まないこと
これらの条件を満たした、文字コードの扱いに起因する脆弱性デモを紹介してくださいました。

• 文字コードの脆弱性:表示の問題ではない
• 半端な先行バイトによるXSS（文字コードを使った古典的な攻撃の例）
  F0を入力すると” と組み合わせて ・ (F022) という文字であると認識されてしまう
• 非最短形式によるパストラバーサル
  %CO%AF（”/”スラッシュの非最短形式） を使ってディレクトリトラバーサルができちゃった
• 5C問題によるSQLインジェクション
  Shift_JIS文字の2バイト目に0x5cが来る文字に起因する問題。
  間違えて 0x5Cが1バイト文字（バックスラッシュ）として解釈された場合に問題がおきる。
• UTF-7によるXSS
  UTF-7特有の文字列”+ADw-“があると、IEはUTF-7だと解釈する。
  →エスケープされない生のスクリプトが出てきちゃった。
  レスポンスヘッダに正しい文字コードを指定してあげていればOK
• U+00A5によるSQLインジェクション
  mySQLへの接続はShit_JIS、ブラウザはUTF-8でエンコーディングされている
• U+00A5によるXSS
  エスケープの必要がない文字列がエスケープされたことで起きる。（良くからなかったとのメモあり）
• UTF-7によるJavaScript
  evalインジェクション（遅くても2011年には修正されている）

不正な文字エンコーディング対策

• Shift_JISを避ける
• 外部内部で同じ文字コードを使用する
• 骶吉（つちよし）テスト

まとめ

• 正しい脆弱性対策をしていても、文字コードの扱いに依る脆弱性が混入する場合がある
• 文字コードの選定
• 入力時に不正な文字エンコーディングを排除
• 処理ごとの正しい文字エンコーディングの取り扱い
• 出力時の文字エンコーディングの扱い
• DBの文字エンコーディング指定と静的プレースホルダーの使用

今まで、文字コードについて、脆弱性の観点から真剣に考えたことがありませんでした。
自分がこれらの対策を取ろう、と考えたとき、簡単にできるアプローチとして、Webアプリケーションを制作する時に選択するフレームワークはメジャーなものを使うというものがありそうです。
メジャーなものであれば脆弱性のFIXも早いし、情報の共有も早いのでオレオレフレームワークより安心。
あとは、きれいな見通しの良いソースコードを書くこと。
問題がどこかわからないようなソースコードを書かないこと。
訳がわからないままに、コードをコピペしないこと。
なども大事だなあと再確認しました。

今回のケーキはルタオでした。美味しかった <3