これは通常「HTML インジェクション」という用語が使用されるため、「HTML インジェクション」ではありません。<
これは通常、Web アプリケーションが のような文字をエスケープせずに HTML テンプレートにユーザー入力を書き込む脆弱性を指します<
。(PHP では、これはhtmlspecialchars()
、出力テンプレートを呼び出すのを忘れて、言語が自動的に呼び出しを行わないために発生する一般的な問題です。)
ただし、誰かがサーバー上の既存の .php ファイルの内容を変更した場合、単純な HTML インジェクション XSS よりもはるかに悪い妥協になります。ファイルへの書き込みを可能にするには、攻撃者が管理者アカウントへのアクセス権を取得するか、Web アプリのファイル書き込みの脆弱性を悪用し、アプリが独自の .php ファイルへの書き込みアクセス権を持つユーザーとして実行されている必要があります。 . (通常、アプリ ファイルへの書き込み権限を持たない権限の低いユーザーとして Web アプリを実行する必要があります。しかし、一部の共有ホスティング シナリオでは、1 人のユーザーですべてを処理できる場合があります。)
ホストが何と言おうと、今日のこの種の侵害の最大の原因は、断然 FTP クレデンシャルの喪失です。通常のパターンは、FTP サーバーへのアクセスに使用されるマシンがパスワードを盗むマルウェアに感染しているというものです。これは通常、別の Web サイト (それ自体がハッキングされていることが多い) の感染したページにアクセスした結果です。
したがって、FTP サーバーにアクセスできるすべてのマシンにウイルス チェッカーを確実にインストールしてください。複数の AV を使用し、見つけた感染マシンには OS の再インストールを実行します。次に、アカウントのパスワードを変更し、神のために暗号化されていない FTP の使用を停止します。それは 2013 年です。ホストが SFTP アクセスの提供を拒否する場合、これと上記の貧弱なアドバイスは、それらをダンプする良い理由になります。
File uploading is a part of my site. Could they have done some sort of buffer attack and made my site interpret a file as PHP commands?
It's conceivable; file upload is a very difficult function to get right in general. If the web site is running as a user that has write access to any location from which your web server will run .php files, then any file-write vuln escalates to an execute-abitrary-code vuln. So audit what bits of the filesystem have write access for the web server user, and lock it down as much as possible, in addition to performing strong whitelist validation on any variables used for filenames in your app. (Best: never use any client-supplied data to form a filename.)