PHPスクリプトをアップロードすることを許可することには、どのようなセキュリティ上のリスクがありますか？
パートナーがPHPスクリプトを私のApacheサーバーにアップロードしたいと考えています。これによってどのような騒乱が引き起こされる可能性がありますか？
PHPパラメータは脅威をもたらしますか？これらのPHPパラメータが完全に無効になっている場合、PHPをサーバーに挿入できます安全ですか？
これらは、いくつかのPHPパラメータが私が知っているパラメータであり、セキュリティ上の問題を引き起こします。他に安全でないものはありますか？
サーバーへの書き込み：
fwrite
file_get_contents
FILE_APPEND
サーバー上のファイルを開いています：
fopen
file_get_contents
含める
恐怖
url_get_contents
curl_init
curl_setopt
ファイルの削除：
- リンクを解除
- 未設定
パートナーが私のサーバーに.phpファイルを追加することを許可する前に考慮すべき他のセキュリティ上の欠陥はありますか？知らないことがたくさんあるのではないでしょうか。
また、すべてのRAMとCPU、バックドアアクセス攻撃、マルウェアなどを使い果たす可能性のあるループスクリプトについても心配しています。それらを防ぐために実行できる対策はありますか？そして、もっと起こってから？
PHPスクリプトにJavaScript、JQuery、または他の言語が埋め込まれている場合、それらも危険ですか？また、サーバーを保護するために他の言語でどのような種類のパラメーターを無効にする必要がありますか？
JsfiddleやcodepenのようなWebサイトは、人々が自分のコードを投稿できるようにしながら、サイトをどのように保護しますか？
誰かにPHP不明なコードと不明な意図のあるファイルをアップロードすることを許可しているため、Webサイトの一部としてこの機能が必要な場合は、サーバーを強化する必要があります。例：
- アップロードするディレクトリを1つだけ設定PHPファイル。このディレクトリに適切なユーザー権限（読み取り、書き込み、または実行）を適用する必要があります。rootを使用せず、このディレクトリに特定のユーザーを作成してください。ユーザー。
- ディレクトリ用の.htaccessファイルを作成してから、そのディレクトリに特定の設定を行うことができます（ 。htaccessファイルの構成 ）。
- PHPファイルがその形式またはその形式と一致しない場合、PHPファイルに特定の名前形式と最大サイズを設定する必要がある場合でも、入力ユーザーを検証しますサイズが許可されているサイズよりも大きい場合、アプリケーションはユーザーがそのファイルをアップロードできないようにする必要があります。
- ファイル関数を使用する前に、正規化を使用します（例： realpath 、 basename ）。これにより、パストラバーサル攻撃を回避できます。
リスクが高いPHP関数、たとえば：exec、Shell_execを無効にする必要があります。これはphp.iniファイルを使用して行うことができます。たとえば、次の行を追加してOSの関数を無効にすることができます。コマンドの実行と設定の管理：
disable_functions =exec,passthru,Shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source次の行は、外部ソースからのインクルードファイルまたはオープンファイルの機能を無効にするのに役立ちます。
allow_url_fopen=Off allow_url_include=Off
これらはいくつかの基本的な推奨事項です。サーバーとWebアプリケーションに適切な設定を行うには、Webアプリケーションとニーズを分析する必要があります。
この情報がお役に立てば幸いです。
PHPスクリプトをサーバーでアップロードして実行することを許可する場合、ユーザーにユーザー名/パスワードでsshアクセスが許可されていれば、このユーザーにできることをすべて実行する権利を効果的に与えますPHPスクリプトは次のように実行されます。
したがって、問題の人がApacheを介してスクリプトを実行する場合、その人はサーバー上のApacheユーザーが実行できることをすべて実行できます。
追加のリスクとして、この人は与えられたアクセスを使用して特権エスカレーションを試みる可能性があります。これは、おそらく彼らとの法的合意に違反するでしょう（あなたは法的合意を持っていますね？）。
私には、足元で自分を撃ちそうとしているように聞こえます。信頼できない人にアップロードを許可してPHP=サーバー上で実行することは非常に危険です。攻撃者が試みることができるいくつかのことを以下に示します：
- ウェブサーバーを引き継ぐバッチコマンドを実行します。その後、ネットワーク内から他のサーバーを攻撃するためのステージンググラウンドとして使用できます。
- シークレットを含むファイルを読み取ります。パスワード、暗号化キー、TLSキーなど.
- （JavaScriptを使用して）XSS攻撃を行い、ユーザーからセッションCookieまたはその他の資格情報を盗みます。これは、アップロードされたファイルが他のアプリケーションと同じドメインまたはサブドメインで実行されることを前提としています。
リストはどんどん続いています。これらの攻撃をブロックする方法はいくつかあります（ hmrojas.p にいくつかの提案があります）が、それは簡単なことではありません。ブラックリスト機能は始まりですが、ブラックリストは部分的な防御に過ぎません。最高の専門家であっても、PHP=を実行できる人を含めることは困難です。
結局、コードを書いた人を信頼できない場合は、コードを注意深く手動で監査して、コードが無害であることを確認する必要があります。これには時間と手間がかかり、直接ファイルをアップロードすることはできません。
時々、勝つ唯一の手はプレーしないことです。これはこれらのケースの1つだと思います。
PHPコードをオンデマンドで実行できるサイト（つまり v4l ））がありますが、それらはあなたができることと いくつかの主要な安全にそれを行うためにフープ
小さな仮想マシンでスクリプトが実行される設定を使用しています。セキュリティ上の理由から、このマシンにはネットワークがなく、最小限のファイルシステムしかありません。スクリプトはデーモン（Golangで記述）によって実行され、結果（統計を含む）はPostgreSQLデータベースに報告されます。すべての結果は保存され、パフォーマンス概要の平均を提供するために使用されます。
ユーザーにPHPスクリプトをライブ環境でアップロードすることを許可しません。以前は、画像アップロードスクリプトを書いていたインターンがいました。ただし、受け入れているファイルについて何かを検証するのを忘れていた場合を除きます。誰かPHPマルウェアスクリプトをトルコからアップロードし、それを乗っ取ろうとしました（サーバーの他のセキュリティ対策がなければ、彼もそれを回避したでしょう）。
PHPには、共有ホスティングシナリオで使用できるように、機能を無効にし、特定のアクションを制限する多くの関数があります。したがって、ウェブサーバーとphpインスタンスが正しく設定されている場合は、Perlスクリプトよりもphpスクリプトをアップロードする方がはるかに安全です。
だから私はurlopenなどのセキュリティ以外のことにも取り組みたいと思います：人々がインタラクティブなサイトを実行することを許可しています。
結果は、ネットワークやディスクの量に関係なく危険ですIOたとえば、ドメインやIPレピュテーションに悪影響を与える可能性のあるフィッシングサイトをセットアップする可能性があります。
そのため、phpがメールを送信することを禁止することによってスパムメールがブロックされるため、ブラックリストに載ることはありませんが、おそらくユーザーのFacebookログインをフィッシングするスクリプトを実行しているためです。
あなたはApacheサーバーについて言及していますが、PHPがインストールされているかどうかは言及していません。
どちらのソフトウェアも、他のソフトウェアなしで使用/インストールできます。
どちらのソフトウェアも、複数のオペレーティングシステムで利用できます。
PHPがサーバーにインストールされている場合：
リスクは、ユーザーアカウントPHPが最終的に実行される場合、マシンに対する管理者権限を持っている場合、PHPライブラリ内で何でもできることです。
そのアカウントに管理者権限がない場合、これにより、ユーザーが実行できることが制限されます。
一部のオペレーティングシステムには、非管理者アカウントが管理者権限を「取得」できるようにする発見可能な既知のエクスプロイトがあります。これらは、権限昇格の悪用として知られています。使用されている場合は、再びPHPライブラリで何でもできます。
PHPがサーバーにインストールされていない場合：
リスクはほとんどありません。 PHPファイルは、PHPが解釈して動作する指示のテキストファイルです。シチューのレシピが含まれたテキストファイルよりも害がありません。
これを「確保」する方法はありません。誰か/誰でもシステム上で自由にコードを実行できるようにすると、本質的に、特定の機能の使用を妨げようとしているシステムの欠陥が原因で、またはすべての命令が実行されるため、システムが完全にテイクオーバーされる可能性があります。
専用ユーザーとしてのjail/chroot/containerのスクリプト言語でさえ、最終的には完全なrootアクセスなど（つまりファームウェアへのアクセス）を可能にする脆弱性（既存/新規の脆弱性）を悪用する可能性があります。これは、共有ホスティングプロバイダーが1日中処理しなければならないことです。予防と修正のほとんどは、次の2つから生じます。
法的;事前に契約でできることとできないことをリストする
処理する;冗長性とリカバリスキームを導入しており、違反/損失に対処している