ユーザーが無害なクエリに制限されている場合、SQLインジェクションは依然として悪いことですか？
SQLデータベースのフロントエンドとして機能する非常に単純なPHPアプリケーションがあるとします。ユーザーがボックスにクエリを入力すると、アプリはクエリ結果をテーブルに表示します。
ユーザーがテーブルを変更できないようにするため、SQLユーザーは読み取り専用クエリのみの権限を持っています。つまり、ユーザーがDELETE * FROM personsやDROP TABLE personsなどをテキストボックスに入力しようとすると、エラーが発生します。
このWebアプリがSQLインジェクションに対して脆弱である場合、アプリの使用目的がユーザーがデータベースで独自の（読み取り専用の）SQLクエリを実行できることを前提とすると、依然として「不正な形式」と見なされますか？
アプリがSQLインジェクションに対して脆弱であり、害を及ぼさない場合は悪いですか-はい。それは重要ですか-おそらくそうではありません。修正する必要があります-はい。
基本的に、多層防御を備えています。最初の層はSQLインジェクションを許可しないことを確認することで、2番目の層は（データベース権限を使用して）インジェクションが成功しても害を及ぼさないことを確認することです。多層防御の背後にある考え方は、どの層も完全ではないかもしれないが、それらを組み合わせると、単独よりも優れた防御を提供するということです。 2番目の層が問題をキャッチすることを期待するだけで、この防御層は完璧であることが期待されます-多くの場合そうではありません。
それは常に悪いことです。脆弱性が直接悪用可能ではないが知らない場合でも、コードがずさんであることを意味するため、経験豊富なハッカーは、現時点では確認できない欠陥を見つける可能性があります。または、ボックスの外側を考える賢いユーザーでも、見逃したものを見つける可能性があります。したがって、それが無害であると想定しないでください。
実際、問題の脆弱なコードを投稿することもできます。その場合、議論はさらに面白くなるでしょう。
アプリケーションのコーディングが不十分でバグが多いという事実は変わりません。バグが多い場合は信頼できません。おそらくロジックやプログラミングに欠陥があり、正しく動作しない場合や間違ったデータを返す場合があると想像できます。
あなたはそのフロントエンドについて詳細を述べていませんが、私はそれのポイントが何であるか疑問に思っています。代わりに使用できる商用またはオープンソースのフロントエンドアプリケーションはありませんか？そうすれば、この問題を心配する必要はありません。データベースでそれぞれのユーザー権限を設定して、アクセスを制限するだけです。
データベースへのアクセス権を強制するのはフロントエンドではありません。セキュリティはソースで行われる必要があります。実際、フロントエンドはおそらくバイパスすることができます。 postgresqlはタグで言及されているので、コマンドラインユーティリティは言うまでもなく、そのためのGUIツールがかなりあります。これらのツールのいずれかを使用してデータベースに接続するのを妨げているのは何ですか？
このWebアプリがSQLインジェクションに対して脆弱である場合、アプリの使用目的がユーザーがデータベースで独自の（読み取り専用の）SQLクエリを実行できることを前提とすると、依然として「不正な形式」と見なされますか？
定義により、ここではSQLインジェクションは行われません。
私の知る限り、あなたのphpコードはユーザーのsqlクエリをそのままデータベースに渡します。フォームの「ボックス」の値は、パラメーターまたは別のSQLクエリの入力として使用されません。
そうは言っても、あなたの主な懸念はアプリケーションのユーザーに与えられる権利であり、 "Update"や "Insert"を拒否するようなフォームに検証を追加することを考えるかもしれませんが、これはデータベースがこれを処理できるので不必要です。正しい例外を制御して返します。