2

ユーザーが複雑な SELECT ステートメントを作成できるアプリケーションを作成しています。生成される SQL は信頼できず、完全に恣意的です。

信頼できない SQL を比較的安全に実行する方法が必要です。私の計画は、関連するスキーマとテーブルに対する SELECT 権限のみを持つデータベース ユーザーを作成することです。信頼できない SQL は、そのユーザーとして実行されます。

それで何がうまくいかない可能性がありますか？:)

postgres 自体に重大な脆弱性がないと仮定すると、ユーザーは多数のクロス結合を実行し、データベースに過負荷をかける可能性があります。これは、セッション タイムアウトで軽減できます。

うまくいかないことがたくさんあるように感じますが、リストを作成するのに苦労しています.

編集：

これまでのコメント/回答に基づいて、このツールを使用している人の数は常に 0 に非常に近いことに注意してください。

4

4 に答える 4

3

SELECT クエリは、データベース内の何も変更できません。dba 権限がないと、グローバル設定を変更できないことが保証されます。したがって、過負荷が本当に唯一の懸念事項です。

ワンロードは、複雑なクエリまたは単純なクエリが多すぎる結果である可能性があります。

  • statement_timeout複雑すぎるクエリは、設定することで除外できますpostgresql.conf

  • 単純なクエリを大量に受信することも回避できます。まず、ユーザーごとに並列接続制限を設定できます (alter userでCONNECTION LIMIT)。また、ユーザーと postgresql の間に何らかのインターフェース プログラムがある場合は、(1) クエリが完了するたびに待機時間を追加する、(2) CAPTCHA を導入して自動化された DOS 攻撃を回避することができます。

追加: PostgreSQL のパブリック システム関数は、多くの可能性のある攻撃ベクトルを提供します。それらは同様に呼び出すことができselect pg_advisory_lock(1)、すべてのユーザーはそれらを呼び出す特権を持っています。したがって、それらへのアクセスを制限する必要があります。(適切なオプションは、すべての「呼び出し可能な単語」、またはより正確には、それらの後に使用できる識別子のホワイトリストを作成することです。identifier (また、ホワイト リストにない識別子を持つ呼び出しのような構造を含むすべてのクエリを除外します。

于 2013-08-30T16:24:04.100 に答える
1

ユーザーが SELECT のみであり、関数に対する権限を取り消すことに加えて、次のことが頭に浮かびます。

  • 読み取り専用トランザクション。BEGIN READ ONLYによって、またはその最初の命令としてトランザクションが開始されるSET TRANSACTION READ ONLYと、ユーザー権限とは関係なく、トランザクションは何も書き込むことができません。

  • クライアント側で 1 つに制限したい場合は、1 つSELECTにまとめられた複数のクエリを受け入れない SQL サブミッション関数を使用することをお勧めします。たとえばPQexec、API のスイスナイフ メソッドはそのlibpqようなクエリを受け入れます。また、PHP のpg_query.

  • http://sqlfiddle.com/は、任意の SQL ステートメントを実行するための専用サービスであり、1 日中ハッキングや DDo 攻撃を受けずに実行できるという概念の証明と見なされる可能性があります。

于 2013-09-02T14:34:31.497 に答える