チャット(スクリプト)の脆弱性について

 CGI・PHPの『チャットスクリプト(プログラム)』を自分で設置する・している人へ向けて。
 CGIチャット設置時のセキュリティについてのミニコラムです。
 Perl、PHP等を触る以上、HTML等の知識は有している、と前提で話を進めますが、なるべくわかりやすく書いているつもりです。
貴方の設置してるチャット(CGI, PHP)に脆弱性はないか?
 今回のコラムは、『チャット等自分以外も利用するスクリプトを設置するならば危機意識を持とう』がテーマです。
 善意ある利用者に利用方法を説けば受け入れられるでしょうが、悪意のある利用者には通じません。ならば、スクリプト側で対応するしかありません。
  ――ほとんど『(Wikipediaで言う所の)クロスサイトスクリプティング(Cross Site Scripting=XSS))』の脆弱性対策について話してるに過ぎないコラムです。
  雑誌で取り上げられているXSSの事例が『データベース』に関連する事が多いのもありますが、『掲示板・チャット等でHTMLタグやJavaScript,スタイルシートが使える』のもクロスサイトスクリプティングと呼ぶようです。
 『IT用語辞典 e-Words – XSS[クロスサイトスクリプティング=Cross Site Scripting]とは』
 http://e-words.jp/w/XSS.htmlを参照してください。
 「レンタルチャットだから絶対安全だ」、という物でもありません。レンタルチャットでも作りの甘いチャットは存在します。
目次
 今回は、以下の項目についてを考えます。
* 『安全なチャットスクリプトかどうか』
* ありがち?な脆弱性例とその対策例
o XHTML仕様にそってCSSで色指定しているチャット
o アイコンチャットで画像ファイル名でアイコンを変更するタイプのチャット
* 『HTMLタグが使えるチャットが良いの!』という人へ
* 安全なチャットスクリプトは? 危険なチャットスクリプトは?
* 対策案の色々(プログラミングができない人向け)
『安全なチャットスクリプトかどうか』
 安全なチャットスクリプトとは何でしょうか?
* 荒らしが来ても平気なチャット。
* タグが使えないチャット。
* タグが使えるが、指定の物のみ。スタイルシートは使えないチャット。
* HTMLタグを廃止し、[b]~[/b]といった擬似タグ・UBBコードのような物を採用しているチャット。
* ツーショットチャットやパスワードチャットであれば、他の人が覗き見できない。盗聴不可能なチャット。
* アイコンチャットであれば、アイコン指定のselect value値が数値で、「画像ファイル名」ではないチャット。
* 各項目内容をチェックし、『<であれば<に』『>であれば>に』『”であれば"に』『’であれば'に』変換しているチャット(サニタイジング[Sanitizing]=無害化処理を行っている)。
o フォームからポストされてくる物だけではなく、ブラウザ情報を保存している場合、『HTTP_USER_AGENT』等にもタグが含まれていないかチェックを行っているチャット。
o NULLバイトアタック(ヌルバイト攻撃)対策(¥0/¥x00)をサニタイジングしているチャット。
* 投稿method(『REQUEST_METHOD』)がPOSTの発言の場合のみ書き込み処理をするチャット。GETで発言不可能なチャット。
o ⇒といったタグを外部のサイトで設置されたら投稿されてしまうので危険、という意味です。1時間に1000人がアクセスするサイトにこのタグが設置されたら? サーバに負荷が当然かかりますし、チャットのログには『不特定多数の悪意の無い荒らし』の書き込みがされてしまう事となります。
 といった辺りでしょうか。『タグ(+CSS)が(制限無く)使えるチャットは危険だ』といえます。
 『チャットの発言欄で発言してもタグが使えない。だから安全だ』とは、言えません。
 メールアドレス入力欄があるチャットであれば、メールアドレス入力欄に入力された値をチェックしなければなりません。
 『test@test.com』とメールアドレス入力欄に入っていれば結果、「Mailaddress」となれば問題ない物を、
 『test@test.com” style=”font-size: 50px;』と入力されて結果、「Mailaddress」となってしまえば……どうなるかわかりましたね?
・Mailaddress ←通常の例。正常です。
・Mailaddress ←font-size:50px;に指定されてしまった方。
 このように、『フォントサイズを大きくされたり』、『JavaScriptでウィルスコードの埋め込まれたページにジャンプさせてしまう』ことだって、不可能ではなくなるのです。
 タグが利用可能であると、他には、といった感じに、ウィルスコードの入ったサイトを画像URLとして表示させる、などもされない事はありません。
 『HTMLタグが利用可能なチャットは危険』である、と理解していただけたでしょうか?
ありがち?な脆弱性例とその対策例
 大切な処理、見落としていませんか?
XHTML仕様にそってCSSで色指定しているチャット
 あまり無いとは思いますが、『XHTML使って仕様に沿ってCSS使って文字色装飾してる』チャットで、文字色指定がフォームから渡される場合も危険です。
span style=”color: (色名);”といった形式になるかと思いますが、 色指定のvalue値に『#000000』や『Black』といった色RGB値・色名の指定が考えられますが、ここで『;font-size:50px』と指定されていたら、という問題ですね。「色指定のvalue値に『;』が含まれていれば削除する、という仕様」でも良いでしょうし、「色指定のvalue値を6文字に制限してRGB値だけを採用する仕様」にするのも手です。考えて作られてなければ、利用者に危険が及ぶチャットになってしまうのです。
 ちなみに、色名指定で一番長いのは『Lightgoldenrodyellow(20Bytes)』です。無精して『色指定は20Bytesまでなら何でもOK』とかすると痛い目に合うかもしれません。
アイコンチャットで画像ファイル名でアイコンを変更するタイプのチャット
 『アイコンチャットであれば、アイコン指定のselect value値が数値で、「画像ファイル名」ではないチャット。』は安全だ、と書きましたが、その理由は、下記の例を考えてみてください。
http://shelle.sakura.ne.jp/chatlinks/chaticon/というフォルダURL+アイコン名でアイコンファイルが呼び出されるとしましょう。
ここで『icon_00.jpg』が呼び出される指定であれば『http://shelle.sakura.ne.jp/chatlinks/chaticon/icon_00.jpg』が呼び出されます。
そこで『../icon_00.jpg』が呼び出される指定であれば『http://shelle.sakura.ne.jp/chatlinks/icon_00.jpg』が呼び出されてしまいます。
ここで、『../../format.exe』という悪意のあるプログラムが実行されてしまえば、どうなるでしょう? という事ですね。危険なのです。
対策としては、アイコンのvalue値をチェックし、『..』が含まれていれば削除(置換)してやる等が考えられます。
『HTMLタグが使えるチャットが良いの!』という人へ
* 信頼できる人に権限を持たせ、『HTML使用権限』を設ける(チャットルーム入室前に特定のパスワードを入力したらタグ利用可能、とか)。
* 擬似タグ・UBBコードを導入する
* 文字装飾などをチェック項目制にする
 といった感じの対策を取る事で安全なチャットにすることができます。
安全なチャットスクリプトは? 危険なチャットスクリプトは?
 がる・ザ・ジョーカーが確認した物を挙げておきます。
比較的安全なチャットスクリプト
* Perl製。KENT WEBの『Windy v1.5』、『COMCHAT v4.4』、『YY-CHAT v2.31』 … KENTさん
 注:『getでの投稿ができてしまう』のが少し危ないかもしれないけれど。それさえ防げば問題無しです。
 例:~/chat.cgi?mode=regist&name=a&comment=a&line=10とか直打ちで書き込めてしまう……。
* PHP製。Ristorante Cappuccinoの『php New Chat v0.92』 … ICE(Internet Community Exchange)さん
事業者『ICE』によるPHPチャットスクリプト。『RCUG』に「CGIチャットの恐ろしさ」、『悪意のある利用者についてのお話』という読み物もあるようです。
危険なチャットスクリプト
* Perl製。KENT WEBの『COMCHAT-EX v3.xシリーズ』comchatx.cgi
また、このv3.xシリーズを改造して再配布しているチャット。『文字色』選択欄の”デコードがされていない為少し危険。styleとonMouseMove組み合わせた荒らしが来たら対策できていない。
o Perl製。Falcon Worldの『グラデーションチャット v2.31』comchatg.cgi
… Name、E-Mail欄はデコードしてあるが、『グラデーションチャット アイコンセレクト版 v2.31i』はアイコン欄を弄られてしまえば危険です。
o Perl製。PrettyBookの『PRETTY COMCHAT v1.00(配布終了)』pcchat.cgi
… グラデーションチャットと同じく、アイコン選択部分追加部分でデコード処理をしていない為に危険。
o NF-CHAT v1.4など
* Perl製。The Roomの『Light Chat v2.16』『Icon Chat v2.16』lchat.cgiとichat.cgi
… 2001/06/28から更新されていない。仕様機能として、『荒らし対策』に挙げられている『スタイルシートを使った書き込み禁止』が実装されていない。Mail欄を少し弄ってしまえばタグ使用可能になる為危険。デフォルトでmethod=”get”での投稿も通ってしまう為、危険。
o Perl版。もめ花美さんによる『Secret Meeting Chat v1.26r3』smchat.cgi
… メール欄に”とか入ったら警告文出る仕様なので比較的安全みたいです。アイコンURL指定周りも、『#$icon_list[2 -$m_ic] = ‘url:’;』の部分をコメントアウトにしておけばURL指定無効になるようで比較的安心・安全設計のようです。普通にLight Chat/Icon Chatの代わりに使うとしたら、多機能すぎて負荷気になりますけど……。でも、デフォルトで$ENV{’REQUEST_METHOD’} = ‘GET’でも投稿できてしまうので危険です。
* Perl製。『ゆいちゃっと』シリーズ全般。デコードができてないタイプが多い為、要チェック。
1996年と10年以上前から存在する『黎明期のチャット』なので信頼できるのだろう、と思えば間違いです。ゆいさんによる開発は2000年で終了していますし、7年以上経過した放置された危ないスクリプトなのです。
そりゃあ元を辿ればゆいちゃっとが国内で有名なチャットかもしれませんけれど、FOLLOWERが多すぎてウンザリします。ゆいちゃっとがCGI開発者さん達に与えた影響は良い物だったのかもしれませんが。
gzip圧縮送信する、とかjcodeLE.plといった役立つ知識(by ゆい『CGIぱっちわーく』)は必見ですが、スクリプトのセキュリティは意識されていません。
o Perl版。くるくるチャット・くるくるCGI研究室の『くるくるちゃっと』シリーズ3種(更新日が2006年以前の物)。『GET投稿を反映しない』設定はあるが、本家(ゆいちゃっと)同様デコードができていない。
o Perl版。割烹朝日の『のりちゃっとPro3.01(2002.06.01)』。
o Perl版。『乙霧楓。’sるぅむ』の『かえでちゃっとCute』など(2005.05.28)。
o Perl版。『Shin’sTerritory「伊勢的新常識」』の『えびちゃっと』シリーズなど(2007.07.26確認時点)。
o PHP 版。ASPゆいちゃっとの『PHPでゆいちゃっと2Cute-AT』(php2cat)。全デコード処理があるにはあるが、タグを含む発言がデフォルトで適用されたり、GETで投稿可能な為危険。『a』などの発言が可能になってしまう。background- image:url(~);で指定されていた場合を考えると危険と言わざるを得ない。「入室後に『タグ無効』チェックがあり、StyleSheetなどを閲覧者主導でタグ不許可にできる(strip_tags関数使用)」。
o PHP 版。AKIさんの「PHP@Home – From Perl to PHP(旧:AKI-PHP Try The PHP)」で配布されていた、『PHPゆいちゃっと2000』シリーズ(2004年以前に配布されていた物)と、『PHPゆいちゃっと2005シリーズ (PHPYui2005)』。説明は、「デコードはされるが、GET投稿可能・JavaScriptを含む発言がチェックされない」……ASPゆいちゃっとの『PHPでゆいちゃっと2Cute-AT』と同様に利用者に危険を及ぼす可能性があります。
o 他、沢山あります。ここまでくると、『脆弱性はゆいちゃっと系の宿命か?』と(苦笑)。
* PHP製。レッツPHP!の『pHp de cHat フレーム高速チャット(2006/12/1up!)』
ヴァージョン表記じゃないので、『2006/12/1up!』版以前についてですが、デコードはされます。ですが中身チェックができていない。色の手動入力で悪意ある文字列が含まれていた場合、チェックされていない為危険です。
対策案の色々(プログラミングができない人向け)
 Perl/PHPなどを自分で書き換える事のできない人は、『スクリプト面を見直さずに対策できないものか』と思ったかもしれません。
 では、『外部からの見直し』について考えてみましょう。
 ゆいちゃっとやIcon Chat/Light Chatのように『method=”get”』でも投稿できてしまうスクリプトに対しては、『リファラー(REFERER・リンク元・参照元)URLをチェックしてやれば対策に』なります。
 以下、有効かもしれないPerlライブラリを紹介します。
* CGIROOMの『CGI機能拡張』にある『KEEP OUT(リファラーチェック)』,『ワードチェック』など。
http://cgiroom.nu/
* The Roomの『その他』にある『Access Denial』。
http://dream.lib.net/room/
Light Chat/Icon Chat配布サイトでもありますが。……あまり役立たない気がします(滅)。

No related posts.

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です