Webセキュリティに関して体系的に学べる良書、体系的に学ぶ 安全なWebアプリケーションの作り方、(徳丸本とも)をようやく読み終えたのでその学んだことをまとめようと思う。
・・・と思ったのだが、元々本自体がよくまとめられているので、ポイントを書き出すのが難しい。本を読めで済んでしまうからだ。だが、まとめられているのに500ページもある。無駄がほとんどないのにこんなにあるのだ(重さとしても相当だろうが、幸い電子書籍なのでそれは味わずに済んだ)。
このため、もうまとめるのは諦めた。自分が興味があったところをポツポツとメモとしてまとめておくことにする。体系的に学びたければ、文字とおりこの本を読めばいいのだ。
前置きが長くなったが、本を読んで大切だと思ったことを書いておく。
- Webシステムでは外部から受け取る入力パラメータを信用するな。まずは疑え。
- 入力パラメータは等しく疑え。テキストフィールドでも、ラジオボタンでも、hiddenでも。
- パラメータエスケープは用途ごとに異なることを意識せよ。
- 自作するな。フレームワークを使え。
- 使わずに済むものは使うな。
ちなみに筆者は親切に書いているのでこんなニュアンスでは言っていない。
だが、大切なことである。
1に関しては、外から来る、特にインターネット越しで来るものを扱うシステムの基本である。システムはクライアント-サーバ形式が多く、入力チェックはクライアントでやっているものが多い。そのため、サーバではチェック不要ではないかと考えるかもしれないが、それは誤りだ。特にWebシステムでは、クライアントとなる画面を通さなくても送信自体は容易に出来る(HTMLが書けさえすればPOST送信は簡単だ)。何が渡されるかわからない。まずはその認識が第一だということだ。
2に関しては、主にPOST送信される項目の話である。ブラウザ上では、ラジオボタンになっているだから任意の文字列に変えることは不可能だと思うかもしれない。ましては、そもそも画面には出ていないhiddenなんて変えることは出来るのか?
答えは出来るである。簡単な話だ。その画面を通さずにパラメータ名さえ合わせて直接POST送信すればいいのだから。hiddenだから入力チェック不要とはならないのだ。
3に関しては、対処は一つで終わりじゃないということだ。外から送信される信用出来ないパラメータをエスケープすることによって問題ない形で使うことがWebアプリケーションの基本だ。この場合、制御文字をエスケープすることが主である。だが、扱う対象がjavasciptとhtmlでエスケープ処理は異なるのだ。
4に関しては、定形処理は極力自作するなということである。セッション管理におけるセッションIDの払い出しや、入力値を元にメールヘッダを組み立て送信するなど、簡単に済ましてしまうとそれが脆弱性の元になる。幸い、フレームワークの機能を使えば面倒くさいチェック処理なども行なってくれるので安心だ。少なくとも、自分がこれから作ろうとしているコードに比べたら何倍もテストされている。
5に関しては、脆弱性の元になるような機能は使わずに済むならば使わないということだ。具体的には、入力値を元にシェルを呼び出したり、入力値を元にjavascriptを生成して実行するなど。外部から制御可能になりそうな隙は塞いでいた方が当然安全なのである。
以上、つらつらと書いてみたが、あんまりまとまっていない。・・・まあ、いいか。
最後にメモらしく、散文的に書いておく。
- 脆弱性とは悪用可能なバグのこと
- インジェクション系脆弱性が発生する状況
- テキスト形式のインタフェースを使用
- 命令や演算子、データが混在している
- インジェクション系脆弱性とは
- データの中に引用符やデリミタなど、データの終端を示すマークを混入させて、その後の文字列の構造を変化させるの可能なのが脆弱性
- 制御文字以外という正規表現 → [:^cntrl:]]
- ¥P{Cc}でも可
- javaの場合
- if (s.matches("\\P{Cc}{0,100}")) { ... }
- 文字エンコーディングのチェック:尾骶骨テスト
- 「骶」はJIS第3種文字なので、Shift-JISを途中で扱っていると文字化けする
体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
- 作者: 徳丸浩
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2011/03/03
- メディア: 大型本
- 購入: 106人 クリック: 4,040回
- この商品を含むブログ (125件) を見る