データベースセキュリティ

1,516 views

Published on

第一回 中国地方DB勉強会の資料

  • Be the first to comment

データベースセキュリティ

  1. 1. データベース セキュ リティ Yasuo Ohgaki / yohgaki@ohgaki.net
  2. 2. セキュリティの基本 データ アプリ ホスト ネット ワーク 多層防御 フェイルセーフ 入出力制御
  3. 3. アプリケーションセキュリティ 2013/07/08岡山Ruby会議2013 (C) Electronic Service Initiative, Ltd. 3 フレームワーク アプリ ライブラリ 外部システム ライブラリ 外部システム ライブラリ ライブラリ ライブラリ ライブラリ ライブラリ ライブラリ ライブラリ Webサービス Webサービス Webサービス ブラウザ ブラウザ ブラウザ ライブラリ ライブラリ ライブラリ 外部システム 外部システム 外部システム ライブラリ ライブラリ ライブラリ 外部システム 外部システム 外部システム Webサービス Webサービス Webサービス ブラウザ ブラウザ ブラウザ 初期状態ではアプリのみ
  4. 4. データベースセキュリティ • PostgreSQLの場合はpg_hba.conf 接続制御 • ロールベースアクセス制御 • DBオブジェクトへのアクセス制御 • 作成・利用・削除 • SE-PostgreSQL(行、コラムのアクセス制御) アクセス制御 • DB自体のセキュリティ データベース
  5. 5. 接続と認証 ▪ pg_hda.conf ▪ データベースにアクセス可能なホストを設定 ▪ UNIXドメインとTCP接続 ▪ ローカルホストの場合、UNIXドメインの方が高速 ▪ 書式 local DATABASE USER METHOD [OPTION] host DATABASE USER CIDR-ADDRESS METHOD [OPTION] hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTION] hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTION] 2007/6/5 5PostgreSQL Conference 2007
  6. 6. 権限 ▪ 権限管理は8.0からロールベース ▪ DBオブジェクトに対して権限を設定可能 ▪ Webアプリケーションには不必要な権限を与えない ▪ 公開サイトで参照のみ可能なWebアプリケーションならDBユー ザはSELECT権限のみ与える ▪ 削除が不必要ならDELETE権限は与えない CREATE USER name は CREATE ROLE name LOGIN と同等 SELECT, INSERT, UPDATE, DELETE, REFERENCES, TRIGGER, CREATE, CONNECT, TEMPORARY, EXECUTE, USAGE 2007/6/5 6PostgreSQL Conference 2007
  7. 7. データベースセキュリティはほぼアプリ任 せ • データベース最大の脅威 • DBAには対策なし • 緩和策は可能 SQLインジェクション • 最小権限原則の実施 • 例:読み込み専用接続、テーブルアクセス権設定、 SELinux • SSRF(後述)を考慮した構成 緩和策 • SQLインジェクション脆弱性を排除 根本的な対策はアプリ
  8. 8. SQLインジェクションの種類と攻撃 直接SQLインジェクション • 直接攻撃SQL文に挿入 間接SQLインジェクション • 間接的に攻撃SQL文を挿入 ブラインドSQLインジェクション • データベース解析 • 参考:sqlmap ファイルの取得・設置 • 多くのデータベースはファイルへのアクセスを許す 任意コマンド実行 • DBによってはコマンド実行可能(UDFインジェクション) SSRF • PostgreSQL
  9. 9. PostgreSQLでのコマンド配置例 ▪ 他のDBでもSQL文からファイル操作が可能 CREATE TABLE footable(data text); INSERT INTO footable(data) VALUES ('TVqQ…'); UPDATE footable SET data=data||'U8pp…vgDw'; […] SELECT lo_create(47); UPDATE pg_largeobject SET data=(DECODE((SELECT data FROM footable), 'base64')) WHERE loid=47; SELECT lo_export(47, 'C:/WINDOWS/Temp/nc.exe'); 出典:Advanced SQL injection to operating system full control
  10. 10. MySQLでのコマンドの配置例 ▪ MySQLでももちろん可能 CREATE TABLE footable(data longblob); INSERT INTO footable(data) VALUES (0x4d5a90…610000); UPDATE footable SET data=CONCAT(data, 0xaa270000…000000); […]; SELECT data FROM footable INTO DUMPFILE 'C:/WINDOWS/Temp/nc.exe'; 出典:Advanced SQL injection to operating system full control
  11. 11. UDFインジェクション ▪ PostgreSQLの例 CREATE OR REPLACE FUNCTION sys_exec(text) RETURNS int4 AS 'libudflenpx.dll', 'sys_exec' LANGUAGE C […]; CREATE OR REPLACE FUNCTION sys_eval(text) RETURNS text AS 'libudflenpx.dll', 'sys_eval' LANGUAGE C […]; 出典:Advanced SQL injection to operating system full control
  12. 12. UDFインジェクション ▪ もちろんMySQLもOK CREATE FUNCTION sys_exec RETURNS int SONAME 'libudffmwgj.dll'; CREATE FUNCTION sys_eval RETURNS string SONAME 'libudffmwgj.dll'; 出典:Advanced SQL injection to operating system full control
  13. 13. SSRF攻撃 ▪ SSRFにXXE、SQL・OSコマンド・スクリプトインジェク ションなどを利用し企業内ネットワークの奥深くまで攻撃 Electronic Service Initiative, Ltd. 13 SSRFは内部ネットワークから攻撃する クラシックな攻撃パターンだが研究者は インターネットから攻撃する手法を考案 ※XXE – XML External Entityを利用した攻撃
  14. 14. SSRF攻撃とは ▪ SSRF = Server Side Request Forgery ▪ リクエストAをサービスAに送信 ▪ サービスAはリクエストBをサービスBに送信 ▪ リクエストBの幾つかフィールドをリクエストAで操作可能 A1 A2 A3 リクエスト A サービス A Electronic Service Initiative, Ltd. 14 B1 A1 A3 B2 サービス B リクエスト B 攻撃
  15. 15. SSRF攻撃の手法 Electronic Service Initiative, Ltd. 15 単純なリクエスト /ui/BufferOverview?server=172.16.1.1&port=31337&dispatcher=&target= XXE <!ENTITY xxe SYSTEM “http://172.16.1.1:80/someservice”> SQLインジェクション SELECT * FROM OPENQUERY(HostB, „SELECT * FROM @@version‟) (MS SQL) SELECT * FROM myTable@HostB (Oracle) SELECT dblink_send_query('host=127.0.0.1 dbname=HostB user='attacker' ','select version();') (PostgreSQL) OSコマンド system(„wget http://172.16.1.1/someservie‟) 攻撃
  16. 16. SSRF攻撃 ▪ XXEで可能と紹介されている例 ▪ ファイルとディレクトリへのアクセス ▪ リモートポートスキャン ▪ 他のシステムをHTTPで攻撃 ▪ HTTP以外のプロトコルで他のシステムを攻撃 ▪ PHPのXXE修正 ▪ SOAP - Disabled external entities loading (CVE-2013-1643, CVE-2013-1824) 2013年3月 PHP5.4.13/5.3.23 ▪ PostgreSQLの場合、構成によりさまざまなSSRF攻撃が可 能 Electronic Service Initiative, Ltd. 16
  17. 17. SSRF攻撃 SSRFはコマンドやリクエストを実行できる脆弱性がある場 合、実行可能 XXE、SQLインジェクション、OSコマンドインジェクショ ン、スクリプト実行 Electronic Service Initiative, Ltd. 17
  18. 18. SSRFとデータベース • FDW!(Foreign Data Wrapper) • DBLink! 例えばPostgreSQLの場合 • Oracle, MySQL, MS SQL, ODBC, JDBC, Informix, CouchDB, Mongo, Redis, Neo4J, File, LDAP, etc PostgreSQLのFDW
  19. 19. SQLインジェクション 対策
  20. 20. SQLインジェクション脆弱性 • 非常に簡単 攻撃の容易さ • 非常に危険 攻撃の危険性 • とても簡単 修正の難易度 簡単なのに無くならない!
  21. 21. なぜ無くならないのか? 対策の基本思想が間違っている事が原因 • API(プリペアードクエリ、プレイスホルダ)を使えば大丈夫! • バリデーションすれば大丈夫! この思想が間違い
  22. 22. 出力制御の基本 エスケープ API利用 バリデーション 出力先の種別を問わず 基本は同じ
  23. 23. 出力先の入力仕様を知る データベースに限らず、何かに出力する場 合、出力先の入力仕様を知ることが必須
  24. 24. SQL文の入力仕様 • エスケープ PQescapeLiteral パラメータ • エスケープ PQescapeIdentifier 識別子 • バリデーション APIなし SQL語句
  25. 25. プリペアードクエリの入力仕様 • プレイスホルダ エスケープなし パラメータ • エスケープ PQescapeIdentifier 識別子 • バリデーション APIなし SQL語句
  26. 26. よくあるSQLインジェクション脆弱性 識別子が埋め込まれている INクエリなど可変長のパラメータを埋め込み 整数値などが整数値だと思い込んで埋め込み SQL語句(DESCなど)だから大丈夫と信じ て埋め込み
  27. 27. 脆弱性を作る根本的原因 出力先の入力仕様を知らない APIの制限を知らない
  28. 28. 原因と対策 原因: 入力仕様、API制限を知らない 対策:入力仕様を知る • API制限もAPIの入力仕様
  29. 29. 入力仕様を知る最適な方法 エスケープ仕様を知る
  30. 30. 出力制御の基本 エスケープ API利用 バリデーション 出力先の種別を問わず 基本は同じ
  31. 31. まとめ
  32. 32. SQLインジェクション対策まとめ SQLインジェクション対策は簡単! 誤った思想が「簡単な脆弱性」を蔓延させる 出力先の入力仕様を知ることが最大のセキュリティ対策 APIは万能ではない 出力先に対するセキュリティ対策はすべて共通 • エスケープ > API利用 > バリデーション ただし実際にアプリを作る場合は、 • API利用 > エスケープ > バリデーション でOK 今日から脆弱性フリーのコーディング!

×