PHPのセキュリティ対策について(他記事の読み解き) [プログラミング]
こんにちは。今日はサーバーサイドスクリプト言語としては最も敷居の低い「PHP」を使うにあたり,セキュリティ対策をどうすべきかについてまとめてみます。なお,松下幸之助の「PHP」とは無関係です。
なお,本記事は以下のサイトをワタクシの知見のレベルで読み解いたものであることをあらかじめお断りしておきます。
http://web-cocoon.jp/P_51b178bfcbefa 「HTML+JavaScript」へのテキスト埋め込みが危ない
PHPが最もお手軽なサーバーサイド言語であると言われているのは,HTMLのプリプロセッサであることも理由の一つですが,それ以前にスクリプト言語であるという点が大きいと思います。
スクリプト言語というのは,プログラムをあらかじめコンピュータよりの言語に翻訳(コンパイルといいます)するのではなく,プログラムを走らせながら逐次コンピュータよりの言語に通訳しつつ実行される言語のことです。コンパイルしないことで,実行速度は多少犠牲になりますが,コンピュータ環境への依存度が低い点が強みです。
このように,プログラムを走らせてみるまで処理内容が固まっていないというスクリプト言語の特性は,複数の言語を多層化してプリプロセスすることを可能にするという柔軟性を与える反面,セキュリティ上危険なプリプロセスを発生させてしまう懸念が生じます。
具体的に言うと,クライアントでwebブラウザは「HTML+JavaScript」で構成されたプログラムを通訳して実行するわけですが,実行前にサーバーから送信されてきたのはもともと「HTML+JavaScript+PHP」で構成されたプログラムだったりするわけです。
この場合,PHPで書かれたプログラム部分は,サーバーで「HTML+JavaScript」に変換され,その他の「HTML+JavaScript」と結合された上でクライアントに飛んできているため,PHPプログラムを注意深く書いていればセキュリティ上の問題はないものの,もしもクライアント側からサーバー側に送信されたテキスト(例えばユーザーIDとかパスワードとか書き込みコメントとか)がPHPプログラム内で無批判に埋め込まれてしまうと,そのテキストが悪意のある「HTML+JavaScript」の一部を構成してしまうと問題なわけです。こうした攻撃は,クロスサイトスクリプティング(XSS)と呼ばれています。
ただし,XSSについては対策はそれほど難しくなく,クライアント側からサーバー側に送信されるテキストが「HTML+JavaScript」の体をなしていなければ問題ないわけで,そのためにはサーバー側に送信する前にテキストをhtmlspecialchars(テキスト,ENT_QUOTES,'UTF-8')の形でくるんでやることで,<とか"とか'を無毒な形に変換すればいいわけです。
「SQL」へのテキスト埋め込みが危ない>
PHP内でSQLを用いている場合,上と同様にSQLに危険なテキストを埋め込んでしまう恐れがあります。SQLの場合,htmlspecialchars()でくるむだけでは/*とか--とかが無毒化されず,不十分です。こうした攻撃は,SQLインジェクションと呼ばれています。
SQLインジェクションに対しては,PHPのプレースホルダ機能を活用するのが定番のようです。プレースホルダとは,テキストの結合によってSQLを生成する代わりに,穴あきSQLをあらかじめ作成しておき,executeメソッドの実行を通じて穴埋めを行うことでSQLを完成させるというものです。ワタクシはSQLがよくわかっていませんので,これ以上の深入りは避けます。
※ その後にサイト http://www.phpbook.jp/tutorial/sqlite/index5.html を見つけ,sqlite_escape_string()でくるめばシングルコーテーションマークが無毒化されるので,この手もあるようです。
悪いサイトの枠内に取り込まれるのが危ない>
悪いサイトがiframeの枠内で自分のサイトを呼び出してしまうという攻撃もあります。クリックジャグリング攻撃と呼ぶんだそうですが,このサイトでは自分のサイトをそのまま呼び出したように見えて,実はiframeに透明なボタンが上からかぶせてあって,目に見えるボタンをクリックすると透明なボタンがクリックされてしまうという,恐ろしい手口です。
ただし,これについても,PHPプログラムにheader('X-FRAME-OPTIONS: DENY');というヘッダを追加してやるだけで,iframeの枠内で呼び出されることを拒否できるようです。
この他,クロスサイトリクエストフォージェリ(CSRF)という攻撃があるようですが,ワタクシの理解を超えるため,いったんおしまいにします。
なお,本記事は以下のサイトをワタクシの知見のレベルで読み解いたものであることをあらかじめお断りしておきます。
http://web-cocoon.jp/P_51b178bfcbefa 「HTML+JavaScript」へのテキスト埋め込みが危ない
PHPが最もお手軽なサーバーサイド言語であると言われているのは,HTMLのプリプロセッサであることも理由の一つですが,それ以前にスクリプト言語であるという点が大きいと思います。
スクリプト言語というのは,プログラムをあらかじめコンピュータよりの言語に翻訳(コンパイルといいます)するのではなく,プログラムを走らせながら逐次コンピュータよりの言語に通訳しつつ実行される言語のことです。コンパイルしないことで,実行速度は多少犠牲になりますが,コンピュータ環境への依存度が低い点が強みです。
このように,プログラムを走らせてみるまで処理内容が固まっていないというスクリプト言語の特性は,複数の言語を多層化してプリプロセスすることを可能にするという柔軟性を与える反面,セキュリティ上危険なプリプロセスを発生させてしまう懸念が生じます。
具体的に言うと,クライアントでwebブラウザは「HTML+JavaScript」で構成されたプログラムを通訳して実行するわけですが,実行前にサーバーから送信されてきたのはもともと「HTML+JavaScript+PHP」で構成されたプログラムだったりするわけです。
この場合,PHPで書かれたプログラム部分は,サーバーで「HTML+JavaScript」に変換され,その他の「HTML+JavaScript」と結合された上でクライアントに飛んできているため,PHPプログラムを注意深く書いていればセキュリティ上の問題はないものの,もしもクライアント側からサーバー側に送信されたテキスト(例えばユーザーIDとかパスワードとか書き込みコメントとか)がPHPプログラム内で無批判に埋め込まれてしまうと,そのテキストが悪意のある「HTML+JavaScript」の一部を構成してしまうと問題なわけです。こうした攻撃は,クロスサイトスクリプティング(XSS)と呼ばれています。
ただし,XSSについては対策はそれほど難しくなく,クライアント側からサーバー側に送信されるテキストが「HTML+JavaScript」の体をなしていなければ問題ないわけで,そのためにはサーバー側に送信する前にテキストをhtmlspecialchars(テキスト,ENT_QUOTES,'UTF-8')の形でくるんでやることで,<とか"とか'を無毒な形に変換すればいいわけです。
「SQL」へのテキスト埋め込みが危ない>
PHP内でSQLを用いている場合,上と同様にSQLに危険なテキストを埋め込んでしまう恐れがあります。SQLの場合,htmlspecialchars()でくるむだけでは/*とか--とかが無毒化されず,不十分です。こうした攻撃は,SQLインジェクションと呼ばれています。
SQLインジェクションに対しては,PHPのプレースホルダ機能を活用するのが定番のようです。プレースホルダとは,テキストの結合によってSQLを生成する代わりに,穴あきSQLをあらかじめ作成しておき,executeメソッドの実行を通じて穴埋めを行うことでSQLを完成させるというものです。ワタクシはSQLがよくわかっていませんので,これ以上の深入りは避けます。
※ その後にサイト http://www.phpbook.jp/tutorial/sqlite/index5.html を見つけ,sqlite_escape_string()でくるめばシングルコーテーションマークが無毒化されるので,この手もあるようです。
悪いサイトの枠内に取り込まれるのが危ない>
悪いサイトがiframeの枠内で自分のサイトを呼び出してしまうという攻撃もあります。クリックジャグリング攻撃と呼ぶんだそうですが,このサイトでは自分のサイトをそのまま呼び出したように見えて,実はiframeに透明なボタンが上からかぶせてあって,目に見えるボタンをクリックすると透明なボタンがクリックされてしまうという,恐ろしい手口です。
ただし,これについても,PHPプログラムにheader('X-FRAME-OPTIONS: DENY');というヘッダを追加してやるだけで,iframeの枠内で呼び出されることを拒否できるようです。
この他,クロスサイトリクエストフォージェリ(CSRF)という攻撃があるようですが,ワタクシの理解を超えるため,いったんおしまいにします。
2014-03-28 18:31
nice!(0)
コメント(0)
トラックバック(0)
コメント 0