- 追加された行はこの色です。
- 削除された行はこの色です。
**目次 [#x07d335b]
#contents
**このドキュメントは？ [#xec7bab0]
PHPによるWebアプリケーション構築時のセキュリティ対策に関して社内の勉強会用に
・<a href="http://www.asahi-net.or.jp/~wv7y-kmr/memo/php_security.html" target="_blank">PHP と Web アプリケーションのセキュリティについてのメモ</a>
・<a href="http://www.ipa.go.jp/security/awareness/vendor/programming/
" target="_blank">IPA ISEC セキュア・プログラミング講座</a>
・<a href="http://www.amazon.co.jp/gp/product/4883374718/503-3339577-1535166?v=glance&n=465392&s=gateway" target="_blank">PHPサーバーテロの技法 GIJOE 著 ソシム</a>
から特に気になる、注意しておきたい、知見や問題、対策などを簡易にメモしたものです。
勉強回そのものは<a href="http://www.asahi-net.or.jp/~wv7y-kmr/memo/php_security.html" target="_blank">PHP と Web アプリケーションのセキュリティについてのメモ</a>を読みながら進めます。
**クロスサイトスクリプティング [#ka10177d]
-サニタイズのタイミングはHTML生成時~
~
<a href="http://www.ipa.go.jp/security/awareness/vendor/programming/
" target="_blank">IPA ISEC セキュア・プログラミング講座</a>より
クロスサイトスクリプティングの解説記事でよく説明される「入力データチェックを厳密に」という表現から，図3の(1) フォーム受付時のタイミングでサニタイジングを行うのかと思いがちである。サニタイジングは(2)HTML生成時のタイミングで行うべきである。次章「クロスサイトスクリプティング対策の詳細」で説明するが，データを埋め込むHTML中の文脈に合わせて適切なサニタイジング手法を選択する必要があるからである。また掲示板の例では，将来的にデータベースへの記事の書き込み手段として，メールによる投稿が導入された場合でも，(2)HTML生成時のタイミングでサニタイジングしていれば，なんら手を加えることなく，いろんな入力源から入り込んでくるデータを漏れなくサニタイジングできる。また，同じデータに誤って2回以上サニタイジングしてデータの意味が変わってしまうという設計上のトラブルも防げる。
このようにサニタイジングのタイミングは(1)フォーム受付時ではなく，(2)HTML生成時でなければならない。参考文献『Understanding Malicious Content Mitigation for Web Developers』でもHTML生成時のサニタイジングを推奨している。
-style タグや script タグの内部に外部からの入力は組み込まない~
~
ユーザにHTMLタグやスタイルシートを記述させる場合の参考~
~
<a href="http://hatenadiary.g.hatena.ne.jp/keyword/%e3%81%af%e3%81%a6%e3%81%aa%e3%83%80%e3%82%a4%e3%82%a2%e3%83%aa%e3%83%bcXSS%e5%af%be%e7%ad%96" target="_blank">はてなダイアリーのXSS対策</a>
-入力データ挿入部によって対策の切り分けが必要~
~
通常のテキスト部、タグ属性値、URL属性、イベントハンドラ属性、<SCRIPT>、<!-- -->、
スタイルシートなどによって異なる対策が必要。~
<a href="http://www.ipa.go.jp/security/awareness/vendor/programming/a01_02.html" target="_blank">IPA ISEC セキュア・プログラミング講座 1-2. クロスサイトスクリプティング</a>参照
**HTTPレスポンス分割攻撃 [#rd5fc8da]
-header()、setcookie()に改行を含む値をわたらせないようにする
-PHP 4.4.2 / PHP 5.1.2 では、一度の複数のヘッダを送ることができないように修正されている
**NULL バイト攻撃 [#bdf6e920]
-バイナリセーフじゃない関数でチェックした後にバイナリセーフの関数を使う。またはその逆のケースで想定外の動作をしてしまう問題。
-正規表現のチェック等で注意。ereg系はバイナリセーフではない。個人的にはバイナリセーフのpreg系で統一するのがよいと思う。
-ファイル名を直接引数で渡すような設計をしない（NULL バイト攻撃で任意のファイルが読めたりする可能性あり）。この場合は下記のようにハッシュ等を用意して対処する~
~
$config_file_list = array('add' => 'add.conf', 'del' => 'del.conf');
require($config_file_list[$_GET['command']]);
~
SQLに渡すカラム値などもこの方法を使い、直接渡さないようにするのが望ましい。
**Email ヘッダ・インジェクション [#lf88be37]
-HTTPレスポンス分割と意図は殆ど同じ。吐き出すヘッダをチェックして、ユーザの
入力値をそのまま出さないようにする。改行周りに特に注意。
**include()、require() [#cd8dd501]
-allow_url_fopen を Offにするのは基本。でも、これだけでは不充分。~
php://inputを使用する方法がある。
-対策としてはNULLバイト攻撃と同じ。原則ユーザの入力値をそのままinclude()、require()に
わたさず、ハッシュや配列、テーブルなどを用意しておいて、ユーザの入力値によって、include()、require()に与える値をデータ構造から取り出すようにすればＯＫ
-eval系を使う時は入力チェックに万全の注意を（ブラックリスト法を使うこと）
![[ARK-Web SandBox]](image/sandbox.gif "[ARK-Web SandBox]")
