すべてのphpスクリプトに欠陥がある場合、SQLインジェクションに対するデータベースの保護をどのように設定する必要がありますか？
私はSQLインジェクションの歴史を持つ非常に安全でないphpウェブアプリを継承しました。スクリプトをすぐに修正することはできません。Webサイトを実行するにはスクリプトを実行する必要があります。また、最初にphpの終わりから処理するにはphpスクリプトが多すぎます。ただし、mysqlデータベースとそのユーザーの完全な制御を含め、サーバーとサーバー上のソフトウェアを完全に制御できます。
全体で300のスクリプト、40のセミプライベートスクリプト、20のプライベート/セキュアスクリプトのように見積もってみましょう。
だから私の質問は、php側（たとえば、300スクリプトのリストのどこか）からのSQLインジェクションが避けられないという暗黙の前提で、データを保護するための最善の方法です？
私の最初のドラフト計画は、mysqlデータベースに異なる許可ユーザーの複数の層を作成することです。このようにして、最初にセキュリティを確保する必要のあるデータとスクリプトを保護し（「プライベート/セキュア」カテゴリ）、次にデータベーステーブルとスクリプトの第2層（「セミプライベート」）を保護し、最後にセキュリティを処理できます。 phpアプリ全体の残りの部分（たとえば、ホームページを表示するだけでも必要なものなど、本質的に「公開」情報を処理するデータベーステーブルを最終的に保護した結果）。
したがって、3つのデータベースユーザー（パブリック、セミプライベート、およびセキュア）があり、異なるユーザーが3つの異なるスクリプトグループ（セキュアスクリプト、セミプライベートスクリプト、およびパブリックスクリプト）のそれぞれに接続しています。このようにして、「パブリック」または「セミプライベート」からの「セキュア」へのすべてのアクセス、および「パブリック」からの「セミプライベート」へのすべてのアクセスを防ぐことができます。私が調べるべき他の選択肢はありますか？階層型アクセスシステムが進むべき道である場合、どのアプローチが最適ですか？
簡単な答えは、「データベースレベルでSQLインジェクションに対して実際に保護することはできません」です。クエリを使用してデータベースに接続すると、DBがそれを実行します。誰かがそのSQLに不快感を注入した場合、あなたが望むことができる最善の方法は、彼らができる被害を軽減することです。
損傷の軽減という点では、すでに説明したことは優れたアプローチです。各スクリプトを、スクリプトに必要な最小限のアクセス（選択、挿入、更新、削除、およびテーブルの特定のサブセットのみ）に制限されたデータベースユーザーアカウントの使用に制限します。スクリプト必須タッチ）。
これはSQLインジェクションからデータベースを保護しません-侵害したスクリプトに基づいて誰かが盗む（または破壊する）ことができるデータの量を制限するだけです。断固とした攻撃者は、おそらく最初に「興味深い」スクリプトを攻撃します。このスクリプトには、そもそも必要なジューシーなデータが含まれています。
予期しない問題に関しては、ユーザーロールへの分離は、重大な破損のリスクを伴いながら（複数のことを実行する複雑なクロステーブルクエリとスクリプトが多数ある場合）、最小限のセキュリティゲインしか提供しない可能性があります（特に =複数のことを行うスクリプトの複雑なクロステーブルクエリがたくさんある場合）。
このレベルでのデータベースの監査には、現在のすべての呼び出しを、SQLインジェクション攻撃を困難または不可能にする適切なパラメーター化されたクエリに置き換えるよりも、おそらく同じくらいの時間がかかることに注意してください。
PHP-IDS http://phpids.org/ を確認することをお勧めします。スクリプトを保護する代わりになるわけではなく、すべての攻撃を防ぐことはできませんが、セキュリティバンドエイドを適用する必要がある場合は、非常に素晴らしいバンドエイドです。それは便利なハッカーを苛立たせ、彼らを次の標的に移らせるでしょう。それは決心した人を止めることはありません。
それはで最善の努力を推測します：
- XSS
- SQLインジェクション
- 既知のPHPエクスプロイト
- さまざまな形式でデータを非表示にする
Mod_securityと組み合わせると、非常に役立ちます。
パーティショニングの戦略は100％正しいです。ただし、SQLインジェクションが存在する場合は、他のクラスの攻撃が発生する可能性があるため、SQLインジェクションを超えて考えてください。インスタンスまたはセッションハイジャックの特権の昇格？サイトの設計方法によっては、パーティション分割が最初に想像したよりも難しい場合があります。
最終的に弾丸を噛み、それを再コーディングするだけで、何が起こる必要があります。
mod_security ApacheまたはIDS/IPSハードウェアファイアウォールモジュールの場合、リクエストの分析を行い、潜在的なSQLインジェクションをブロックします。しかし、他のコメンテーターがリスクを詳細に説明すると確信しています。
GreenSQL が必要です。とにかく、実稼働環境では使用したことがありませんが、MySQLのクエリとして機能し、SQLインジェクションを示す危険なクエリを除外します。
（才能、時間、またはリソースがある場合）データベースとPHPスクリプトの間に位置し、疑わしいSQLクエリを除外するデータベースプロキシを作成できます。=のすべてまたはほとんどの場合PHPスクリプトが同じデータベースAPIライブラリを呼び出している場合は、そこにフィルタを実装することをお勧めします。必ずパッチファイルを作成して（diffを使用）、PHP = DB APIが更新され、変更を再適用できます。
Mysql Proxy を使用して、すべてのリクエストをその場で検証/変更できます。 Dのデータマイニングを防ぐのは難しいかもしれません。たとえば、少なくともすべてのDROPを削除することはできます。