
Webデザイナが知っておくべきPHPセキュリティ
ここまでの連載で、PHPがデザイナにとっても決して難しいものではなく、むしろ便利に使えるものであることを紹介した。少しでも恐怖感やアレルギー感がなくなっていただけると幸いである。
ただし、あまり身近に感じすぎてしまうのも逆に危険が伴う。
スクリプトは、ご存じの通り何でも作ることができてしまうため、Webサーバーに大きな負担をかけたり、場合によっては壊してしまうようなスクリプトさえできあがってしまうことがある。
また、正しい知識を持って作らなければ「セキュリティホール」が存在することになってしまい、クラッカーと呼ばれる悪意を持ったユーザーによって、個人情報が盗まれたり、Webサイトを改変されたりする可能性もあり得る。
そこで、今回はそんなセキュリティの知識を紹介していこう。
無限ループ
次のようなスクリプトを見てみよう(実際に動作させないでください)。
<?php $count = 1; while($count <= 10) { $coun = $count + 1; echo $count; } ?>
このスクリプト、一見すると大した内容ではない。「$countという変数が10になるまで1ずつ加算して、画面に表示する」というスクリプトだ。「while」というのは「繰り返す」という意味のスクリプトで、特定の条件が満たされるまでスクリプトを何度も動作させることができる。
ただし、上記のスクリプト。実は次の部分でスペルミスを犯している。
$coun = $count + 1;
これにより、正しい処理が行われずに「while」の終了条件であるはずの「10になるまで」という条件が永遠に満たされない状態となる。そのため、このスクリプトは終わらない「無限ループ」という状態に陥ってしまうのだ。
すると、Webサーバーは意味のないスクリプトを動作させ続け、非常に負担の大きい状況になってしまう。
このように、スクリプトはたった一文字間違えただけでも、意図しない動作になるばかりか、Webサーバーに負担をかけてしまったり、閲覧者に迷惑をかけることになるので気をつけよう。
- コメント(10件)
htmlspecialchars($_REQUEST['my_name'], ENT_QUOTES, 'EUCJP')
はてなブックマークやトラックバック等でご指摘いただいた方々、誠にありがとうございました!
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++といい。中身のレビューが全く出来てないと思うのですが。そのあたり、編集の方はどのようにお感じになられているのでしょうか?
シンタックスエラーの件は大変失礼いたしました。誤って余計な記号が含まれてしまいましたので、修正いたします。
また、ご指摘のセキュリティ面の脆弱性についてですが、以下の資料を参考にさせていただいております。
情報処理推進機構:情報セキュリティ:脆弱性対策:安全なウェブサイトの作り方
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
ほかの問題がございましたらご指摘いただければ幸いです。
ご指摘の通りのチェック体制の至らなさは見直して参ります。それでは、今後ともどうかよろしくお願いします。
大変に手厳しい発言になり恐縮ではあるのですが。
> また、ご指摘のセキュリティ面の脆弱性についてですが、以下の資料を参考にさせていただいております。
「参考にした資料があるから問題はない」とでもおっしゃりたいのでしょうか?
一応念のために、ごく簡単にミニマムコードを書いて「実際にクラックが可能であることを確認してから」コメントを差し上げているのですが。
逆に。御社側で多少なり、そういったチェックは本当に行われているのでしょうか?
筆者様にそのような確認はちゃんととられているのでしょうか?
> もちろん、実際には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さんといえばそれなりにお名前も通っている会社様であると私は認識しております。
もう少し、出すモノに対する品質へのプライドとか責任感とかそういったものが向上する事を心から願ってやみません。
また、先の投稿のとおり、現在、正確性の担保のための施策を見直しております。さらに、今回のような公開後のご指摘に関して、がる様のおっしゃるように、ご指摘をいただいた方に協力を仰がせていただくこともあるかと思います。
いずれにせよ、貴重なご指摘をいただきまして感謝しております。
> がるさん
ご指摘、および詳しい解説をいただきましてありがとうございました。
完全に私の検証ミスで、セキュリティ以前に IDとパスワードに文字列が使えないプログラムを掲載してしまいました。
また、ご指摘の通りセキュリティ的にも大変危険なスクリプトになってしまい、大変申し訳なく思っております。今後は、しっかり気をつけて記事を執筆して参りますね。
この度は、誠にありがとうございました
「今日からはじめて、簡単に作ってみまちた」という人はたくさん出てくるわけでして、セキュリティ上の問題など気にしない人はどんどん出てくるのは間違いないと思います。
すると、「みんなでSQLインジェクションができないように書こう!」なんてことでは、どうにもならないような気がします。
本来的にはそういうことを気にしなくても安心してサイトが作れるようになってないといけないよな、と思うのでした。
原稿も途中で欠けてる状態ですし、ページを改ざんされたのでしょうか?
builder編集部です。ご指摘、ありがとうございました。
原因は記事本文に記載したHTMLタグの「<」「>」が、文字実体参照ではなく、通常の文字に置き換わったために起きた現象でした。先ほど実体参照に修正し、正常に表示できることを確認いたしました。
この度はご迷惑をおかけしまして、誠に申し訳ございませんでした。
今後もご愛読頂ければ幸いです。よろしくお願いいたします。
- 新着記事
- 特集
- ブログ
- 企画特集
-
変化への対応はリアルタイム経営で
-
働き方改革にモニターが有効なワケ
-
レガシーなインフラ設計を見直す
-
AI活用が激変する新たなインフラ
-
RPAがニガテなExcelをどう使う
-
働き方、生産性を根底から底上げ!
-
攻めと守りのクラウド活用とは!?
-
「データ」こそDXの主役
-
分析されたデータを活用できるか?
-
意識してますか?PCの「信頼性」
-
ITシステムは永久のβ版思考で
-
データ活用を加速するエコシステム
-
サブスクモデルのSaaSで業務改善
-
働き方改革は身近な「改善」から
-
2020年代を勝ち抜くインフラ
-
ビジネス成功の砦はここにあり!
-
Why ワークプレース?
-
特集:ビジネスを止めるな!
-
ビジネスの大きな転換点で勝者に!
-
特集:ポスト2020時代のCX再考
-
ウルトラ帳票文化を乗り越える!
-
講演レポ:ポスト2020時代の基盤
-
どこまで可能?企業を究極の自動化
-
明治創業の鉄道企業がAWSに挑戦
-
隗より始めよ
-
下した決断は「ハイブリッドへ」
-
クラウドバックアップお悩み相談室
builder編集部の大野です。初出時、2ページ目最下のソースコードにおいて、htmlspecialchars($_REQUEST['my_name'])となっていましたが、特別な理由がない限りhtmlspecialchars($_REQUEST['my_name'], ENT_QUOTES)とすべきなので、第2引数を追加しました。
確かに、タグを防ぐだけなら問題ないですが、クオート(')を防ぐにはENT_QUOTESを第2引数に指定すべきです。さらにいえば、第3引数に文字エンコーディングを指定するほうが望ましいです。つまり、次のコードがもっとも望ましいといえます。文字エンコーディングを直接ここに書き込むのはどうか、という議論もありますが……
http://jp.php.net/htmlspecialchars