データベースユーザーが読み取り専用の場合、SQLインジェクションについて心配する必要があるのはなぜですか？

Question

彼ら（悪意のあるユーザー）はテーブルを記述し、重要な情報を得ることができますか？ユーザーを特定のテーブルにロックダウンするとどうなりますか？私はSQLインジェクションが必要だと言っているわけではありませんが、古いコードについては気になりますが、dbユーザーはロックされています。ありがとうございました。

編集：私はあなたが言っているのか理解が、私は他のデータのためのResponse.Writeをを持っていない場合、どのように彼らはそれを見ることができます。クロールとドッキングをもたらすことは理にかなっています。他の人も同様ですが、データを実際にどのように見ていますか？

Answer 1

誰かは立ち入り禁止であるべきものへのアクセスを得るために、真の同等の代わりに、偽を返すために認証チェックを引き起こすためにSQLを注入できます。

それとも、クロールにデータベースのパフォーマンスをもたらすために自分自身にカタログテーブルのジョイン20または30回を注入できます。

またはがのデータを変更する別のデータベースユーザーとして実行されるストアドプロシージャを呼び出すことができます。あなたは全体データベースを読んで、任意のユーザーを気にしない場合にのみ、

Answer 2

'); SELECT * FROM Users 

はい、あなただけのデータ（テーブル/ビュー）にそれらをロックダウンする必要があり、彼らは実際にそれが公に直面しています場合は特に、見ることができるはずです。

Answer 3

。例えば、ここでは簡単な、注射用ログインシーケンスです：

select * from UserTable where userID = 'txtUserName.Text' and password = 'txtPassword.Text' 

if(RowCount > 0) { 
    // Logged in 
} 

私はちょうどそのユーザとしてログインするために、任意のユーザー名とパスワード'または1 = 1を使用してログインする必要があります。

Answer 4

非常に注意してください。私はドロップテーブルを削除し、テーブルを変更し、テーブルを作成し、テーブルを切り捨てたと仮定しています。

基本的には、優れたSQLインジェクションとは、データベースに依存している何かを変更することができるはずです。これは、認可、権限、外部システムへのアクセス、...

はあなたがデータベースから取得されたディスクにデータを書き込むかだろうか？その場合、perlやperlファイルのような実行可能ファイルをアップロードし、実行してボックスにアクセスしやすくすることができます。

また、特定の戻り値が予想される状況を利用して、データが何であるかを判断することもできます。私。 SQLがtrueを返した場合は実行を継続し、そうでない場合は実行を停止します。次に、SQLでバイナリ検索を使用できます。 select count（*）ここで、user_password> 'H';カウントが0より大きい場合、カウントは継続します。これで、プレーンテキストのパスワードをスクリーンに印刷することなく正確に見つけることができます。

また、アプリケーションがSQLエラーに対して強化されていない場合は、結果ハンドラの実行中に結果がSQLまたはSQLに挿入され、結果が画面に表示される場合があります。最初のSQL文は、ユーザー名とパスワードの素敵なリストを収集します。 2番目のステートメントは、適切でないSQL条件でそれらを活用しようとします。 SQL文は、このエラー状態で表示されている場合は、...

ヤコブ

Answer 5

はいは、SQLインジェクションを心配し続けています。悪意のあるSQL文は、書き込みに関するものではありません。

リンクされたサーバーがある場合、またはクロスdbリソースにアクセスするためにクエリが作成されたとします。すなわち

SELECT * from someServer.somePayrollDB.dbo.EmployeeSalary; 

Answer 6

あなたが悪いのパラメータを持つパブリック（しかし、文書化されていない）メソッドを呼び出すことで、インスタンスをクラッシュすることができオラクルのバグがありました。

Answer 7

エンドユーザが任意のSQLを実行できるようにする読取り専用ユーザーでSQL tutorial websiteを作成中だったので、この質問と回答を読んでいます。

これは明らかに危険で、私はいくつかの間違いを犯しました。ここで私が最初の24時間に学んだものがあります（これのほとんどは他の回答によってカバーされていますが、この情報はより実用的です）。

• は、ユーザーテーブルまたはシステムテーブルへのアクセスを許可しない：

のPostgres：

REVOKE ALL ON SCHEMA PG_CATALOG, PUBLIC, INFORMATION_SCHEMA FROM PUBLIC 

• あなたの読み取り専用ユーザーは唯一のあなたが必要なテーブルへのアクセス権を持っていることを確認します あなたが望むスキーマ：

のPostgres：

GRANT USAGE ON SCHEMA X TO READ_ONLY_USER; 
GRANT SELECT ON ALL TABLES IN SCHEMA X TO READ_ONLY_USER 

• 長時間実行をドロップするようにデータベースを構成しますが

Postgresの照会：

Set statement_timeout in the PG config file 
/etc/postgresql/(version)/main/postgresql.conf 

• 独自のスキーマ内

Postgresの機密情報を入れて考えてみましょう：

GRANT USAGE ON SCHEMA MY_SCHEMA TO READ_ONLY_USER; 

GRANT SELECT ON ALL TABLES IN SCHEMA MY_SCHEMA TO READ_ONLY_USER; 

ALTER USER READ_ONLY_USER SET SEARCH_PATH TO MY_SCHEMA; 

• を任意のストアドプロシージャをロックダウンして、彼らは、読み取り専用ユーザーによって実行することができないように注意してください

編集：システムテーブルへのアクセスを完全に削除することで、ユーザーが許可されなくなりましたo cast（）のような呼び出しを行います。だから、アクセスを許可するために、再度これを実行することもできます。

GRANT USAGE ON SCHEMA PG_CATALOG to READ_ONLY_USER;