12月14日にwasbook読書会で発表した時の資料。

1. Wasbook読書会4章1,2節
Webアプリケーションの
機能別に見るセキュリティバグ
1

2. 1節
WEBアプリケーションの機能と
脆弱性の対応
2

3. １節要約
• 脆弱性は処理と出力に潜む
• 入力は脆弱性足り得ない(入力値の問題ではなく、出力
結果が脆弱性となる。また、ミドルウェアのせいで入力検証で脆弱性にな
る場合があるそうです。)
• 出力に起因する脆弱性は大体「○○イン
ジェクション」
• 処理・出力は大体決まっているので、発
生箇所を知ろう
3

4. 出力の種類と脆弱性(P.68)
• HTML・JS(表示) ------- XSS,HTTPヘッダインジェク
ション
• DB・SQL -------- SQLインジェクション
• 外部コマンド ------- OSコマンドインジェク
ション
• メール -------- メールヘッダインジェク
ション
→これらは、外部にある種のスクリプトを
出力している 4

5. 処理の種類(P.68)
• ファイル出力 ------- ディレクトリトラバーサル
• 認証 ---------- セッションフィクセーション
• 認可 ---------- 認可不備
• その他 ---------- CSRF(クロスサイトリクエストフォー
ジェリ)
5

6. インジェクション系脆弱性とは
(P.69,70)
• Webアプリケーションでのインターフェー
スは基本的に何らかの文法があるテキス
ト形式
• データはデリミタ(,等)、引用符(“”)で区別
されている
→ここを攻撃する！
6

7. P.70の表を参照
(データの終端)
7

8. １節まとめ
• 脆弱性は処理と出力に潜む
• 入力は脆弱性足り得ないが必要(次章でやります)
• 出力に起因する脆弱性は大体「○○イン
ジェクション」
• 処理・出力は大体決まっているので、発
生箇所を知ろう
8

9. 2節
入力処理とセキュリティ
9

10. ２節要約
• 入力値検証はアプリケーション仕様に基
づいて行う
• 具体的な検証内容
– 文字エンコーディング
– 制御文字を含む文字種(文字列の妥当性)
– 文字数
• 脆弱性を軽減させるためにも入力のセ
キュリティをする
10

11. 「入力」では何をするか(P.72)
• 「入力」とはHTTPリクエストのパラメー
タ(GET,POST,クッキーなど)
• 以下の処理を行う
– 文字エンコーディングの妥当性検証・変換
• 文字コードを使った攻撃を防ぐ
– パラメータ文字列の妥当性検証
• アプリケーションの仕様。そして保険。
11

12. 文字エンコーディングの検証
(P.73)
bool mb_check_encoding(string $str, string $encoding)
※PHPでのmb_はマルチバイト対応を示す。
12

13. 文字エンコーディングの変換
(P.73)
文字エンコーディング変換は２つ方法があり、ど
ちらを選ぶかはプロジェクト毎に決定しましょ
う。
string mb_convert_encoding(string $str, string
$to_encoding [, mixed $from_encoding])
例:SJISからUTF-8へ変換する
$str_u = mb_convert_encoding($str, “UTF-8”,”SJIS”);
13

14. 文字エンコーディングの変換
(P.73)
• php.iniに設定を書くと自動変換してくれる
– 書き方は/etc/apache2/php.ini参照
– P.75のコラムを読んでデメリットを知ってお
くこと
→PHP以外は表4-2参照
14

15. 文字エンコーディング実演(P.74,75)
15

16. 入力値検証の目的(P.75,76)
• 入力値の間違いを早期発見して最入力さ
せるのはユーザビリティ向上につながる。
• 間違った処理によるデータの不整合を防
ぎ、システムの信頼性を向上させる。
• セキュリティが主目的じゃないよ！
例:数値だけ受け付ける入力箇所に英字が
入っていたら検出・再入力を促すように
する。
16

17. 入力値検証とセキュリティ(P.76)
• セキュリティに役立つ場合がある。
– SQLインジェクション対策漏れがあったが、
英数字しか通さないようなバリデーションに
していたから実害はなかった。
17

18. バイナリセーフとヌルバイト攻撃
(P.77)
• バイナリセーフとは、入力値がどんなバ
イト列でも正しく扱える(ヌルバイトでも
平気)
• ヌルバイトは0、%00のことで、C言語等
での文字列の終端。
• バイナリセーフでないとヌルバイトを終
端として扱う。
18

19. ヌルバイト攻撃の実演(P.77)
19

20. eregを回避された理由(P.78)
• %00はヌルバイトなので、バイナリセーフ
ではないeregは%00より後ろは検知しない
• よって<script>……が実行された
• この脆弱性はディレクトリトラバーサル
やXSSと組み合わせて使うことが多い
20

21. 対策方法(P.78,P.79)
• バイナリセーフの関数を用いて入力され
たヌルバイトを検出。エラー＆再入力に
させる。
• PHPだとpreg_match()やmb_ereg()で検出す
るのが良い
• あくまで保険だよ！
21

22. 何回も言いますが、
入力値検証はアプ
リケーション要件
22

23. アプリケーション要件(P.79)
• 電話番号やメールアドレスは形式が決
まっているよね？仕様を考えよう
• 制御文字のチェック
– 改行やタブなどの通常は表示されない文字
• 文字数のチェック
– 動作保証ができる範囲を作ると攻撃用の長い
スクリプトを読み込ませないようにできる
– あまり長いとちゃんと動作するかわからない
23

24. 入力値検証は全
てのパラメータを対
象とする。hiddenや
ラジオボタンもクッ
キーもrefererも (セッションIDは
検証いらない？)
24

25. 正規表現(P.80)
• 入力値検証の実装は正規表現を使うと便
利。
• PHPだとpregかmb_eregを使う。
– eregはPHP5.3以降非推奨
– pregやmb_eregはバイナリセーフ
• 日本語の扱いはpregはUTF-8のみ、mb_ereg
は様々な文字コードで扱える。
• 正規表現を使えない人は今すぐ学びま 25

26. 正規表現による入力値検証の
例(1)P.80の実演
26

27. 正規表現による入力値検証の
例(2)P.82の実演
27

28. mb_eregのdやwについて(P.83コラ
ム)
• 定義済み文字クラスはマルチバイト文字
にもマッチするので、半角数字が欲しけ
れば[0-9]と書いたほうが無難。
28

29. これまでの注意点を受けたサ
ンプル(P.83,84)
29

30. 入力値検証とフレームワーク
(P.84)
• フレームワークの中には、入力値検証を
扱いやすくして開発の手間を省いてくれ
るものがある
• CodeIgniterにはform_validationとかある
よ！
30