●
公開していないとはいえウェブアプリケーションを作成している身、「PHPで作成したWebアプリケーションは常にサイバー攻撃の脅威にさらされている」などと表紙で煽られてはちょっと知識を仕入れておくかという気にもなる。そういうわけで今回はPHP版gccsの作成と同時進行でちょこちょこ読んでいた本のサマリをサラリと。本書はウェブアプリケーションに対する実際の攻撃方法を例示し、個別に対策を紹介するというかたちをとっている。それらを軽くまとめてみたいと思うが、如何せん、半分くらいは理解できなくてなあ。たとえばユーザからの入力を投稿としてそのままhtmlに表示するアプリケーションは、有害なJavascriptを入力されるとそれもそのまま表示して実行してしまうという脆弱性を抱えている。これはScript Insertionという攻撃だが、この程度なら俺にもわかる。これを防ぐには、受け付けた入力テキストに < や > などの記号が含まれる場合それらを < やら > といった表記に変換するようにすればよい。ちなみにみろりhpのコメント欄にもその機構が働いているため、たまにスパムが書いたリンクタグがそのまま表示されたりしている。ところが話がHTTPレスポンス分割攻撃などに至ってくるとちょっと前提知識が足りなくなってきてよくわからなくなる。そういう部分はサマリが随分てきとうになると思うがご容赦いただきたく。というかそもそも「想定されるダメージ：クッキーを盗まれる」を読んで「ﾌﾞﾌｫｗそりゃ大事件だｗ」とか笑っているレベルの素人なのでな、緑さんは。
●
- cross site scripting。リクエスト変数であるGETにJavascriptを埋め込んだリンクをターゲットに踏ませる。一見リンク先は正常なサイトのように見えても、Javascriptの内容が有害なサイトへのジャンプなので飛ばされてしまう。対策はサニタイズ。GETの内容をそのままページ内に表示するようなことはせず、htmlspecialchars()をかけること。
- 冒頭で触れたやつ。XXSでもそうだが、外部由来のテキストにはサニタイズ推奨。数値しかとらないとわかっている変数についてはintval()で完全に数値化する。文字列についてはブラックリストやホワイトリストを作れば確実である。
- クエリに不正なSQL文を混ぜてDBからデータを引き出す攻撃。対策はシングルクォーテーションやダブルクオーテーションのエスケープ。並びにブラックリストやホワイトリスト。
- cross site request forgery。管理者権限がなければはじかれるリクエスト変数をもたせたURIを、管理者権限をもったユーザに踏ませる。するとアプリケーションとしては管理者からの命令だと認識するため、その命令が実行される。対策はリファラーチェック。指定したサイトからのリンクでなければ処理をスキップするようにする。リファラーってのはリンク元のこと。あるいはワンタイムチケット法。正しいリンク元ページにパスワードみたいなものを置いておき、それをセッション変数に保存しておく。そして実行ページでパスワードを照合し、合致すれば処理をしてセッション変数を破棄する。いま思えばワンタイムパスワードってこのシステムを利用していたんじゃないかねえ。
- リクエスト変数の値にヌルバイトを含めることで、セキュリティチェックを通過する攻撃。たとえばサーバが"ab%00cd"という文字列をチェックするとき、ヌルバイトをチェックした時点で「この文字列はここまでか」となりこの文字列は"ab"であるとされてしまう。対策はサニタイズ。受け取ったデータのヌルバイトは削除する。
- ユーザがディレクトリ内のファイルの名前を指定できるような箇所で ../ を使ってディレクトリを移動し、他のディレクトリ内のファイルを指定する攻撃。対策はホワイトリスト法。指定してよいファイル名をあらかじめ配列にしておく。
- header()関数の飛び先に改行記号とセッションIDを変更する命令を混ぜ込み、セッションを乗っ取る攻撃。対策はサニタイズ。header()に渡すURIから改行記号 ¥r ¥n を削除する。
- include文の内容をリクエスト変数で指定している場合、そこに任意ファイルのURIをおくことでそのページにおいて好き放題できる。対策はホワイトリスト法。
- 画像ファイルなどをアップロードできるアプリケーションにphpファイルやJavascriptの含まれるファイルをアップロードし、標的のサーバ内のそのファイルをURIで指定し実行する攻撃。対策はファイル保存場所の非公開化や、アップロード可能ファイルの拡張子ホワイトリスト法。
- データの用途を明確にしつつ設計すること。ユーザが自由に値を変更できるデータは必ず型変換し無害化すること。
●
俺が趣味で作っている程度のphpアプリケーションにも脆弱性は多数あり、というかフォームやリクエスト変数を使っていればほぼ間違いなく脆弱性が発生していると考えていいだろう。そしてフォームやリクエスト変数を使わないphpスクリプトなんてものはほぼありえない。今回のgccsには、本の復習がてらこころばかりのセキュリティ強化を試してはみた。そして改めて痛感したのが、「それが問題だと気付けない問題」は「解くのが難しい問題」よりも断然難しいということだ。ページにJavascriptを埋め込むことでサイトを狂わせるなんて発想すらしなかったぜ。内容の厳密な理解はできなくとも、phpスクリプトにはセキュリティ上の問題が発生しうるということが知れて視野は広まったし、いまのレベルではこんなところだろう。ヘボなサマリのフォローが済んだところで今回はこのへんで。
