ホスティング会社はセキュリティ上の理由からPHPを避けるようにアドバイスしました。それらは正しいですか？
私は過去にハッキングされた後、セキュリティについて当然のことながら心配しているクライアントの再設計を行っています。私は最初、単純なPHP includeヘッダーとフッターのテンプレート、およびお問い合わせフォームにインクルードすることをお勧めしました。ホスティング会社からPHPはセキュリティ上の問題で、誰かがcPanelに侵入してサイトを制御できる可能性があります。
これは、誰かに運転しないように言って、自動車事故に遭わないようにすることのようです。私の直感は、ホストが自分のシステムのセキュリティ上の欠陥のためにクライアントに責任を移そうとしているということです。また、サーバーにはまだPHP=がインストールされているため、それを使用するかどうかに関係なく、これにより実際に攻撃対象領域がどの程度減少するかについて質問しています...しかし、私はセキュリティの専門家ではないので、足を口に刺したくない。
連絡フォームを処理するには、何らかの動的スクリプトが必要になることをクライアントに伝えました。 （誤り？）彼らは私がその1ページでPHPを使用できるかどうか尋ねました。これはかなり安全ですか、それともあなたの車のドアをロックして窓を下に置いたままにすることと同等ですか？
anyPHPスクリプトを使用することは、どれほど単純であっても、固有のセキュリティであるという主張にどれだけ真実があるか問題はありますか？SSLを使用しない共有ホスティングを使用していますPHPを使用したためにハッキングされたと想定するのは妥当ですか？使用しない場合でも安全ですが、アンインストールできませんか？そうでない場合、他の問題があります。
（他の言語では答えが異なりますか？）
セキュリティの問題が蔓延している人気のあるPHPベースのソフトウェアが多数存在するため、PHP自体にセキュリティの問題（必要なセキュリティの更新を想定）があることはそれほど多くありません。 PHPは、自分を窒息させるのに十分なロープを与える言語であるために失敗する可能性がありますが、実際の問題は、実際に蔓延している脆弱なPHPコードがどれだけあるかです。 Stack Overflow PHP tag を見て、古いチュートリアルの残虐行為に基づいて恐ろしく脆弱なコードを書いているPHP初心者を見つける必要があります。
さらに、セキュリティの欠陥が蔓延していることで知られているかなりの数の人気のあるPHPソフトウェアは、非常に古いコードとコーディング手法に基づいています。これらの古い慣習の多くは、固有のセキュリティ問題があるため、不適切な慣行と見なされています。
これは、誰かに運転しないように言って、自動車事故に遭わないようにすることのようです。
かなりそうです。より良いアドバイスは、「エアバッグのない古い車を運転しないでください」という方針に沿っているかもしれません。
私の直感は、ホストが自分のシステムのセキュリティ上の欠陥のためにクライアントに責任を移そうとしているということです。
必ずしも。ユーザーがWordPressサイトとcPanelに同じパスワードを使用している場合、WordPressパスワードが危険にさらされるとcPanelも危険にさらされます。それはユーザーの責任です。ただし、ハッカーがそれを実現する必要はめったになく、PHPシェルを使用するだけです。
連絡フォームを処理するには、何らかの動的スクリプトが必要になることをクライアントに伝えました。 （誤り？）
必ずしもそうではありません。サードパーティのサービスを使用してメール送信を処理できます。次に、サービスは動的サーバースクリプトを処理し、セキュリティへの影響を引き継ぎます。さまざまな機能セットで利用できるそのようなサービスは数多くあり、静的に生成されたサイトで連絡先フォームを強化するために人気があります。
PHPスクリプトを使用することは、どんなに単純であっても、固有のセキュリティ問題であるという主張にはどのくらい真実がありますか？
一部はあるが、多くはない。 PHPには、PHPとそれを実行するサーバーソフトウェアの両方で、アクティブなコードがいくつか含まれています。そのプロセスに特定のPHPコードに依存しないセキュリティの脆弱性があった場合、それが悪用される可能性があります。そのリスクはわずかですが、そのようなサポートのないサーバーにはないリスクです。
「正しい」は正しい言葉ではないかもしれませんが、「賢明」、「賢明」、「良心的」が頭に浮かびます。 PHPは、当初からソフトウェアの正当性の価値を下げるという哲学に固執しています。他の言語（Pythonなど）があきらめてエラーをスローし、プログラムが間違っていることを通知する状況が多数発生しますが、代わりにPHPが無意味なことを行い、物事が大丈夫だった場合。
正確さはセキュリティにとって非常に重要であることに注意してください。左右のエラーを静かに無視する傾向がある言語は、セキュリティの問題があるプログラムを公平に共有する以上のものになります。たとえば、プログラマーが特定の攻撃から保護していると考えるコードの一部があり、インタープリターがエラーを無視するため、実際にはスキップされている場合があります。
加えて：
- PHPは、技術を習得しようとする動機が最も少ないプログラマーの最下位の人々にアピールするように設計されています。したがって、安全でないソフトウェアを書く可能性が最も高い。
- PHPチームには、一般的なセキュリティ問題を修正する試みに重大な欠陥があった歴史があります。たとえば、SQLインジェクション保護を見てください。これは、問題を修正するための繰り返し欠陥のある試みを裏付けています：
real_escape_string（元のescape_stringは壊れていましたが、後で削除されなかったため）対addslashes対mysql_escape_string/pg_escape_stringなど。それに対して、他のほとんどすべての言語は、準備されたステートメントとクエリパラメータを使用して、最初の試行ですべてのデータベースに拡張可能なデザインを取得しました。
つまり、他の回答でのあなたのやりかたについてのすべての話についてcan PHPで安全なソフトウェアを書いてみてください。
PHPのセキュリティ問題は、一般的に2つのカテゴリに絞り込むことができます
パッチ未適用システム
現在、 Wordpress stats は、すべてのユーザーの半分以上が実行していることを示していますPHP PHPの過去のバージョン- End of Life （PHP 5.2-5.4）。2週間でPHP 5.5はEOLになり、すべてのインストールの約80％にジャンプします。さて、公平を期すために、一部のEnterprise/LTS Linuxインストールはセキュリティ修正をバックポートしますが、それらの大部分はバックポート修正を使用していません（またはシステムにパッチを適用しないものもあります）。さらに、多くの人がアップグレードを拒否していますPHP =自体。コードを更新できない、または更新しないか、古いソフトウェアの方が安定していると考えています。
Wordpress（＃1 PHPアプリケーション））は、ユーザーがソフトウェア自体を最新の状態に保つために一丸となって努力しました（ただし、ユーザーは大きな進歩を遂げました）。 ％は最新バージョンのWordpressを実行しています。つまり、約60％にパッチが適用されていないセキュリティの脆弱性がある可能性があります。これは単なる基本プログラムです。Wordpressには、プラグインの大規模なエコシステムがあり、その多くは- 独自のセキュリティ脆弱性がある 。
次に、他の問題があります。たとえば、無効な mcryptライブラリ を使用した多くの古いコードです。そして、それはあなたがコンパイルできる1つのPHPプラグインです。
次に、これを実行していないサーバーに外挿し、統計をWPに報告します。それはきれいな絵を描きません。去年の夏、Apache 1.3.3とPHP 4.1.2。にまだ残っているeコマースページを実行しているWebサイトを見つけました。古すぎてSSLv2が有効になっていた...
悪い習慣
SO PHP質問を十分に長くぶらぶら回すと、多くの人々が悪いコードを実践しているのが見えるでしょう。私が見た問題のいくつかは年
- SQLインジェクション
- MD5を考えることはパスワードを保護する良い方法です
- 古くなったAPIをコードに使用する（つまり、
ext/mysql、古いMySQLコネクタ） - ユーザー入力を信頼してコードを実行する（つまり、ユーザー指定のデータで eval を使用する）
- PHPコード（つまり exec 関数）でセキュリティリスクをオフにしない）
訓練を受けていない人にとって、これはPHP問題です。問題を生み出しているのはプログラマとそのエコシステムです。多分彼らは急いでいました。多分彼らは予備でこれを行う人を雇いました時間と「ちょうどそれを働かせた」。
安全ですか？
はい！しかし、そのセキュリティには多少の努力が必要です。 PHPインストールを最新の状態に保ちます。サーバー全体を最新の状態に保ちます。ホストはセキュリティとパッチを実行しませんか？別のホストを見つけます。（これに頭を悩ます人々に驚いています。）独自のサーバーを構築します（VMは安価です）。しかし、何よりも注意してください。セキュリティについてできる限りのことを学んでください。あなたのウェブサイトとサーバーを海に出してみましょう。
PHPが安全でないと言う人は怠惰です。
PHPは、他のどの言語（Java、Railsなど）よりも安全、または安全ではありません。それはすべてコーディングに関するものです。攻撃をそらし、防御し、防止し、軽減するためのチェックとバランスが整っていますか。引用：
WhiteHat Securityは、.NET、Java、ASP、PHP、Cold Fusion、Perlを使用して、30,000を超えるWebサイトの脆弱性評価を行いました。最も広く使用されている言語は.NET（Webアプリケーションの28.1％）、Java（24.9％）、およびASP（15.9％）でした。
...
プログラミング言語の.Netには、スロットあたり平均11.36の脆弱性があり、Java 11.32およびASP 10.98。最も安全な言語であるColdFusionでは、スロットごとに6つの脆弱性がありました。 。Perlにはスロットごとに7つの脆弱性があり、PHPには10個の脆弱性がありました。
...
Javaは発見された脆弱性の28％を占め、ASP= 15％です。「この場合も、言語で記述されたアプリケーションの数とWebサイトの複雑さを要因として考慮する必要があります。」 PHPも発見された脆弱性の15％を占めました。ColdFusionは脆弱性の4％とPerl 2％のみを占めました。（ source ）
これは、優れたコーディング慣行に関してサイトがどのように開発されたかについては何も述べていません。たとえば、各言語で（より良い用語がないために）スキルのないプログラマーを採用した場合、これらの数値が逆転し、Perlが最も脆弱性が高くなり、.Netが最小になります。すべては、コード自体が実行することになっていることに要約されます。コードは、開発に入る前に改ざん/乱用をテストしてその唯一の機能を実行するようにプログラムされていますか？
十分なセキュリティ チートシート 、 ベストプラクティスガイド 、および セキュリティの問題 をカバーするその他の記事がありますが、これはクライアントの状況になります彼らのプロバイダーからのアドバイスに基づいて疲れています。これは「彼が言った」となるため、ハードルになる可能性があります。彼女は、PHPを使用してサイトを作成できるようにクライアントを説得するためにある程度の苦労をしました。 PHPはデモサイトを作成することであり、それに対して脆弱性評価スキャナー（Acunetix、AppScan、Burpsuite）を使用して欠陥をチェックすることになります。どちらも見つかりませんでした。クライアントの両方に構築したセキュリティポスチャの詳細を示すレポートを提示し、プロバイダーに提示できるような方法（PDFなど）で作成します。
PHPの根本的な問題の1つは、CGIモデルの基本的な問題です（PHPはmod_phpのトラッピングに基づいています）-つまり、そのユーザー-直面しているデータはスクリプトと混在しており、例えばユーザーがアップロードして実行可能スクリプトになります。これは必ずしもPHP自体の問題ではありませんが、システムでPHPを使用できるようにすると、攻撃対象が非常に大きくなります。かなりの数のWordPressプラグインのセキュリティ問題は、たとえば、この側面から発生します。
従来のCGIベースの展開では、信頼できるディレクトリ（/cgi-bin/など）からのCGIスクリプトの実行のみを許可することでこれまでこの問題を軽減していましたが、多くの共有ホスティングプロバイダーは最終的にこの制限を「利便性」のために緩和し、同じ利便性が広がっていますPHP全体を通して。
最近のPHPベースのアプリケーションの多くは、.htaccessを、これらの問題を緩和するのに役立つ迅速で汚い要求ルーティングメカニズムとして使用することがよくありますが、これは普遍的ではなく、まだ簡単な解決策ではありません。
私の意見では、PHPの最大の問題は、任意のPHPコードが構成されている任意のサーバーで実行できるようにするのが非常に簡単であるため、 PHPは、他の言語で記述されたコードよりも必ずしも安全ではありません（ただし、標準ライブラリ 厳密には何もしていません 安全なコードの記述に関して）、 PHPスクリプトを実行するメカニズムは、サーバー上でも利用できるPHPのメリットにより、大規模なセキュリティの課題を提供します。
PHPを使用してもセキュリティリスクは必要ないとの評価に同意します。 PHPがセキュリティリスクと見なされているのと同じ理由で、WordPressを避けているベンダーもいます。人気です。普及度が高いほど、エクスプロイトの開発に多くのエネルギーが投入されます。
とはいえ、適切に実装され、タイムリーなパッチを受け取り、悪意のあるアクティビティを検出するためのある程度の監視がある場合、PHPは避けられません。結論：セキュリティリスクは、プラットフォームに依存しないセキュリティリスクです。スクリプト言語を変更しても、不十分に記述/開発/実装されたコードに関連するセキュリティリスクは軽減されません。
必要なのが標準のヘッダー/フッターを含めることだけである場合、PHPはやり過ぎかもしれません-単純なサーバー側インクルードでそれが可能です。
以前の回答が主張したように、PHPは本質的に危険ではありません。ただし、サーバー上に完全なスクリプト言語が必要ない場合は、セキュリティを確保するためにスクリプト言語をインストールしないでください。あなたが言うようにPHPがとにかくサーバーにインストールされる場合、それを使用することによって生じる追加のリスクは、あなたが何も愚かでない限り、ほぼゼロです。そしてテンプレートを含めることは、URLパラメータからファイル名を何らかの方法で解析しない限り、愚かではありません。
お問い合わせフォームは、誰かが送信したときにPOSTリクエストを処理するために、その背後にある種類のAPIとデータベースが必要であり、この部分がどの程度適切に記述されているかによって、物事を作成または破壊することになります。使用します。SQLデータベースの場合、SQLインジェクションは注意する価値があります。ユーザーの入力が何らかの方法でユーザーまたはWebページのクライアントにエコーバックされる場合は、（Java）スクリプトインジェクションを検討し、すべてが適切にHTML-エスケープ。連絡フォームと比較して、インクルードの使用は安全です。
インタラクティブなWebアプリケーションではなく、一連のWebページだけが必要な場合は、静的サイトジェネレーターを使用するのがセキュリティの究極です。サーバーが提供する必要があるのは、攻撃対象がはるかに小さいファイルだけです。
そう：
PHPスクリプトを使用すると、どんなに単純であっても、固有のセキュリティ問題はあるという主張はどれほど真実ですか？
そのように言いました、ほとんどなし。 include-headerスクリプトは脆弱性ではありません。 PHP必要のないときに最初にインストールすることは、セキュリティ上の最善策ではありません。セキュリティパッチがリリースされるたびにインストールして定期的に更新しないことは、潜在的な問題です。これらの更新の責任者のポリシーを持っている-サイトの設計が完了した後、クライアントがこれを担当するのか、それともホスティングプロバイダーがそうなのか？クライアントがそれについて心配しているのであれば、PHPサーバー上の最初の場所です。そうでない場合、何をしているのかわかっている場所でそれを使用しないというセキュリティ関連の理由はありません。
言語とツールは本質的に安全ではなく、悪いコードとセキュリティの慣行は安全ではありません。
PHPはエントリに対する障壁が低いため、ネットワークのセキュリティと安全なコーディングを理解していない人は、情報に基づいていない決定でセキュリティの問題を引き起こす可能性があります。
それはツールではなく、それを使うサルです;-)
任意の言語で書かれたコードは安全ではない可能性があります。
「ホスティング会社からPHPを使用することはセキュリティ上の懸念であり、cPanelに侵入してサイトの制御権を取得する可能性があるため、セキュリティ上の懸念があるとのことでした。
ホスティング会社がcPanelを実行する必要があると考える場合PHP=ホストを移動する時間