私の友人は、PHP Apache/MySQL/home brew CMSを使用し、OS Debian 8 "jessie"で古いホスティングを使用して記述された15歳のウェブサイトを所有する会社に勤めています。SSHにより、パスワード(fail2banなどがない)に加えて、「admin」ページとphpMyAdminの両方が公開されており、アクセス可能であり、レートリミッターやその他のブルートフォース防止技術やソフトウェアを使用していません。そう、そうです。WebサイトはSQLに対して脆弱ですインジェクションもそうです。まとめると、セキュリティ上の問題です。その上、Apacheのログから学んだように、悪意のあるユーザーから注意が向けられ、ハッキングされるのは時間の問題です。
最近のCOVID-19の問題が原因で、彼らの会社はビジネスを続けようと試みており、誰もレイオフしていませんが、ウェブサイトを書き直すための予算は(まだ)ありません。彼らの目標は、困難な時期を乗り越え、できるだけ多くの問題を軽減することですPHP codeに触れずに後でWebサイトを書き直すこと。 here 、 here または here の解決策がうまく機能しないのはそのためです。
そこで、彼は次の6〜9か月で使用できるいくつかの一時的なアイデア/解決策について質問し、次のことを提案しました。
ただし、SQLインジェクションは依然としてリストに含まれており、Apache/PHPに詳しいアドバイスを提供することはできません。nginx/ nodejsとIIS/.NETの両方を使用しています。
ここに私の質問があります:アプリケーションコードを変更せずにSQLインジェクションを一時的に軽減する最良の方法は何でしょうか?
.htaccessを使用してクエリをフィルタリングすることをお勧めしますか?彼はプロキシを使用して同じことをするべきですか?それを行うための比較的安価な方法は他にありますか?助けてくれてありがとう。
次の2つのうちの1つがないと、多くのことを実行できません。
SQLインジェクションは通常、書き換えない限り、古いコードでは防止できません。はい、WAF(Webアプリケーションファイアウォール)が周りにあり、攻撃の大部分を軽減できますが、何かがWAFから逃れた場合、サイトは完全に公開されます。
クラウドプロバイダーに移行しても、セキュリティは変わりません。自宅でホストされている安全でないウェブサイトは、Amazon、Google、darkwebプロバイダーでホストされている場合は安全ではありません。プロバイダーにセキュリティプラグインが含まれている場合は、安全性が少し低下する可能性があります。しかしとにかく脆弱です。
サイトがCMSの場合は、HTMLでサイトのローカルミラーを作成し(HTMLスパイダーを探してください)、これをホストできます。一部の機能が欠落していますが(検索が頭に浮かびます)、オンラインになり、SQLインジェクションに対して無防備になります。他の欠点は、CMS側で何かを変更するたびに、ファイルを再ミラーリングして再エクスポートする必要があることです。
しかし、私はコードを編集することをお勧めします。もし、あんたが grep -R mysql_query /path/of/the/cms
どれだけ変更する必要があるかを理解できます。サイトを常にエクスポートし続けるよりもコードを変更する方が速いと思います。
SSHはパスワードを許可します(fail2banなどはありません)
サーバー(またはCSF + LFD)にfail2banをインストールできますか?できるだけ早く。または、SSHを外部に公開しないほうがよいでしょう。ホワイトリストに登録されたいくつかのIPアドレスへのアクセスを制限できる場合、それは途方もない進歩です。
さらに、「admin」ページとphpMyAdminの両方が公開され、アクセス可能であり、レートリミッターやその他のブルートフォース防止技術やソフトウェアを使用していません。
本当にphpMyAdminが必要ですか?その場合は、.htaccessを使用して、ホワイトリストに登録されたいくつかのIPアドレスへのアクセスを制限します。会社は静的IPアドレスを既に持っている可能性があります。それ以外の場合は、phpMyAdminを無効にします。
他にできること:
wget
またはhttrack
を使用し、FTP経由でファイルをデポジットしてから、CMSを削除し、データベース。明らかに、彼らには他の優先事項があり、サイトはすぐには修正されません。待つほど、違反の可能性が高くなります。そのペンテストをしてください、そしてあなたの友人はリスクが本当であることに気づくでしょう。
URL内の正当なクエリである可能性のあるものをマップできない限り、WAFは災害になります(これにより、災害を軽減するだけで、防止することはできず、多大な労力が必要になります-カスタム正規表現を作成する必要がありますすべてのURLのパラメータごとに)。
MySQLシムなしの最新のPHPインストールでそれを実行することはできません( e.g。 )。
触れずにPHPコード
明らかに、カスタムアプリケーションを公開するために必要なのはすべてコードを書くこと、または少なくともコストの大部分を占めているという印象を受けています。絶対に避けてください。これはうまく終わりません。
彼らがあなたの身代金を身につけており、すべての正当なアクセスが認証されている場合は、サイトを適切な認証ページの背後に置きます(つまり、ログインページ以外のすべてに対してプロキシが設定された別のWebサーバーで実行されています)。暗号化された有効期限、およびユーザーの識別に役立つ可能性のあるその他のもの(IPアドレス/ ASN番号はおそらく安全/ユーザーエージェントからのメジャーバージョン情報は使用しないでください)。すべてのページで起動するCookieが有効かどうか、有効期限が切れていないかどうかを確認し、ログインに返送するバックエンドサイトに自動プリペンドを追加します。バックエンドログインを、フロントエンドログインからのcurl呼び出しを受け入れてセットアップしてセッションIDを返すものに置き換えます。
これにより、アカウントを持つユーザーがサイトをハッキングするのを防ぐことはできませんが、攻撃対象を減らすことができます。
(ところで、あなたが引用した3つの「解決策」は、3つの異なる方法で述べられた同じ解決策です)。