私は読んでいました Essential PHP Security そして第8章では、共有ホスティング環境でのPHPアプリのホスティングに関する問題について説明しています。
彼が言及する問題のいくつかは次のとおりです。
-公開されたソースコードとファイルシステムの参照
webサーバーは、ソースコードを実行するためにソースコードを読み取ることができる必要があります。 Webサーバーは共有されているため、サーバー上の別の開発者によって作成されたPHPスクリプトは、任意のファイルを読み取ることができます。攻撃者は、ファイルシステムを参照するスクリプトを作成することもできます。
-公開されたセッションデータとセッションインジェクション。
デフォルトでは、PHPはすべてのユーザーが書き込み可能な/ tmpにセッションデータを格納するため、Apacheはそこにセッションデータを書き込む権限を持っています。単純なスクリプトにより、他のユーザーが読み取り、追加、変更、またはセッションを削除します。
この方法で共有ホスティングを使用すると、すべてが公開されて脆弱になるようです。
私の質問:
1)この本が8年前に出版されたことを考えると、それらはまだ問題が発生しているのでしょうか、それとも過去数年間で何らかの形で軽減されたのでしょうか?
ファイルシステムのブラウジングは、適切な能力のあるホスティングサービスによって無効にすることができます。私はまだ持っているいくつかの共有ホスティングアカウントがあなた自身のディレクトリの外のファイルを閲覧することを許可していないことを知っています。また、リークされたセッションデータは問題ではありません-それが属するデータベースにそれを入れてください。
2)これらの巨大なセキュリティ上の懸念を引き起こすのであれば、なぜ共有ホスティングを選ぶのでしょうか?
歴史的背景-8年前、VPSホスティングは増加し始めていました。 2つの主要なオプションは、共有ホスティングと専用マシンでした。そして明らかに、専用マシンは共有ホスティングよりもはるかに高価でした。だから...多くの人が共有ホスティングを利用しました。
)共有ホスティングは安価であることを理解していますが、専用ホスティングよりも安全で安価な代替手段が必要ですか?
いいえ、8年前には本当にありませんでした。その特定の価格ではありません。 VPSホスティングは今でははるかに安価であり、それは基本的に引き継がれています。
4)共有ホスティングでホストされるアプリケーションを開発するように顧客から依頼された場合、安全なアプリケーションを開発するための完全な証明方法はありますか、それとも単なる災害のレシピですか?
いいえ。共有ホスティング、または専用ホスティングでこれを行うための「簡単な方法」はありません。ただし、共有ホスティングよりもVPSホスティングをお勧めします。これにより、開発者はマシンを保護する責任を負いますが、開発者は必要なソフトウェアや拡張機能をインストールすることもできます。
共有ホスティングでも問題ありません。理論的な問題はありますが、マシンをセットアップする人は、平均的なPHPハックよりもはるかに有能である可能性が高いことも考慮してください。正直なところ、セキュリティの問題がある場合は、サーバーのセットアップよりもPHPコードの欠陥が原因である可能性がはるかに高いです。
部分的な答え:
2)利用可能な最も安価なオプションだからです。そして、リスクについて知らないか、自分が持っているものを何も感じていないために気にしない人にとっては、それを確保するための追加費用の価値があるので、そうしない理由はありません。
3)仮想プライベートサーバー(VPS)は、共有ホスティングと専用ホスティングの間に価格があります。あなたが得るものはVMあなた自身のweb/db/etcサーバーをインストールするためのものです。ローエンドでは私はわずか10ドル/月でそれらを見てきましたが、安価な共有アカウント。その価格では、他の多数のVPSが実行されているサーバー上で最小限のリソースが得られますが、同じことが低コストの共有ホスティングにも当てはまります。大規模なVPSとローエンドの専用サーバー(例:atom、celeronなど)の境界を曖昧にするまで、サーバーリソースの共有とより多くのサポート。
4)専用サーバーでさえ、ハッキングされる可能性があるという点で完全な証拠ではありません。ただし、共有アカウントを強化するための具体的なアドバイスはできません。
部分的な答え:
デフォルトでは、PHPはすべてのユーザーが書き込み可能な/ tmpにセッションデータを保存するため、Apacheはそこにセッションデータを書き込む権限を持っています。簡単なスクリプトで、他のユーザーが読み取り、追加、変更、またはセッションを削除します。
これは本当ですが、回避策があります-変更できます session.save_path
ホームディレクトリの何かに、または データベースにセッションデータを保存 代わりに。