私は、すべてがpublic_html \フォルダーにあるphp Webサイトを持っています。これには、構成とクラスを含むincludes
フォルダーが含まれます。私は開発者にパブリックフォルダーから移動するように言いましたが、ファイルはphpファイルであり、ブラウザーでタイプしても
www.example.com/includex/config.php
彼らが得るすべては空白のページです。
あれは正しいですか?ハッカーが何らかの方法で私のサーバーにログインしてファイルをダウンロードしたり、XSSを使用してサーバー上のphpファイルに含めたりしても、誰かがphpファイルをダウンロードして内部を確認する方法はありませんか?
PHPコードを読み取るには、 ディレクトリトラバーサルの脆弱性 が必要です。file_get_contents()
またはその他の 悪用可能なファイルシステム関数 =。
MysqlでのSQLインジェクションを使用して、ソースコードを読み取ることができます。例えば:
select load_file("/var/www/index.php")
これに対処するには、file_privs
は、PHPが使用するMySQLユーザーアカウントでは無効になっています。 display_errors = on
php構成で、攻撃者はWebルートへのパスを取得し、SQLインジェクションまたはディレクトリトラバーサルを使用してソースコードを読み取ることができます。
FTPを使用すると、ソースコードがプレーンテキストで送信されます。[〜#〜] sftp [〜#〜] を使用して、また、強力なパスワードを持っていることを確認してください。RSAキーを設定することをお勧めします。
バックアップファイルに注意してください。編集者がindex.php~
またはindex.php.orig
強制ブラウジング を使用して検出できるファイル。
すべての種類のサーバー側の脆弱性に加えて、漏洩したFTPパスワードも重要な問題です。保存されたFTPパスワードをCuteFTP、FileZilla、DreamWeaverなどのプログラムから収集し、ログイン資格情報を攻撃者に送信する、クライアント側の感染のクラスがあります。 これは非常に一般的です。私は個人的にこれが起こった何百、何千ものケースを見てきました。そして通常、パスワードを知らずに漏らした人は、とにかくパスワードをもう必要としない人です。
そして、攻撃者が実際に構成ファイルを調べてパスワードを探すのかどうか疑問に思っている場合、答えは明確に「yes」です。通常、これは攻撃者が最初に行うことの1つであり、新しいマシンが侵害されてから数分以内です。
攻撃者がこのファイルを実行するのではなく、テキストとして読み取ることができる方法は2つあります。
Webサーバーの設定が間違っていると、phpが実行されない可能性があります。 phpをインストールしてサーバー側で実行し、これをサポートするWebサーバーを配置する必要があることは明らかです。何らかの理由でphpのインストールに問題が発生した場合、phpファイルを「そのまま」ダウンロードすることは理論的には可能です。しかし、これはありそうもないことです。
このスクリプト(またはサイトの他の動的ページ)にLFI(ローカルファイルインクルード)の脆弱性がある場合、Webサーバー上にあるファイルを表示することが可能です。ファイルインクルードの脆弱性について Wikipediaページ を参照して、これがどのようになるかを確認してください。
余談ですが、usePHPファイルを使用するためには、次の方法でアクセスできる必要があることに注意してください。別のスクリプトで他の場所で実行していない限り、ページを「隠す」方法はありません。
漏洩したFTPパスワードはすべて非常に一般的であり、ソースファイルを削除する最も一般的な方法の1つです。開発者のWebサイトにインストールされたマルウェアは非常に一般的で、最近開発されたハッカーが知的財産を獲得する試みで、スピアフィッシング攻撃を目撃しています。 。
あまり一般的ではない方法の1つであり、私が認識していることは、特定の数の人々しか知らないものですが、WebサイトがホストされているLinux WebサーバーでWebサイトを開発すると、編集として問題が発生する可能性がありますソフトウェアは、開発者ビューから隠された編集済みファイルのバックアップを保存します。
Login.php〜
このファイルはウェブサーバーによって実行されないため、次のように入力してアクセスできます。
これにより、バックアップのlogin.phpファイルのソースが明らかになり、これを防ぐには、サイトのコードを開発してサーバーにアップロードするか、一般に公開されているディレクトリにバックアップファイルが保存されていないことを確認する必要があります。へのアクセス。
出典:2600マガジン
攻撃者がアクセスできた場合
databaseConnection.php〜
その後、本当にあなたのs ***クリーク
他の人が答えたように、これは不可能であるべきです。ただし、攻撃者がPHPソースコードを読み取る方法は絶対にないとは言えません。
たとえば、攻撃者が未加工のPHPコードを含む)Webサーバーのファイルを表示できる脆弱性が存在する可能性があります。または、攻撃者がFTPパスワードを発見できる可能性があります。 man-in-the-middle攻撃 や ソーシャルエンジニアリング など、さまざまな方法で行われます。多くの可能性があります。以下に、それを可能にする可能性のあるいくつかの脆弱性を示します。しかし、肝心なのは、PHPファイルをpublic_htmlフォルダーに置くだけで、それ自体がリスクになることはないはずです。
download.phpファイルは、ダウンロードするファイルの名前でGET/POSTパラメータを受け取り、ユーザー入力を正しくフィルタリングしないため、未加工のファイルをダウンロードできる可能性があります次のようなアドレスにアクセスすることによる、サイト上のファイルのコード: http://www.example.com/files/download.php?file=../index.php 。 this を参照してください。
別の例:攻撃者が Local/Remote File Inclusion のように、サーバーでコードを実行できる脆弱性がある場合、 File Upload Vulnerabilities 、およびその他、彼があなたのPHPソースコードを読み取ることを可能にするコードを実行することも可能かもしれません。
サーバーで設定が正しく行われている限り、PHPファイルはスクリプトとして登録する必要があり、Webサーバーでは、要求されたときにのみPHPによって解釈される必要があります。その解釈の結果を表示します。
つまり、問題がいくつあっても、ファイルが公開される可能性があります。これらの問題の中には、パブリックフォルダーにあるかどうかに関係なく、データを公開するものもあります。許可する必要のあるリクエストのみを許可するようにサーバーが適切に構成されていることを確認することは常に重要です。これにより、攻撃に利用できる領域が減少し、違反につながる可能性のあるバグ関連の問題の回避に役立ちます。
パブリックフォルダーに構成ファイルを置くことは良い考えですか?サーバーがファイルを処理せずに提供しないように構成されている限り、システム上の他のどの場所よりも安全性はそれほど高くありません。スクリプトエンジンによる実行を防止するためにWebサーバーにバグが使用される可能性はほとんどありませんが、SQL、FTP、またはプライベートフォルダー内にあるコードインジェクションなど、他の方向からの攻撃がより可能性が高いです等しく公開されます。
とは言っても、問題の裏側は、どこかにそれを置いてはいけないということです。最も安全なオプションは、WebサイトのPHPインスタンスを実行しているユーザーのみが、他のメカニズム(FTPユーザーや他の公的に使用されるユーザー。)ただし、これを構成および管理するのはかなり難しいため、追加のセキュリティが必要かどうかを判断する必要があります。
どちらがベストかというトスです。そのレベルのセキュリティを維持するために、すべてのパス、権限、およびユーザーを管理することは、多くの追加作業です。反対に、サーバーにパッチが適用され、適切に構成されている限り、非常に低いレベルで攻撃するゼロデイエクスプロイトに対してのみ脆弱であり、構成ファイルを使用しても、ほとんどすべての一般的な攻撃に対して安全です。パブリックフォルダ。