hnwの日記

なぜSuhosinを使うのか

Suhosinプロジェクトのドキュメント「Suhosin - Why ?」を日本語訳してみました。慣れた方の翻訳とはかけ離れた出来だと思います。というのも、日本語として自然な言い回しに変えようとした部分があり、翻訳としては少々問題があるかもしれません。また、僕の英語力にもそもそも問題があるわけですが、文意は99%取れたつもりでいます。


原文も長い文章では無いので、興味を持たれた方は原文も合わせてチェックして、僕のまずい翻訳を指摘して頂ければ助かります。


Suhosinが何かについては廣川さんの記事「【PHPウォッチ】第30回 相次ぐ脆弱性修正リリースとセキュリティ強化PHP「Suhosin」」が詳しいのでそちらをご覧下さい。


補足:SuhosinPHP本体に対するパッチと、PHPエクステンションとの2つで成り立っており、それぞれ独立しています。(参照:Suhosin Downloads

なぜSuhosinを使うのか

これからSuhosinを使おうとしている人が最も知りたいことは、Suhosinが本当に必要なものだとしても、なぜSuhosinを使う必要があるのか、またパッチ単体やエクステンション単体や両者の組み合わせによりどういうメリットを得られるのかの2点でしょう。


この質問に対する答えは、あなたがPHPをどう使っているかによります。もしあなたが自分のサーバーで自分で書いたスクリプトやアプリケーションを動かすのにPHPを使っているのなら、自分のコードが信頼できるかどうかについては自分自身で判断できるはずです。このような場合にはSuhoshinエクステンションはおそらく不要です。というのも、Suhosinエクステンションの機能の大半は脆弱なプログラムからサーバーを守るためのものだからです。とはいえ、PHPは非常に複雑なプログラミング言語であり、アプリケーション開発時に陥りやすい多くの落とし穴が存在します。PHPのコアプログラマーでさえ、こうした落とし穴を完璧には把握しておらず、しばしば安全でないコードを書いてしまうほどです。ですから、用心のため常にSuhosinを導入しておくのは良いアイデアです。他方、SuhosinパッチはZendエンジンに存在するバッファオーバーフローとそれに関連する脆弱性からサーバを守るためのものです。いつでもPHPにこのようなバグがあることは、これまでのバージョンアップの経緯を見れば明らかです。


もしあなたが自分の書いたPHPスクリプトだけでなく、第三者の書いたPHPアプリケーションを自分や顧客のためにホスティングしているなら、利用しているPHPアプリケーションのコード品質を保証できないことになります。不幸なことに、PHP言語の落とし穴はプログラマに広く知られていないのが実際のところです。さらに、多くの落とし穴は近年発売されたPHPセキュリティの本にも載っていません。というのも、そららの本はマーケットで最初に出版するために大急ぎで書かれていたりするからです。また、それらの本の多くはセキュリティのプロではないPHPプログラマによって書かれていることも理由の一つです。中でもOreillyの本は最悪で、サンプルコードの問題点を修正しようとして、更に危険な脆弱性を作り出しています。


そういった本に共通の間違いがもう一つあります。それは、PHPの「remote code inclusion脆弱性」に起因する危険性がallow_url_fopenディレクティブ(やPHP 5.2.xのallow_url_includeディレクティブ)で解決するかのような都市伝説を広めていることです。この情報は間違っています。なぜなら、これらのディレクティブではphp://inputやdata://といったURLによる攻撃を防げませんSuhosinやその前身であるHardening-Patchだけが攻撃可能性のある全てのURLを無効にできます。


結局のところ、Suhosinをどう使うかはあなたの自由です。もしあなたのサーバとあなたのビジネスに関して更なる防御が必要であれば、我々はエクステンションとパッチの組み合わせを強く推奨します。常に覚えておいて欲しいのですが、あなたがサーバを守ることは、あなたとあなたのユーザーだけを守っているのではなく、インターネットの他のユーザーも守っていることになります。というのも、もしあなたのサーバがSPAMDDOS攻撃の踏み台にされてしまうと、あなたのサーバがインターネットの他のユーザーを攻撃するからです。