Webデザイナが知っておくべきPHPセキュリティ

たにぐちまこと(H2O Space.)
2008-04-10 08:00:00
  • このエントリーをはてなブックマークに追加

クロスサイトスクリプティング

 例えば、次のようなスクリプトを作ってみよう(インターネット上には公開せず、XAMPPやMAMPなどを用いて、コンピュータ内だけで試してください(連載第1回参照))。

index.php
<p>あなたのお名前をご記入ください</p>
<form id="form1" name="form1" method="post" action="main.php">
  <input name="my_name" type="text" id="my_name" size="35" maxlength="256" />
  <input type="submit" name="btnSubmit" id="btnSubmit" value="送信する" />
</form>

main.php
こんにちは。<?php echo $_REQUEST['my_name']; ?>さん

 index.phpをWebブラウザに表示して、名前を記入すると次の画面に名前が表示されるというスクリプトだ(画像1)。

画像1 画像1

 大したことのないスクリプトに見えるが、非常に危険なセキュリティホールを含んでいる。名前の欄に、次のように記入してみよう。

<script>alert(123);</script>

 すると、次の画面のように名前が記入される代わりに、警告ウィンドウが表示される(画像2)。

画像2 画像2

 これは、本来名前を記入するべき欄に、悪意のあるユーザーがJavaScriptを記入することでWebブラウザを暴走させたものだ。上記のスクリプト内容では警告ウィンドウが表示されるだけの内容なので被害はないが、スクリプトの内容によってはWebサーバーに被害を与えたり、他の閲覧者の情報を盗むようなスクリプトを書き込まれる可能性もあり、非常に危険な状態といえる。

 これを「クロスサイトスクリプティング」などという。今回の場合、「<script>」というタグを書き込まれることがないよう、次のようにすれば防ぐことが可能だ。

main.php
こんにちは。<?php echo htmlspecialchars($_REQUEST['my_name'], ENT_QUOTES); ?>さん

 このように、スクリプトを記述する時には必ず必要な記述などもある。特にユーザーからの入力を受け付ける時には、細心の注意が必要なため、必ずエンジニアに相談してから作ると良いだろう。

  • コメント(10件)
#1 大野晋一   2008-04-10 14:18:17
htmlspecialchars()関数の第2引数について

builder編集部の大野です。初出時、2ページ目最下のソースコードにおいて、htmlspecialchars($_REQUEST['my_name'])となっていましたが、特別な理由がない限りhtmlspecialchars($_REQUEST['my_name'], ENT_QUOTES)とすべきなので、第2引数を追加しました。

確かに、タグを防ぐだけなら問題ないですが、クオート(')を防ぐにはENT_QUOTESを第2引数に指定すべきです。さらにいえば、第3引数に文字エンコーディングを指定するほうが望ましいです。つまり、次のコードがもっとも望ましいといえます。文字エンコーディングを直接ここに書き込むのはどうか、という議論もありますが……

http://jp.php.net/htmlspecialchars
htmlspecialchars($_REQUEST['my_name'], ENT_QUOTES, 'EUCJP')
#2 h2ospace   2008-04-10 18:56:57
筆者です。「htmlspecialchars」の件、うっかりしていて大変失礼いたしました。
はてなブックマークやトラックバック等でご指摘いただいた方々、誠にありがとうございました!
#3 がる   2008-04-19 01:46:29
本文中に出ている
mysql_query("SELECT * FROM login_table WHERE id=".mysql_real_escape_string($_REQUEST['id'])." AND password=".mysql_real_escape_string($_REQUEST['password'])");

ですが。
最後のダブルクォートが不要である(というかこのままだとシンタックスエラー)であることを除いてもなお、問題があります。
というかこのままではSQL-Injectionの脆弱性は全然とれておりません。

セキュリティの記事であれば、きちんと検証なりされるか、或いは相応の識者に確認などを取られてから記事を書かれる事を強くお勧めいたします。

といいますか。
先日のC++といい。中身のレビューが全く出来てないと思うのですが。そのあたり、編集の方はどのようにお感じになられているのでしょうか?
#4 大野晋一   2008-04-21 20:39:44
builder編集部の大野です。

シンタックスエラーの件は大変失礼いたしました。誤って余計な記号が含まれてしまいましたので、修正いたします。

また、ご指摘のセキュリティ面の脆弱性についてですが、以下の資料を参考にさせていただいております。

情報処理推進機構:情報セキュリティ:脆弱性対策:安全なウェブサイトの作り方
http://www.ipa.go.jp/security/vuln/websecurity.html

PHP: SQLインジェクション - Manual
http://jp.php.net/manual/ja/security.database.sql-injection.php

もちろん、実際にはmysql_real_escape_string()のほかにも、addslashes()や文字コードへの対策などもするべきかと思います。しかし、本企画の「Webデザイナ(マークアップエンジニア含む)が少なくとも知っておきたいWebテクノロジの知識を、PHPを例に4回にわたって紹介」するという主旨をご理解頂ければ幸いです。

http://builder.japan.zdnet.com/sp/php-for-desinger-2008/story/0,3800085347,20369782,00.htm

ほかの問題がございましたらご指摘いただければ幸いです。

ご指摘の通りのチェック体制の至らなさは見直して参ります。それでは、今後ともどうかよろしくお願いします。
#5 がる   2008-04-22 06:11:44
がるです。
大変に手厳しい発言になり恐縮ではあるのですが。

> また、ご指摘のセキュリティ面の脆弱性についてですが、以下の資料を参考にさせていただいております。
「参考にした資料があるから問題はない」とでもおっしゃりたいのでしょうか?
一応念のために、ごく簡単にミニマムコードを書いて「実際にクラックが可能であることを確認してから」コメントを差し上げているのですが。
逆に。御社側で多少なり、そういったチェックは本当に行われているのでしょうか?
筆者様にそのような確認はちゃんととられているのでしょうか?

> もちろん、実際にはmysql_real_escape_string()のほかにも、addslashes()や文字コードへの対策などもするべきかと思います。しかし、本企画の「Webデザイナ(マークアップエンジニア含む)が少なくとも知っておきたいWebテクノロジの知識を、PHPを例に4回にわたって紹介」するという主旨をご理解頂ければ幸いです。
そういう問題ではありません。
もっと、きわめて基本的な部分で欠落がございます。
こんな生半可で半可通な知識は、まさに「生兵法は怪我の元」なだけ。こんなレベルなら、ない方がマシです。

> ほかの問題がございましたらご指摘いただければ幸いです。
ほかの問題ではなくて。前回コメントで指摘させていただいた内容が、以前の、C++の記事の初めの修正と同様「問題の本質を理解しておらず」「故に修正箇所などが全く的を射ていない」のです。

…と書き立てても御理解いただけないでしょうから、正解を書いておきます。

mysql_query("SELECT * FROM login_table WHERE id='".mysql_real_escape_string($_REQUEST['id'])."' AND password='".mysql_real_escape_string($_REQUEST['password']) . "';");

ポイントはWHERE句において文字列をシングルクォートで囲っているかいないか、です。
試しに。筆者や大野様が「問題ない」とおっしゃっている、元のソースコードで。
IDに“hoge OR (1=1”、passwordに“1) OR 1=1”という文字列を入れてみてください。

SELECT * FROM login_table WHERE id=hoge OR (1=1 AND password=1) OR 1=1;

ちなみに、修正したソースの場合、以下の通りになります。

SELECT * FROM login_table WHERE id='hoge OR (1=1' AND password='1) OR 1=1';

こんなSQLが通るものが、本当にセキュアなのですか?
これが「Webデザイナ(マークアップエンジニア含む)が少なくとも知っておきたいWebテクノロジの知識」なのですか?

「まずい」と指摘された場合に。「すでにミスを起こしてしまっている社内リソースで全てを片付ける」のではなくて、まず初めに「どこがまずいのか」を指摘者に質問するくらいの余裕があってもよろしいのではないでしょうか?
拝見しているかぎりでは。指摘を受けた後も結局は「知識的に足りない社内リソースだけで物事を片付けようとし」「そのために結果として的を大きくはずしている」ようにしか見受けられません。

ZDNetさんといえばそれなりにお名前も通っている会社様であると私は認識しております。
もう少し、出すモノに対する品質へのプライドとか責任感とかそういったものが向上する事を心から願ってやみません。
#6 大野晋一   2008-04-22 17:31:55
ご指摘ありがとうございます。このままでは文字列の IDやパスワードを受け付けてくれないですね。修正いたしました。

また、先の投稿のとおり、現在、正確性の担保のための施策を見直しております。さらに、今回のような公開後のご指摘に関して、がる様のおっしゃるように、ご指摘をいただいた方に協力を仰がせていただくこともあるかと思います。

いずれにせよ、貴重なご指摘をいただきまして感謝しております。
#7 h2ospace   2008-04-25 13:33:30
筆者です。

> がるさん

ご指摘、および詳しい解説をいただきましてありがとうございました。
完全に私の検証ミスで、セキュリティ以前に IDとパスワードに文字列が使えないプログラムを掲載してしまいました。

また、ご指摘の通りセキュリティ的にも大変危険なスクリプトになってしまい、大変申し訳なく思っております。今後は、しっかり気をつけて記事を執筆して参りますね。

この度は、誠にありがとうございました
#8 thesecret   2008-05-10 17:46:58
PHPはそもそも「HTMLをちょっと変えれば動くようになります」という趣旨の言語ですから、
「今日からはじめて、簡単に作ってみまちた」という人はたくさん出てくるわけでして、セキュリティ上の問題など気にしない人はどんどん出てくるのは間違いないと思います。
すると、「みんなでSQLインジェクションができないように書こう!」なんてことでは、どうにもならないような気がします。

本来的にはそういうことを気にしなくても安心してサイトが作れるようになってないといけないよな、と思うのでした。
#9 WEBセキュリティ勉強中   2012-01-06 17:22:36
次のページに進んだ時に「123」と表示されるXSSが発生するのですが。
原稿も途中で欠けてる状態ですし、ページを改ざんされたのでしょうか?
#10 builder編集部   2012-01-06 17:51:41
WEBセキュリティ勉強中 様

builder編集部です。ご指摘、ありがとうございました。

原因は記事本文に記載したHTMLタグの「&lt;」「&gt;」が、文字実体参照ではなく、通常の文字に置き換わったために起きた現象でした。先ほど実体参照に修正し、正常に表示できることを確認いたしました。

この度はご迷惑をおかけしまして、誠に申し訳ございませんでした。
今後もご愛読頂ければ幸いです。よろしくお願いいたします。
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]