Webアプリの制限されたPostgreSQL権限

最初に「サイドクエスト」の質問に答えます：

あなたはあなたの心配や懸念に完全に正解です、そしてアプリケーションを設計する誰もが同じことを考えるべきです。他のすべてはだらしなく不注意です。

SQLインジェクション攻撃の成功によって引き起こされる可能性のある損害を軽減するには、最小特権の原則を確実に採用する必要があります。

要件に一致するシステムをセットアップするのは非常に簡単なはずです。

マイナスの代わりにアンダースコアを使用することを除いて、例のオブジェクト名を使用します。オブジェクト名には小文字、アンダースコア、数字のみを使用することをお勧めします。これにより、作業が楽になります。

/* create the database */
\c postgres postgres
CREATE DATABASE test_database WITH OWNER app_admin;
\c test_database postgres

/* drop public schema; other, less invasive option is to
   REVOKE ALL ON SCHEMA public FROM PUBLIC */
DROP SCHEMA public;
/* create an application schema */
CREATE SCHEMA app AUTHORIZATION app_admin;
/* further operations won't need superuser access */
\c test_database app_admin
/* allow app_user to access, but not create objects in the schema */
GRANT USAGE ON SCHEMA app TO app_user;

/* PUBLIC should not be allowed to execute functions created by app_admin */
ALTER DEFAULT PRIVILEGES FOR ROLE app_admin
   REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;

/* assuming that app_user should be allowed to do anything
   with data in all tables in that schema, allow access for all
   objects that app_admin will create there */
ALTER DEFAULT PRIVILEGES FOR ROLE app_admin IN SCHEMA app
   GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_user;
ALTER DEFAULT PRIVILEGES FOR ROLE app_admin IN SCHEMA app
   GRANT SELECT, USAGE ON SEQUENCES TO app_user;
ALTER DEFAULT PRIVILEGES FOR ROLE app_admin IN SCHEMA app
   GRANT EXECUTE ON FUNCTIONS TO app_user;

ただし、最も真剣に考えていない場合は、テーブルのアクセス許可を個別に付与する必要があります。 app_userを許可しない DELETEへ およびUPDATE ユーザーがそうする必要がないテーブルのデータ。