Download to read offline
![文字エンコーディングの変換
(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](https://image.slidesharecdn.com/wasbook41212-111215005930-phpapp01/85/Wasbook-4-1-2-13-320.jpg)
![mb_eregのdやwについて(P.83コラ
ム)
• 定義済み文字クラスはマルチバイト文字
にもマッチするので、半角数字が欲しけ
れば[0-9]と書いたほうが無難。
28](https://image.slidesharecdn.com/wasbook41212-111215005930-phpapp01/85/Wasbook-4-1-2-28-320.jpg)
Wasbook読書会4章1,2節
- 1.
- 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.
- 8. １節まとめ • 脆弱性は処理と出力に潜む • 入力は脆弱性足り得ないが必要(次章でやります) •出力に起因する脆弱性は大体「○○イン ジェクション」 • 処理・出力は大体決まっているので、発 生箇所を知ろう 8
- 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.
- 16. 入力値検証の目的(P.75,76) • 入力値の間違いを早期発見して最入力さ せるのはユーザビリティ向上につながる。 • 間違った処理によるデータの不整合を防 ぎ、システムの信頼性を向上させる。 • セキュリティが主目的じゃないよ！ 例:数値だけ受け付ける入力箇所に英字が 入っていたら検出・再入力を促すように する。 16
- 17. 入力値検証とセキュリティ(P.76) • セキュリティに役立つ場合がある。 –SQLインジェクション対策漏れがあったが、 英数字しか通さないようなバリデーションに していたから実害はなかった。 17
- 18. バイナリセーフとヌルバイト攻撃 (P.77) • バイナリセーフとは、入力値がどんなバ イト列でも正しく扱える(ヌルバイトでも 平気) • ヌルバイトは0、%00のことで、C言語等 での文字列の終端。 • バイナリセーフでないとヌルバイトを終 端として扱う。 18
- 19.
- 20. eregを回避された理由(P.78) • %00はヌルバイトなので、バイナリセーフ ではないeregは%00より後ろは検知しない • よって<script>……が実行された • この脆弱性はディレクトリトラバーサル やXSSと組み合わせて使うことが多い 20
- 21. 対策方法(P.78,P.79) • バイナリセーフの関数を用いて入力され たヌルバイトを検出。エラー＆再入力に させる。 • PHPだとpreg_match()やmb_ereg()で検出す るのが良い • あくまで保険だよ！ 21
- 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