12

.htaccessを使用して、サーバーでHTMLページをPHPとして解析（HTMLドキュメントでPHPコードを実行）できることをご存知ですか？

そうですね、そうするのは悪いと言う人もいます。なんで？

また、アプリケーションにセキュリティの脆弱性が生じると言う人もいます。どのように？

ドキュメントがブラウザに到達する前にソースコードが削除されたままなので、ソースコードへの不正アクセスの場合はあり得ませんね。

4

6 に答える 6

13

ちょっとした話から始めましょう。私がLinuxディストリビューションベンダーのセキュリティ担当者だったとき、PHPセキュリティチームは、PHPインタープリターがWebサーバー内で実行されている場合でも、インタープリターの呼び出しを停止するようLinuxベンダーに依頼しました。mod_php Apacheで）。（当時、1週間におよそ1つの通訳者のクラッシュが見つかりました。）

実行中のPHPコードを提供した人は誰でも完全に信頼されており、スクリプトがインタープリターから実行できることを制御しようとする試みは誤った方向に進んでいること、そして誰かがインタープリターをクラッシュさせる方法を見つけた場合、彼らが実際に私たちを納得させるには少しの会話が必要でしたスクリプトの安全な実行はPHPインタープリターの目標ではなかったため、課そうとした制限（たとえば、ばかげたセーフモードの山全体など）を回避することは、セキュリティ上の欠陥ではありませんでした。だろう。

私は実際、議論の最終結果にかなり満足しています。これは、PHPのセキュリティ目標を明確に定義しています。100％完全に信頼できるPHPコードの実行のみを許可する必要があります。あなたがそれを信用しないなら、あなたはそれを実行しません。とても簡単です。

スクリプトがインタプリタのバグを悪用するか、予期しないことを行うかに関係なく、インタプリタが利用できるオペレーティングシステムリソースはすべて利用可能で公正なゲームです。

したがって、本当に必要な場合を除いて、Webサーバーのコンテキストでランダムなコードを実行しないようにしてください。

最小特権の原則を使用して、すべてのプログラムで利用できるリソースをガイドしてください。

AppArmor、SELinux、TOMOYO、SMACKなどの必須アクセス制御ツールを使用して、プログラムで実行できることと実行できないことをさらに制限することを検討してください。私は2001年頃からAppArmorプロジェクトに取り組んできましたが、ほとんどのシステム管理者は1日の努力で、AppArmorを使用してサイトのセキュリティを有意義な方法で強化できると確信しています。さまざまなツールがさまざまなセキュリティモデルを中心に設計されているため、いくつかのオプションを評価してください。どちらかがより適している場合があります。

ただし、何をするにしても、サーバーを不必要に開いて余分なベクトルを介して攻撃するような方法でサーバーを実行しないでください。

于 2012-05-28T22:27:18.760 に答える
8

主な懸念事項は、コードを別のサーバーに移動したり、他の誰かにコードやサーバー設定を操作させたり、.htaccessファイルを作成したりすると、PHPインタープリターによるHTMLページの解析が停止する可能性があることです。

その場合、PHPコードはブラウザに提供されます。

于 2012-05-28T22:21:59.327 に答える
3

これを行うと、HTMLファイルは実際にはPHPファイルであるというセキュリティ上の脆弱性があります。したがって、それらのアップロードは、PHPファイルのアップロードと同じくらい真剣に受け止められる必要があります。多くの場合、HTMLファイルをPHPのように解析するように設定されているとは思わないため、HTMLファイルのアップロードはそれほど重要ではないと考えられます（そのため、社内の他のユーザーが誤ってセキュリティホールを開く可能性があります）。[PaulP.ROの回答によると、セキュリティの問題は逆方向にも発生する可能性があります。後でこの設定が誤って削除されたときにPHPがHTMLと間違えられるためです。]

また、パフォーマンスの問題も少しあります。すべてのHTMLファイルをPHPパーサーで実行する必要があります（PHPが含まれていない場合でも）。

于 2012-05-28T22:25:09.853 に答える
2

HTMLをPHPとして解析することは、速度と組織上の理由から悪いことです。

  • PHPエンジンを呼び出しているため、PHPとして解析されたHTMLファイルの読み込みは技術的に遅くなります。
  • しかし、ほとんどの場合、組織的な目的には適していません。プロジェクトが拡大するにつれて、HTMLファイルに埋め込まれたPHPコードを探すことを想像してみてください。プロジェクトを閲覧するときは、ファイル拡張子がそのファイルの目的の真の指標である必要があります。フォームが「login.php」に送信された場合、サーバーコードが含まれていることを合理的に確信できます。ただし、「login.html」は別のHTMLページである可能性があります。

残りのコメントに関しては、セキュリティの側面についてはよくわかりませんが、HTMLとPHPの出力を混同すると、見過ごされているXSSの脆弱性につながる可能性があると思いますか？しかし、それに関しては専門家ではありません。

于 2012-05-28T22:25:34.137 に答える
1

速度が悪いので、何らかの理由でPHPインタープリターが機能しない場合は、PHPコードがページソースに表示されます。たとえば、PHPコードにデータベースのユーザー名とパスワードが含まれている場合、誰でも簡単にデータベースに接続してアクセスできます。

そして、zedが言ったように、それは組織的な理由で悪いです。1つのファイルを更新する代わりに、サイト上のすべてのファイルを更新して簡単な変更を加える必要があります。

于 2012-05-28T23:38:50.580 に答える
0

サーバーがHTMLファイルをPHPとして解析できるようにすることは、適切なアプリケーションデザインパターンを使用していないことを示しています。つまり、推奨される方法ではなく、自分の道を切り開いているということです。MVC（懸念事項とは別）のような設計が存在するのには理由があります。

任意のドキュメントを直接呼び出すことを許可する際の問題の1つは、アプリケーションへの出入り口の数を減らすのに役立つ「フロントコントローラー」（通常はindex.php）が失われることです。

アプリケーションへのパスは多数ありますが、設計でカバーしなければならない可能性のある攻撃ルートはさらに多くあります。

于 2012-05-28T22:31:43.497 に答える